Generative Engine Optimization: How AI Search Is Rewriting Content Strategy

What happens to your blog when the reader stops being a person.

For two decades, the rules of online content were stable enough to take for granted. Write something, optimize it for Google, publish, and a portion of the people searching for the topic would find their way to you. The traffic itself was the unit of value. Subscribers, leads, and revenue followed from clicks.

That model is partially breaking. People still type queries, but increasingly they type them into ChatGPT, Perplexity, Google’s AI Overviews, Claude, or Copilot — and what comes back is a synthesized answer, not a list of links. Sometimes your content is what got synthesized. Sometimes you are cited; sometimes paraphrased; sometimes neither. The reader rarely visits your site at all.

Engineering blogs and developer-relations teams are the most affected, because technical content is exactly what answer engines synthesize most aggressively. “How do I use X with Y?” and “What’s the difference between A and B?” used to drive most of the traffic to good technical writing. They now often resolve entirely inside an answer engine.

The marketing industry has a name for the response: Generative Engine Optimization, or GEO. The name is awkward, the discipline is real, and a lot of the writing about it confuses motion with progress. This post is a technical view of what changed, what to do about it, and what to ignore.

What actually changed (and what didn’t)

The marketing framing of GEO suggests everything has changed and SEO is dead. The technical reality is more interesting: traditional SEO still matters, but it no longer captures the whole funnel.

Two things genuinely changed.

First, the retrieval surface expanded. AI answer engines do not just rank your page against ten others. They retrieve a small handful of sources — typically two to seven, depending on the system — then synthesize an answer from the retrieved content. The selection criteria for “what gets retrieved” are still partially derived from the underlying search index. The criteria for “what gets quoted” inside the answer are different and less well-understood.

Second, the click model eroded. When an answer engine fully resolves a question, no click happens. Your content was used; you got no analytics event. For some queries this is a wash because the user would have bounced anyway. For others, it is genuinely lost engagement.

What did not change is the foundation. Pages that are structured well, written clearly, hosted on credible domains, and accurate are still the pages answer engines retrieve and cite. The E-E-A-T concepts Google has pushed for years — experience, expertise, authority, trustworthiness — map almost directly onto what makes a page useful to an LLM-based system. The technical SEO baseline (crawlable, indexable, structured, fast) is still the baseline. Teams that invested in those things over the past decade are largely the ones being cited today.

The shift is not “SEO is obsolete.” The shift is that SEO is now necessary but not sufficient.

The functional model of an AI answer engine

A useful mental model: most production AI answer engines are retrieval-augmented generation systems, with the retrieval layer doing something close to a traditional search and the generation layer assembling an answer from what was retrieved. Understanding the two layers separately is what lets you make sensible decisions about content.

The retrieval layer is where indexability still rules. If your page is not in the index — because it is blocked from crawling, requires authentication, is dynamically rendered in a way the bot cannot resolve, or simply has no inbound signal — the answer engine cannot retrieve it. Most “we don’t appear in AI answers” investigations end here. The fix is usually unglamorous: make content accessible to crawlers that identify themselves as AI agents (GPTBot, PerplexityBot, ClaudeBot, Google-Extended), and make sure meaningful content is in the rendered HTML rather than client-side React state.

The generation layer is where GEO has genuinely new advice. The model has retrieved your page along with two to six others. What determines whether your content gets quoted, paraphrased, or cited? The early academic work — the GEO paper by Aggarwal et al., the first to put numbers on the question — found that strategies like adding relevant statistics, including authoritative quotations, and improving fluency consistently increased visibility in generated answers across multiple engines. These are not tricks. They are properties of content any reasonable system would weight.

Two observations from that research carry over. First, content containing its own evidence (numbers, named sources, direct quotes) is more likely to be quoted, because the answer engine can attribute a specific claim to it. Second, content that explains rather than asserts — that walks through reasoning rather than announcing conclusions — is more useful to a system that has to synthesize an answer for a user with a slightly different framing of the same question.

The pattern that emerges: optimize for being a useful component of someone else’s answer, not for being the destination.

What this means for technical content

For engineering blogs and developer-relations teams, the practical implications are concrete and mostly involve adjusting writing patterns rather than overhauling stacks.

Lead with the answer. Most technical posts bury the actual finding under several paragraphs of context. Answer engines reward content where the first paragraph of a section contains a self-contained statement of the conclusion, with the supporting detail following. This is also better writing for human readers, which is part of why it works.

Make claims attributable. A sentence that says “in our testing, a seven-billion model handled classification at a fraction of the cost of a frontier model with no measurable accuracy difference” can be quoted with attribution. A sentence that says “smaller models are cheaper” cannot. The first version is more useful to an answer engine and more useful to a careful reader.

Use semantic structure deliberately. Heading hierarchies, lists, definition patterns, and code blocks give the model something to anchor on. The pattern an answer engine looks for is “definition or claim, followed by supporting detail, in a clearly bounded section.” This is also how technical writers should already structure posts; the answer-engine pressure makes the discipline more visible.

Maintain the underlying signals. Backlinks from credible domains still matter. Author bylines that establish expertise still matter. Recency still matters — answer engines have a measurable bias toward more recent content on fast-moving topics. None of this changed; what changed is that getting these things wrong now costs you both Google rankings and AI citation visibility, doubling the penalty.

Avoid the shortcuts. Adding fake statistics or fabricated quotes to “feed the model” is the move that destroyed traditional SEO when keyword stuffing was the equivalent. Answer engines will eventually weed it out, and the reputational damage when they do is worse than the visibility upside in the meantime.

llms.txt: useful, overhyped, or both?

The most discussed technical convention to emerge from this shift is llms.txt, proposed by Jeremy Howard in late 2024. The idea is simple: a Markdown file at the root of your site that provides a curated, machine-readable map of your most important content for AI consumption. A companion llms-full.txt can contain the full content of key pages concatenated together, optimized for an AI to read in a single fetch rather than crawling.

The case for llms.txt is straightforward. AI systems struggle with the complexity of modern web pages — JavaScript rendering, ads, navigation, modals. A clean Markdown summary is a friendlier interface. For developer documentation in particular, where an AI coding assistant pulling your library’s docs is a common case, a well-curated llms.txt meaningfully improves the assistant’s accuracy.

The case against is the adoption gap. The major AI providers have not officially committed to consuming llms.txt files, and empirical studies of server logs show inconsistent crawler interest. As a community convention with no standards-body backing, llms.txt is closer to “useful for some specific cases” than “do this or you become invisible.”

The pragmatic call: if you operate developer documentation, an API reference, or other technical content that AI coding assistants are likely to pull at inference time, an llms.txt file is worth the modest effort. For a general technology blog, the priority is far lower than getting the underlying content structure right. Treat it as a low-cost experiment, not a strategic pillar.

Measuring success without click-through

The hardest part of this transition is the measurement gap. Traffic numbers underrepresent your real influence in a world where answers resolve without clicks. A few practices that survive contact with this reality.

Track AI bot traffic explicitly. Server logs can be parsed for the user-agent strings of known AI crawlers (GPTBot, PerplexityBot, ClaudeBot, Google-Extended). Rising bot traffic to specific pages is a leading indicator that those pages are being used in answer generation. It is not a perfect signal, but it is the cheapest one available.

Monitor citation appearance. A growing set of tools — and a few open-source approaches — will programmatically ask answer engines a set of queries you care about and report which sources got cited. This is closer to the right metric: not “how many people clicked our page” but “how often is our content the substrate of the answer.” Set the queries based on your actual buyer’s questions, not vanity searches.

Watch branded queries and direct traffic. The pattern that has emerged for content performing well in answer engines: searched-for traffic declines, but branded search and direct traffic rise as users encounter your name in synthesized answers and come find you on purpose. The shift is from “found by accident through search-results exploration” to “sought out by name after exposure.” This is a higher-quality funnel even though it looks worse in a chart of total sessions.

Stop using session count as the primary KPI for content marketing. It still has its uses, but its information density has dropped. The teams adapting fastest are the ones who shift the headline metric to brand mentions in AI responses, citation share of voice on the queries that matter, and qualified leads attributable to AI discovery. These are harder to measure, which is exactly why most teams have not done it yet, which is exactly why the teams that have done it have an information advantage.

The honest summary: the rules of being read have changed in ways that mostly reward content that was good for humans anyway. The work is not chasing a new acronym; it is doubling down on writing that has something to say, structured so another system can use it, hosted somewhere a reasonable engine would trust. The teams that win the next decade of technical content will not be the ones with the cleverest GEO tactics. They will be the ones who recognized early that “optimize for AI” mostly means “publish things worth quoting.” Which was the rule all along.