Generative engine optimization: how to get cited by AI Overviews, ChatGPT and Perplexity

What actually changed, and what did not

The change is real, but it is narrower than the industry’s enthusiasm suggests. For a growing share of questions, the search result is now a synthesised paragraph with a handful of sources named beside it, and the reader may never reach a website at all. Being one of the sources named is a different objective from being the fourth blue link, and it is worth understanding on its own terms.

What has not changed is the machinery underneath. Google’s own documentation is unusually blunt about this: there are no additional requirements to appear in AI Overviews or AI Mode, and no special optimisations are necessary. The features draw on the same index, built by the same crawler, ranked by the same core systems. Google goes further and says you do not need to create new machine-readable files, AI text files or markup, and that there is no special schema.org structured data required.

That statement is the single most useful thing in this field, and it is also the most frequently ignored, because a large amount of consulting revenue depends on ignoring it. So the honest framing of generative engine optimisation is this: it is a set of emphases inside search work, plus a genuinely new set of considerations for the engines that are not Google. Both halves matter. Neither is a new discipline.

GEO, AEO, LLMO: one practice with three acronyms

Generative engine optimisation, answer engine optimisation and large language model optimisation describe the same activity with different marketing. There is no meaningful methodological difference between them, and nobody has published evidence separating one from another. When all three appear in a single proposal, you are reading positioning rather than practice.

What the acronyms gesture at is a real shift in the unit of retrieval. Classical SEO optimises a page to rank as a whole. Generative systems retrieve and quote passages, then assemble an answer from several of them, often from several sites. So a paragraph has to make sense when lifted out of its page and placed next to three others from elsewhere. That is a writing constraint rather than a technical one, and it is most of what GEO means in practice.

How retrieval selects your page

Google describes its AI features as using retrieval-augmented generation and query fan-out. Those two mechanisms explain most of the observable behaviour, and understanding them is worth more than any checklist.

Retrieval-augmented generation means the model does not answer from memory. It issues searches, retrieves passages from the index, and generates an answer grounded in what it retrieved, citing sources as it goes. This is why being indexed and being retrievable still matters enormously: a page that is not in the index cannot be retrieved, and a page that is retrieved but ambiguous will not be quoted.

Query fan-out means the system decomposes one question into several sub-questions, runs them, and synthesises across the results. A user asking “which ecommerce platform should I use for a small catalogue with international shipping” produces sub-queries about platform comparison, international tax handling, shipping integrations and catalogue limits. You do not have to be the best result for the whole question. You have to be the best result for one of its parts.

That single point changes how you plan content. It rewards breadth of genuinely distinct coverage across a topic rather than one enormous page trying to be definitive, which is the same conclusion that topical authority work reaches by a different route. It also means the way to be cited more often is usually to answer more sub-questions well, not to add adjectives to the page you already have.

The final constraint is the one Google repeats and everyone forgets: meeting every technical requirement does not oblige Google to crawl, index or serve anything. Eligibility is not entitlement.

Answer-first structure: the block that belongs under every H2

Here is the one structural habit that genuinely helps, and it helps for reasons that have nothing to do with machines.

Under each H2, the first two or three sentences should answer the question that heading implies, completely, without depending on anything above it. Then elaborate. Not “There are several factors to consider when choosing X, and in this section we will explore them” — that sentence answers nothing and can be lifted nowhere. Instead: the direct answer, the important caveat, the number if you have one, then the detail.

Three things follow from writing this way:

1. The passage is quotable. A retrieval system that pulls one block gets a complete thought rather than a fragment that needs the previous paragraph to make sense.
2. The heading becomes a real question. Writing an answer-first block forces the heading to be specific, which improves the table of contents, the internal linking and the reader’s ability to skim.
3. Human readers prefer it. People scan headings, read the first sentence beneath, and decide whether to continue. Answer-first structure is simply good expository writing, rediscovered under a new name.

The failure mode is over-application. Google explicitly says there is no need to break content into tiny pieces, and that its systems handle multi-topic pages perfectly well. Chopping a coherent article into fifty two-sentence chunks with headings makes it worse for everyone. Write in blocks that are self-contained; do not write in fragments.

Original data and specifics are the actual citation bait

If retrieval assembles an answer from multiple sources, the question becomes: what makes a system choose your passage over the eleven others saying roughly the same thing? Consistently, the answer is that your passage contains something the others do not.

Google frames this as the difference between commodity content — common knowledge that could have come from anyone, the generic list of tips — and non-commodity content carrying a unique expert or experienced take. A synthesiser has no reason to cite the fifth restatement of a definition, and every reason to cite the only page with the number, the method or the first-hand observation.

Things that are hard to synthesise away, roughly in order of value:

• Data you generated. A survey of your customers, an analysis of your own anonymised platform data, a benchmark you ran. Nobody else has it, so it can only be attributed to you.
• Method described concretely enough to follow. The exact sequence, the actual thresholds, the specific failure mode. Vague process descriptions are interchangeable; specific ones are not.
• Named trade-offs. Where the industry genuinely disagrees, saying what the disagreement is and who holds which position. Summaries flatten disagreement, so a page that maps it becomes the source worth citing.
• Definitions and constraints stated precisely. Character limits, thresholds, version numbers, conformance levels. Correct specifics get quoted because they are checkable.
• First-hand experience. What went wrong when you did it, and what you changed. This is the “Experience” in E-E-A-T, and it is the part that cannot be manufactured.

The inverse is worth saying plainly. Producing more pages that restate common knowledge is not a GEO strategy; at volume, Google classifies it as scaled content abuse. And it is a bad bet on its own terms, because commodity content is precisely what a language model can already produce without you.

Schema, semantic URLs and machine-readable clarity

This is where the industry disagrees with the platform, so it is worth being exact about who says what.

Google’s position, stated directly: structured data is not required for generative AI search, and there is no special schema.org markup that makes you eligible for AI features. Its value is elsewhere — eligibility for rich results in ordinary search, and unambiguous description of what a page is about.

The GEO industry’s position is that structured data still helps indirectly, by removing interpretive ambiguity about prices, authorship, organisations and dates, and that other engines may weigh it differently from Google. That is plausible and largely unevidenced.

Our reading, and you are free to disagree: implement structured data properly because it earns rich results, keeps your facts consistent, and costs very little once the templates are built. Do not implement it as an AI tactic, and do not let anyone sell you a schema programme on the promise of citations. The rules that matter have not changed: use JSON-LD, mark up only what is genuinely visible on the page, include the required properties rather than sprinkling optional ones, and remember that valid markup buys eligibility rather than a result.

The same applies to the rest of the machine-readable layer: descriptive URLs, correct heading hierarchy, a single H1, tables marked up as tables rather than as images, and text present in the HTML rather than assembled by client-side JavaScript. None of these are AI tactics. They are the conditions under which any automated reader can understand you, and they were worth doing before anyone said “GEO”. If your content only appears after a client-side render, fixing that is technical SEO work with a direct payoff here.

Entity building: being a known thing, not just a ranking page

There is a difference between a page that ranks for a query and an organisation a system recognises as an entity. The second is more durable, and it is what people are usually reaching for when they talk about brand-level AI visibility. Entities are established by consistent, corroborated description across independent sources, which in practice means:

• Consistency of the basics. The same organisation name, address, and description everywhere it appears — your site, your profiles, directories, professional bodies, event listings. Inconsistency is what makes disambiguation fail.
• sameAs links from your Organization markup to the unambiguous references for you: Wikidata where one exists, official profiles, the canonical company registration page. Schema.org describes sameAs as the URL of a reference page that unambiguously indicates the item’s identity, and that is exactly the job it does here.
• Independent corroboration. Mentions in places you do not control: trade press, conference programmes, open-source contributions, industry bodies, genuine coverage. This is the slow half.
• A site that explains who you are. An about page with real people, a stated editorial policy, contact details that resolve to a human. Google’s guidance on trust is direct about “who, how and why” — who made this, how it was made, and why it exists.

Google names one anti-pattern explicitly: seeking inauthentic mentions of your brand across the web does not help. Paid mention farms, reciprocal citation schemes and comment spam are the link-building playbook wearing a new hat, and they have the same expected value they had a decade ago.

llms.txt, robots rules and whether to let the AI crawlers in

Two separate topics get conflated here. Take them in order.

llms.txt

llms.txt is a proposed file at your site root, in markdown, containing an H1 title, a summary blockquote and lists of links to clean versions of your key pages. It was proposed by Jeremy Howard in September 2024, and its stated purpose is to give agents concise expert-level information in one place rather than making them parse navigation, adverts and scripts. According to the specification site, OpenAI, Anthropic and Gemini publish llms.txt files for their developer documentation, and Chrome’s Lighthouse now audits for one.

Google’s position on it is unambiguous: llms.txt files are not used by Google Search, and they neither help nor harm your visibility there. No major engine has published documentation saying it uses llms.txt for retrieval or ranking.

So the honest summary is: it is cheap, it is harmless, it is well-suited to documentation sites where an agent genuinely benefits from a clean index, and there is currently no published evidence it improves citation rates anywhere. Publish one if you have a documentation site or an API. Do not build a strategy on it, and be sceptical of anyone who leads with it.

The crawlers, and what blocking each one actually does

This is the part with real consequences, because training access and search access are governed separately and people conflate them constantly.

Crawler	Operator	What it does	Effect of disallowing
Googlebot	Google	Crawls for Search, including AI Overviews and AI Mode	Removes you from Google Search entirely
Google-Extended	Google	Governs use of crawled content for Gemini training and grounding	No effect on Search inclusion or ranking
GPTBot	OpenAI	Crawls content for training generative models	Signals content should not be used in model training
OAI-SearchBot	OpenAI	Powers ChatGPT search	Sites opted out are not shown in ChatGPT search answers
ChatGPT-User	OpenAI	Fetches a page because a user asked for it	Blocks user-initiated retrieval of your pages
PerplexityBot	Perplexity	Indexes pages to surface them in Perplexity results	Removes you from Perplexity search results
Perplexity-User	Perplexity	Fetches a page a user’s question requires	Documented as typically ignoring robots.txt, being user-initiated
ClaudeBot	Anthropic	Crawls content for model training	Signals content should not be used in training
Claude-SearchBot	Anthropic	Indexes content to improve search results	Reduces eligibility to appear in Claude’s search results

Two decisions fall out of this table.

First, if you want to appear in assistant answers, allow the search-oriented crawlers: OAI-SearchBot, PerplexityBot, Claude-SearchBot and, obviously, Googlebot. Blocking these is the AI-era equivalent of noindex, and a surprising number of sites have done it accidentally by copying a “block AI bots” snippet from a forum.

Second, the training crawlers — GPTBot, ClaudeBot, Google-Extended — are a judgement call rather than a technical decision. A publisher whose archive is the business has a real argument for blocking them; a company whose website exists to be found by buyers usually does not, and blocking them buys nothing measurable. Decide it as policy, write down the reason, and make sure whoever edits robots.txt next knows which rule is deliberate.

One practical note: robots directives are honoured by well-behaved crawlers. If you need to prevent access rather than request it, that is a firewall and rate-limiting problem, and both OpenAI and Perplexity publish IP ranges so you can verify who is who.

Measuring AI visibility when there is no rank tracker

There is no position number for a synthesised answer, and no tool can supply one honestly. Google says plainly that no third-party tool has access to its internal ranking or AI systems. Anything presented as an “AI rank” is a sampled estimate from repeated prompting, which is a legitimate technique badly labelled.

What can actually be measured, in descending order of reliability:

1. Search Console’s generative AI performance report. Google now reports impressions from AI Overviews and AI Mode, broken down by page, device, country and date. Read the limits carefully: this report currently exposes impressions, and does not include clicks, click-through rate, average position or the queries involved. It also excludes Search Labs experiments.
2. Referral traffic from assistant hosts. Assistants that link out send identifiable referrers. Segment them in your analytics and you have a floor on AI-driven traffic — a floor, because every citation that was read without a click is invisible.
3. Server log analysis. Your logs show which AI crawlers fetched which URLs and when. This is the only direct evidence of whether your content is even reachable to a given engine, and it catches robots misconfiguration faster than anything else.
4. Sampled prompt testing. Maintain a fixed list of the questions your buyers actually ask, run them across the assistants on a schedule, and record which domains are cited. Answers vary between runs, between users and over time, so treat the output as a trend line and never as a rank. Change the prompt list rarely, or you are measuring a different thing each month.

The awkward truth is that this measurement stack is worse than the one we had for organic search, and will stay worse for a while. Plan reporting that survives that: report the business outcome, use AI visibility as a leading indicator, and resist building a dashboard around a number nobody can reproduce.

What has not changed, and probably will not

Strip away the acronym and the list of durable requirements is almost identical to what it was:

• Be crawlable and indexable. Everything else is downstream of this.
• Be fast and stable enough that a reader who arrives from an answer stays. Core Web Vitals are still the measurable proxy.
• Publish things that are worth citing, which mostly means things only you can say.
• Say who wrote it, how, and why. Trust is the part of E-E-A-T that carries the others.
• Structure content so a reader — or a retrieval system — can find the answer without reading everything.
• Do not manufacture scale. Generating many pages to capture query variations is a documented spam pattern, and it is now also the thing a model does better and cheaper than you.

If a GEO proposal contains nothing from this list, it is not a strategy.

A retrofit plan for a site you already have

Assuming a site with real content that already gets some organic traffic, this is the order we would work in. It is deliberately front-loaded with the cheap things.

1. Audit robots.txt for accidental blocks. Confirm which AI crawlers you allow and whether that matches an actual decision. This takes an hour and is the single most common self-inflicted wound.
2. Fix render-blocking content. Anything that only exists after client-side JavaScript is invisible to some retrieval systems. Check what is in the raw HTML.
3. Rewrite the opening block under each H2 on your twenty most important pages so it answers the heading directly. No other change. This is the highest-yield editing work available.
4. Make headings into real questions where the content genuinely answers one, and remove headings that label a section without describing it.
5. Find the passages worth citing, and add them. For each important page, ask what it contains that no competitor’s page contains. If the answer is nothing, that is the brief for the next revision, and it is a content problem rather than a technical one.
6. Tidy the entity layer. Organization markup with accurate sameAs references, consistent naming across profiles, an about page with real people and a stated editorial policy.
7. Validate structured data on your key templates — for rich results, not for citations.
8. Set up measurement before you change anything else. Search Console’s AI report, a referral segment, a log query, and a fixed prompt list with a baseline recorded.
9. Publish the sub-answers you are missing. Use query fan-out as a planning tool: for each priority question, list the sub-questions a system would decompose it into, and check whether you answer each one somewhere.
10. Leave it alone for a quarter. These systems change, sampling is noisy, and reacting weekly to a metric with this much variance produces motion rather than progress.

None of the above requires an agency. It requires someone with editorial judgement, access to the CMS and server logs, and the discipline to do the boring items first. If you would rather it were someone else’s job, that is what our generative engine optimisation and broader search work covers — but you should know that the work looks like the list above, because anyone describing something more exotic is describing something they cannot evidence.