LLM SEO: how models actually find and cite your content

LLM SEO is the practice of making your content retrievable and quotable by large language models. The part almost every guide skips: models do not retrieve pages. They retrieve fragments of pages, and the fragment is the unit you are competing with.

We read the five best-ranking articles on this term before writing. Not one of them explains how a page becomes a retrievable fragment, and not one cites a single piece of documentation from the companies that build these models. This article does both. If you would rather hand the work over, that is what our SEO team does, but the mechanics below are worth knowing before you buy anything.

What this is, and what it is not

LLM SEO, LLMO, GEO and AEO are overlapping labels for the same shift. We are not going to relitigate the vocabulary here. If you want the definitions, we have written them properly: what generative engine optimization is and what answer engine optimization is, plus the wider AI search optimization picture.

This piece is narrower and more useful: what physically happens to your page between a person asking a question and a model citing you, and what that implies for how you write.

Sources and further reading

Every technical claim below is traceable to a primary source. We have named each one so you can check it.

1. Google Search Central: AI features and your website (official documentation).
2. Google: List of Google’s common crawlers (official documentation).
3. OpenAI: Overview of OpenAI Crawlers (official documentation for GPTBot, OAI-SearchBot and ChatGPT-User).
4. Lewis et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 (the paper that named RAG).
5. Microsoft Learn: Chunk large documents for RAG and vector search in Azure AI Search (official documentation).
6. Aggarwal et al.: GEO: Generative Engine Optimization, KDD 2024.

That second clause is the whole article in one line. A page gets split not only because it is too long, but because a page about six things is badly represented as one thing. If your page tries to cover everything, it represents nothing sharply, and it loses to a page that covers one thing cleanly.

There are two ways a model can know about you

They work on completely different timescales and you optimize for them differently.

Training. Your content was in the corpus when the model was trained. This is slow, it is frozen until the next training run, and nothing you publish today affects it for months. You cannot be cited with a link this way, because the model is recalling rather than reading.

Retrieval. The system fetches live content at the moment someone asks. This is where citations and referral traffic come from, and it is the one you can actually influence this quarter.

OpenAI documents this split explicitly, and the distinction is visible in its crawlers: GPTBot is the one whose content “may be used in training our generative AI foundation models”, while OAI-SearchBot exists “to surface websites in search results in ChatGPT’s search features”. Those are separate permissions. A site can allow one and block the other, and blocking the wrong one is a quiet way to disappear from ChatGPT’s answers while believing you only opted out of training.

Most budgets get spent as though the first column were the target. Almost all of the available leverage sits in the second.

Your page is not the unit of retrieval

Here is the mental model to replace. You do not have a page competing against other pages. You have a set of fragments competing against other fragments, and most of yours will never be considered at all.

Before anything can be retrieved, documents get split. The RAG paper that named the technique did it bluntly: “Each Wikipedia article is split into disjoint 100-word chunks, to make a total of 21M documents.” Production systems have grown more sophisticated since 2020, but the principle is unchanged. Microsoft’s guidance for its own retrieval product recommends “starting with a chunk size of 512 tokens (approximately 2,000 characters) and an initial overlap of 25%”.

Roughly 2,000 characters. That is a long paragraph or a short section. It is not your article.

Which means the practical question stops being “is my page comprehensive” and becomes “will any single 2,000-character window of my page answer a question on its own, without the rest of the page around it”. Most content fails that test, because most content is written to be read top to bottom by a human who already has the context.

The last row is not hypothetical. One of the best-ranking articles on this exact keyword presents its central comparison as a JPEG. Its argument about being readable by machines is, itself, unreadable by machines.

What happens between the question and the answer

The chain has more steps than most guides admit, and every step is a place to lose.

1. The question is expanded. One prompt becomes several searches. Google documents this plainly, saying its AI surfaces may use “a ‘query fan-out’ technique, issuing multiple related searches across subtopics and data sources”. You are not competing for the question the user typed. You are competing for a handful of sub-questions you never see.
2. Candidates are retrieved. Chunks are compared against each sub-question by meaning rather than exact wording, and the closest ones come back.
3. Candidates are narrowed. Far more is retrieved than can be used.
4. The survivors go into the context window. This is the bottleneck nobody writes about. The model only sees what fits. Being retrieved is not the same as being used.
5. The answer is generated, and some sources get named. Being in the context window is still not the same as being cited. Usually the clearest, most quotable fragment wins the citation.

Four filters sit between your publish button and your brand name in an answer. Content that is merely good tends to die at step two. Content that is good and extractable survives to step five.

Say the same thing the same way everywhere

Retrieval works on meaning, so the model needs a stable idea of who you are. When your company describes itself three different ways across your site, your schema, your directory listings and the press that mentions you, that does not read as one strong entity. It reads as several weak ones.

The unglamorous version of this work: one name, spelled and cased identically everywhere. One canonical description. The same service names on the service pages as in the schema as in the directories. Consistent naming for your own concepts and products, rather than three synonyms because repetition felt clumsy. Human editors reward variety. Retrieval systems punish it.

This overlaps heavily with ordinary structured data hygiene, which we cover in schema markup for AI.

Does schema markup help? Let us settle it

This is the loudest disagreement in the category. Most guides on this keyword tell you to add schema for AI. One major publisher removed that advice from its own article and said the opposite. Neither side cites anybody.

Google’s documentation answers it directly. On AI features, Google states: “You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.” The same page says there are “no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary”, and that to be eligible a page “must be indexed and eligible to be shown in Google Search with a snippet”.

Read that carefully, because it cuts both ways. There is no magic AI markup, and anyone selling you one is selling you nothing. But eligibility for Google’s AI surfaces runs straight through ordinary indexing and snippet eligibility, which means the boring technical work still decides whether you are in the running at all.

So: keep the schema you have, because it earns its place in search regardless. Do not add exotic markup on the promise that a model wants it. And treat any advice that skips this documentation as what it is, a guess.

What the research actually found

There is one peer-reviewed study people cite constantly and describe carelessly. The GEO paper, presented at KDD 2024, tested content changes and measured how visible the changed content became inside generative answers.

Its own summary: the authors “demonstrate that GEO can boost visibility by up to 40% in generative engine responses”. The methods that worked were adding quotations, adding statistics and citing sources. The method that did not work was keyword stuffing, which the paper found performed worse than doing nothing.

Two honest caveats, because they are always dropped. That 40% is visibility inside generated answers on the researchers’ own benchmark, measured with an automated scorer. It is not traffic, and anyone converting it into a traffic promise has left the evidence behind. And “up to” is doing real work in that sentence.

The writing rules that follow from all this

Not best practices. Consequences.

1. Front-load every section. The chunk may be cut before your build-up pays off. Claim first, evidence second.
2. Write sections that survive removal. Take any section out of the article, read it cold, and see whether it still answers something. If it does not, it will not be cited.
3. Kill the pronouns at section starts. Name the subject again. It reads slightly repetitive to a human and it resolves cleanly for a machine.
4. Put every number in the prose. If a figure only exists in a chart, it does not exist.
5. Give things one name. Pick your terminology and never vary it for style.
6. Add quotable material. This is the one tactic with peer-reviewed support: real quotations, real statistics, real attributed sources.
7. Split pages that cover too much. If a page has five loosely related sections, it is five mediocre representations pretending to be one good page.
8. Check your crawler permissions. Know which bot you have allowed and what each one actually controls. Training and live search are separate doors.

How to tell whether any of it is working

Rankings will not tell you, because there is no ranking. The honest measurement set is narrower than the dashboards suggest.

• Citation rate. Run a fixed set of real buyer questions on a fixed schedule and record how often you appear. Same prompts, same cadence, or you are measuring noise.
• Which page gets cited, and which section of it. This is the signal that tells you whether your chunking work landed.
• Referral traffic from assistants. Small, growing, and only available from the retrieval pathway.
• Branded search volume. The lagging indicator that catches the training pathway and the answers that never link to you.

Our longer treatment of the tracking side is in how to measure AI visibility.

Where to start

Take your most important page, delete everything except one section, and ask whether that section still answers a real question on its own. Then do it again with the next section. Whatever survives is what a model can use, and the gap between that and the full page is your actual work. If you want that done across a site rather than a page, see how we run AI visibility and GEO programmes, or talk to us.