Blog · Foundations

How an AI answer is assembled, step by step

Published 8 September 2026 · Updated 12 October 2026 · 9 min read

How an AI answer is assembled, step by step
Photograph: Natalia Y. / unsplash

The short answer: Four stages, in order, in the one pipeline that is documented. Google describes its AI features as rewriting one question into a set of related queries, retrieving candidate documents for each, cutting those documents into passages and keeping a handful, then drafting prose from what it kept and attaching citations afterwards. A brand can be dropped at any of the four, and the fix is different at each one. For the assistants that publish no equivalent description, treat the four stages as a diagnostic frame, not a specification.

Most advice about AI search skips straight to the last stage and talks about writing. The earlier three decide whether your writing was ever in the room.

Stage one: your question becomes several questions

Google's AI features do not search only for what the user typed. Google defines the mechanism in its own guidance as query fan-out, "a set of concurrent, related queries generated by the model to request more information and fetch additional relevant search results", and the worked example on that page turns one question about a weedy lawn into three separate searches about herbicides, chemical-free removal and prevention. That is Google documenting Google. The other assistants publish no comparable definition, and the queries they generate are not shown to a publisher, so fan-out elsewhere is a reasonable working assumption rather than a sourced fact.

On Google at least, that single mechanism explains a lot of odd behaviour. You can be absent from an answer about a topic you own, because the fan-out never produced the phrasing your page is built around. You can also appear in an answer to a question you never targeted, because one of the generated queries happened to match a paragraph buried in a support article.

So the unit of planning is no longer the keyword. It is the family of questions a buyer asks around a decision, which is why a prompt set for an audit runs to around 45 prompts rather than a handful of head terms.

Stage two: retrieval picks candidates, usually from an index

Retrieval is where loss happens without leaving a mark in an analytics dashboard, and it is less mysterious than it looks. Google describes the mechanism plainly: retrieval-augmented generation, or grounding, leans on the core Search ranking systems to pull relevant pages from the Search index, and its eligibility rule for AI features is that a page is indexed and eligible to be shown with a snippet. For Google Search that means no separate AI index and no separate submission. Whether the other engines maintain an index of their own is not something a publisher can check from outside. If you have suppressed snippets with nosnippet, data-nosnippet or a tight max-snippet, you have also limited what the AI features can show, because the same preview controls govern both.

Assistants outside Google split the job across different agents, and the distinction is worth knowing before you edit a robots file. OpenAI documents four: GPTBot for model training, OAI-SearchBot for appearing in ChatGPT search answers, OAI-AdsBot for ad landing pages, and ChatGPT-User for fetches a person triggered by asking about a specific link. Blocking the training crawler and keeping the search crawler is a supported position, not a clever hack. Each of the four has a published IP address file, so a server log can be checked against the real thing rather than a spoofed user agent string. OpenAI also notes that a robots.txt change takes roughly 24 hours to register in their search systems, which is long enough that people change a rule, re-test the same evening, and conclude wrongly that it did nothing. Those agent names, those IP files and that 24 hour note are OpenAI's and apply to OpenAI. Each operator splits and documents its crawlers differently, so the robots file you write is a set of per-operator decisions, not one policy.

Two failure modes dominate this stage. A page that is not indexed cannot be grounded against. A page whose content arrives only after client-side JavaScript runs may be retrieved and then read as near empty.

Stage three: the page becomes passages, and position inside them matters

A whole site is not passed into a model. The general shape of a retrieval pipeline is well known: documents get cut into chunks, a reranker keeps the few that look most relevant, and those survivors are packed into a context window alongside chunks from other sites. Chunk boundaries, reranker behaviour and window budgets are not published by the engines we test, so that is the shape of the pipeline rather than a description of any one of them. Google's own guidance says you do not need to shred your content into tiny pieces for this, which is correct and often misread: you do not control the chunking, so what you control is whether each section stands up on its own.

There is a reason to care about where your claim sits, though the evidence is narrower than the advice built on it. Salvatore, Wang and Zhang, in "Lost in the Middle: An Emergent Property from Information Retrieval Demands in LLMs" (arXiv preprint, 11 October 2025), reproduce the U-shaped recall curve in GPT-2 and Llama variants trained from scratch on two simple human memory paradigms, with material at the start and the end recalled more reliably than material in the middle. That is a finding about those models under those training conditions. Whether a production answer stack shows the same curve is not something anyone outside the engine can measure, so read it as a good reason to put the claim first rather than as a property of the system you are trying to appear in.

This is the mechanical argument behind answer-first writing. A section that opens with the claim survives being cut, lifted and placed anywhere in a context window. A section that opens with three sentences of throat-clearing hands the engine a chunk whose useful half may have been severed, or buried where recall is weakest.

A check you can run this afternoon: take any page you want cited, delete every heading, and read the first two sentences under each former heading in isolation. Any sentence that only works because of the paragraph above it will not survive chunking. That is a rewrite job, not a technical fix.

Stage four: the answer is written, then the citations are attached

The last stage is the one everybody pictures, and the least useful to optimise directly. The model drafts from the kept passages, then links are matched back to the text. How that matching works is not documented, and we cannot watch it happen. What a reader can see is the symptom: a cited page sometimes does not contain the sentence it appears to support, and a brand can be named in an answer with no link to its own site at all. Both are consistent with attachment coming after drafting rather than during it, which is inference from output, not a mechanism anyone has shown us.

Two things follow. First, a mention and a citation are different outcomes and should be counted separately. Second, because sampling and retrieval both vary, the same prompt run twice can produce a different source list. That is the whole subject of why an answer changes between two identical runs, and it is the reason a screenshot of one run is not evidence of anything.

The deeper issue is that being read and being visited have come apart, at least at some platforms. Cloudflare began publishing a crawl-to-refer ratio on Radar on 1 July 2025, dividing HTML requests from a platform's crawlers by HTML requests carrying that platform's referrer. For the week of 19 to 26 June 2025 it reported a spread across platforms from 0.1 crawls per referral at the low end to 70,900 at the high end, so the gap is not a single industry number but a per-platform one. Their own write-up cautions that native app traffic carries no referrer header, which undercounts referrals and inflates the high ratios by an amount they say is unclear. Your own site is not in that table, so the ratio that matters to you is the one in your server logs next to your referral data.

Where each stage breaks, and the check that catches it

Map the four stages to four questions and the diagnosis gets fast.

Fan-out. Does the family of questions around the decision exist on your site in any form. If not, no retrieval step can save you.

Retrieval. Is the page indexed, snippet-eligible, served as HTML, and reachable by the specific agents you want. Where the operator publishes IP ranges, check the logs against those rather than against the user agent string, which is trivially spoofed.

Passage. Does each section answer its own heading in the first two sentences, with the specifics attached.

Draft. Are you named, is the claim next to your name true, and does a link come with it.

That ordering matters because the layers are not equally hard. Access problems are cheap and fast. Identity and corroboration, the other two layers described in what answer engine optimisation is, are slower, and the corroboration layer is the part you do not own at all. That split between what you own and what you rent is covered in rented visibility versus owned visibility, and it decides where money is worth spending first. If you want to test the first two stages yourself before anyone is paid, the self-check is ten things you can run with no tooling.

Honest limits

The thing to challenge first is the scope: this is one documented pipeline presented as a frame for several. Fan-out, grounding, the snippet eligibility rule and the structured data line are Google's, published for Google Search, and the four crawler names, the IP address files and the 24 hour robots.txt note are OpenAI's, published for OpenAI; we have found no equivalent documentation for the other assistants, and that absence tells you nothing about whether they behave the same way. Reranker internals, chunk boundaries and the citation attachment step are published nowhere we can read, so every sentence here about why one passage beat another is inference from output, and fan-out queries are rarely exposed, so we reconstruct them from which pages got cited. The stages also blur: some systems fetch live pages mid-answer rather than relying only on an index, and the conditions under which they do are not documented. No figure in this post is a measurement of ours, and we are not publishing a rate for post hoc citation mismatch because we have not counted one in a way an auditor could reproduce.

FAQ

Does an AI answer come from the model's training or from the live web? Both, mixed. Grounded features retrieve current pages at answer time and write from those, while the model's prior training shapes phrasing and fills gaps. A brand that exists only in training data can be named with outdated facts and no citation.

Why does my competitor get cited when my page is better? Usually one of the first three stages, not writing quality. Their page matched a fan-out query you did not anticipate, or your page was not retrievable, or your relevant claim was in a chunk that did not survive selection.

Do I need structured data to appear in AI answers? Google's guidance says structured data is not required for its generative features. It still helps machines resolve what your entity is and how your pages relate, which matters for the identity work, so the honest answer is useful but not a gate.

Should I block AI crawlers? Separate the crawlers before deciding. OpenAI documents distinct agents for training and for search and says that allowing one while blocking the other is a supported position, and the two have different consequences: one affects future models, the other affects whether you can be cited this week. Other operators name and split their crawlers differently, so read each one's own documentation before copying a rule across.

Sources

Related reading