How AI Search Works: The Five-Stage Answer Pipeline

Most GEO advice treats an answer engine as a black box you can flatter. It is not a box. It is a five-stage pipeline, and your page dies at one specific stage. Usually the second.

Stage one: the question you optimized for was never typed

Someone asks your buyer's question: what is the best CRM for a small agency?

That sentence is not what gets searched. The system breaks it into several narrower machine queries, then runs them at the same time.

All of them. At once.

Google names the mechanism in its own developer documentation: query fan-out. Their definition: "a set of concurrent, related queries generated by the model to request more information and fetch additional relevant search results to address the user's query."

Their worked example is a lawn full of weeds (their choice, not ours). Google says the fan-out queries "might include" best herbicides for lawns, remove weeds without chemicals, how to prevent weeds in lawn.

One question in, at least three out. An example, not a count. Your keyword tool shows you none of it. Not one.

Look again at the CRM question. Which half is doing the work? "For a small agency."

Conversational prompts carry qualifiers a keyword never carried: segment, price band, region, headcount. Those become filter conditions inside the sub-queries.

So your passage has to state the qualifier inside the span. "For teams under 25 seats." "In the EU."

Leave it out and you fail every constrained sub-question, while looking perfectly optimized for the unconstrained one. Which is the one nobody asks.

A Google search engineering director put the scale plainly. AI Mode "is basically doing a dozen searches for you in the time it takes to do one." That was Dounia Berrada in March 2026, talking about an uploaded photo.

A dozen. For a picture.

The other engines document less. Most write-ups get this wrong. Read what they actually say:

• OpenAI: when ChatGPT search partners with an outside provider, it "typically rewrites your query into one or more targeted queries." What it does with its own index is unpublished.
• Anthropic: "Simple factual queries typically use 1-3 searches." And: "comparative or multientity research can use 10 or more."
• Perplexity: its Search API accepts up to five queries per request. That is a request-batching cap, not a fan-out count.

No vendor publishes a per-prompt fan-out count. Anthropic's 1-3 versus 10-or-more is the closest anyone comes, and that is a range. Measured figures move month to month.

So do not build your strategy on a number.

Build it on the one fact that holds: your buyer's question is not the query. The number is greater than one.

How to generate the fan-out

Every GEO article tells you to map the fan-out. None tells you how. Three methods exist, and they are not equal:

Method one: observe it. Bing Webmaster Tools publishes grounding queries: the phrases its AI actually used when retrieving content to cite. It is the only observed fan-out data tied to your own pages. Gemini's API also returns the queries a model executed, but not against your site.

Narrow: Bing, Copilot and select partners. Bing calls it a sample, not the full picture. But real. Chapter 3 covers the setup.

Method two: proxy it. Google's people-also-ask boxes are a rough shadow of the same decomposition. Broad and free. Only loosely connected to what an AI system generates.

Method three: model it. Ask a model to decompose the query the way a retrieval system would. Three properties: reproducible, cheap, and unvalidated against any engine's real behavior.

Use all three.

Method three is your workhorse, so here is the prompt in full:

You are a retrieval system preparing to answer a user question.
Before answering, you decompose the question into the separate
factual sub-questions you would need to look up.

User question: "[QUERY]"

Return only the sub-questions, one per line, no numbering and no
commentary. Rules:
- Each sub-question must be independently searchable.
- Each must be answerable by a single passage of text.
- Do not include the original question.
- Do not include sub-questions a general knowledge base already
  answers without retrieval.
- Include at least one comparison, one constraint or limitation,
  and one cost or effort sub-question, if they are relevant.
- Stop at 8.

Run against "best CRM for a small agency," the intersection comes back looking like this:

Then do the part everyone skips. What do you actually cover? Most teams have never counted.

Mapping sub-questions to pages

This is the expensive step, and where readers stall. Do it mechanically before you do it by hand.

1. Run each sub-question as a site: query in Google and take the top result.
2. Cross-check against Search Console. Filter queries containing the sub-question's head noun, take the page with the most impressions.
3. Where the two disagree, the page Google actually serves wins.
4. Where neither returns anything, score zero and record it as a gap. Do not go hunting for a page.

Then apply one test to each pairing:

Chapter 1's cut test (Figure 1.1), with a number on it: does a passage of 60 words or fewer answer this sub-question on its own? Nothing borrowed from the H1. Nothing borrowed from the line above.

No engine publishes a passage-length threshold. Sixty is ours. Anthropic's API returns up to 150 characters of cited text (about 25 words), and snippet extracts cluster around 40 to 50. Sixty is deliberately generous.

Use a different number if your category argues for one. Just use the same number every time: the value of the test is comparability, not precision.

Pick it once. Never move it.

Score one or zero. No partial credit: a passage that needs its H1 to make sense is not half-retrievable, it fails when it is cut out.

Twenty-five priority queries, six sub-questions each: 150 → 150 binary answers.

That is a full day of your attention, so do not spend it. Score with a model and audit by hand.

Give it three things: the sub-question, the candidate page's text, and the rule. Ask it to return the exact span it would use and that span's word count, or NONE.

Then hand-check 15%. You are checking for the failure the model makes most: silently borrowing the H1.

Returning the span rather than the verdict is what makes the audit cheap. Without it you are grading a grader.

Below 40% coverage the problem is structural. New articles will not fix it. Forty is our line, not a published threshold. Where does yours land?

Below 40%, the fix is not publication. It is surgery on pages you already have.

Take the twenty zero-scoring sub-questions with the highest revenue attribution. For each: add one self-contained span of 60 words or fewer to the page that already ranks nearest, under a heading that restates the sub-question.

Twenty edits, not twenty articles. Testable in one crawl cycle. What is your team proposing instead?

Commission new pages only where no existing page is even topically adjacent.

Stage two: retrieval is a recall problem

Long before the model reads a word, the engine goes looking. That means one of four things: a live web index, a cached crawl, an internal vector store, or all three.

Depends on the engine. Nobody tells you which.

It never means all of the web.

Not close.

Perplexity is the only consumer answer engine that has published an end-to-end description of its own live retrieval stack. Read it closely.

The corroboration is structural rather than editorial. Every commercial retrieval API exposes chunk-level results and a top-k parameter. A design fact, not a vendor claim.

They query the index two ways at once (lexical and semantic), then merge into a hybrid candidate set. Chapter 3 covers how big that index is and who feeds it.

Then they winnow: fast scorers first, heavier cross-encoder rerankers on the survivors. Cheap filters, then expensive ones.

One sentence in that paper matters more than the rest.

Perplexity says they decompose documents into "self-contained spans, each of which can be individually retrieved and ranked at query time." They score at two levels. The document, and the passage inside it.

The passage is the unit that wins or loses.

Not the page.

What decides where a passage begins and ends? Chapter 4. For now, only the consequence matters.

They also explain why they abandoned third-party search APIs. The old ones "prioritized document-level results, to the exclusion of more fine-grained information revealed by sub-document units."

Which is the whole argument of this book. Written by a search engine, about itself.

The arithmetic is what kills your pages. A retriever pulls a bounded pool per sub-query, and the bound is a documented parameter in every one of these APIs (top_k, max_num_results). Everything outside it is invisible for the rest of the process.

And no amount of domain authority rescues a page that was never retrieved. None.

This is where your SEO instincts mislead you. Position eight on Google is a bad day. Position eight in a pool of ten is survivable in a way position eight on a SERP is not.

Survivable, not equivalent. Where you sit in the assembled context still affects whether the model leans on you. A published effect, not a vendor claim.

Position 200 with a beautiful page? Nothing at all.

How a dozen result lists become one pool

A dozen sub-queries produce a dozen ranked lists. Something has to merge them. The merge is where cluster coverage stops being a slogan.

The standard published method is rank fusion: score each document by summing a function of its rank across every list it appears in.

No engine names the fusion method it uses. But the family has been standard in information retrieval since 2009, and every hybrid stack needs one. Perplexity has to merge its lexical and semantic lists somehow.

The arithmetic is the point. Under rank fusion, a page sitting at position five across six sub-query lists beats a page ranked first in one. Fused score accumulates across lists.

Which is why a coverage score is the right instrument and a rank check is not. Breadth compounds. Depth in one place does not.

What semantic retrieval does to keyword coverage

Hybrid retrieval means the match is part lexical, part semantic. No vendor publishes the weighting. Everyone nods at the idea, then keeps writing as though only the lexical half exists.

Does yours?

Here is the consequence.

It inverts a decade of your content briefs.

Under embedding-based retrieval, five paraphrases of the same claim add little. They land close together in vector space, so they compete for one slot rather than occupying five.

Diversity re-ranking exists precisely to stop a pool filling with near-duplicates (it discards yours too). Five becomes one.

Expressing a claim in your buyer's vocabulary rather than your own is different work. Two reasons: the lexical half of hybrid retrieval still matches on words, and a real change of framing is a change of proposition rather than a synonym.

Not the same edit at all.

Your buyers do not search for a revenue operations platform. They search for a way to stop the sales team arguing about which number is right.

Those are not two names for one thing. They are a category and a pain, and they attract different queries.

The mechanism is published, just not by vendors. Near-duplicate suppression and maximal marginal relevance are decades-old information retrieval.

And you can test it before lunch. Embed your five paraphrases and four genuine reframings with any off-the-shelf embedding model, then print the pairwise cosine distances.

The paraphrases will cluster. The reframings will not.

That is the whole argument. Twenty lines of code.

Your old brief said one thing: use the target keyword and its variants n times. The useful brief says something else entirely.

Name the same claim once in each vocabulary your buyers actually use. Their words. The analyst's words. The competitor's words. The regulator's words.

Not synonyms: different framings of the same fact. Can your brief tell the difference?

Stage three: the cut nobody sees

Re-ranking cuts the pool to what will actually be read. Cross-encoders, freshness, source diversity, and whatever else each vendor trained on their own product signal.

Perplexity says its ranking model learns from live answers, so every answer they generate is a datapoint about search quality.

Nothing useful is published about the weights. Not one vendor.

So anyone telling you the ranking factors for Perplexity or ChatGPT is describing a model they built, not a system they observed. Ask which one. Watch what happens.

What is observable is the attrition. How steep? One 2026 study measured it directly.

Before the numbers, the constraint that produces them. Every stage costs tokens and milliseconds. An answer has a unit margin and a latency budget of a few seconds.

So retrieval depth is set by margin, not by capability.

Which is the likeliest explanation for 757 of 759. Opening a page is the most expensive operation in the pipeline: it shows up where the budget exists and vanishes where it does not.

Not a quirk of one product's interface. That is what an evidence budget looks like from the inside.

Stage four: the context window is the real results page

This is the stage nobody plans for. Including you.

The surviving passages get pasted into the model's context window next to the original question. Then the model is told one thing: answer using these.

That window is your competitive surface. An evidence budget far smaller than the corpus, where your paragraph sits beside a competitor's, a Reddit thread and a review site. Your design is gone. Your navigation is gone. Your brand is a word in a wall of text.

A passage that only reads clearly in the context of its page becomes ambiguous here. A passage that opens with its subject, its claim and its limits survives.

Same words. Different fate.

The finding everyone quotes, and the part they leave out

The same study followed what happened to those 61,332 URLs. A page the model opened was cited 74% of the time. A page retrieved but never opened: 7%.

A tenfold gap. It is the most quoted number in GEO right now. Quoted badly, almost every time. Including by people selling you audits.

So what gets left out? Two things:

757 of the 759 opens happened in thinking mode. Two free-tier conversations opened one page between them. In the default free path, opening is effectively absent.

So "get opened" is advice about a slice of one product's traffic. Not a law.

The causality runs both ways, and nobody has tested which dominates.

Reading one: opening causes citation. The model reads you properly, understands you, cites you. Simple.

Reading two: opening is a symptom. The model opens pages whose snippet already looked decisive. The snippet did the work, and the open is what a decided model does next.

Reading three: neither. Something else causes both: domain trust, freshness, a preferred-source list. Your passage is along for the ride.

That is the reading that would actually cost you, and 74-versus-7 cannot rule it out. The opened pages were never a random sample. Nothing was controlled.

We think reading two is closer to the truth: a system optimizing for cost does not open pages at random. But we cannot prove it. Neither can anyone selling you an "AI crawlability" audit on the strength of that number.

So does it matter which? Barely.

The first two readings produce the same instruction. Opening causes citation? Make the passage worth opening. Opening is a symptom of a decisive snippet? Make the snippet decisive. The snippet is a span of your page.

And under the third reading? A self-sufficient span is still the only part of this you control.

Same work either way: make the retrievable span self-sufficient.

When two explanations demand the same action, stop arguing. Take the action.

Do the study's own arithmetic

Before you act on the 74%, multiply it out. Nobody does, and the result changes the instruction.

759 opens, cited 74% of the time: about 560 citations. The 60,573 never opened, cited 7%: about 4,240.

That totals roughly 4,800 against the 5,032 lead sources the study reports. The numbers reconcile. Worth knowing, about a study everyone quotes and nobody checks.

Now look at what the reconciliation says. Roughly 88% of citations came from pages the model never opened.

Being opened multiplies your odds tenfold, on a base of one percent. Almost every citation in that dataset was won by a snippet.

Not by a crawl.

So where does your Monday go? The retrievable span. Not the crawlability audit.

What plausibly earns the open

Nobody publishes this. What follows is a hypothesis, not a ranking factor. Two things we would bet on:

• Answerability: the passage resolves the sub-query on its own, without the rest of the page.
• Recency: where the question implies currency, old passages get downweighted hard.

Two more, attributability and corroboration, belong to Chapter 8. They are about the web around you rather than the page in front of you.

Here is the test, because a hypothesis without one is an opinion with better manners. Take ten sub-questions where you are retrieved and never cited. Rewrite five to be answerable standalone and leave five alone. Re-measure at 30 days. If the rewritten five do not move relative to the control, the hypothesis is wrong in your category.

Test them on your own category first. Then believe them.

Stage five: the part you do not control

Synthesis belongs to the machine. You cannot influence phrasing or ordering. You cannot decide whether the model quotes you by name or absorbs your point silently (unattributed, in its own words).

That part is not yours.

You can see the shape of the constraint in the developer documentation:

• Anthropic returns a truncated excerpt of cited text per source, not the passage Claude actually read.
• Perplexity lets a developer cap how many tokens are extracted from each result page.
• OpenAI notes that the number of sources consulted is usually larger than the number of citations shown.

The first two say the same thing: a small amount of your page reaches the answer, and you do not choose which part.

Far more sources get consulted than ever get shown. OpenAI says so itself.

Why this shape outlasts the products

The obvious objection to a chapter like this: every one of these systems gets retrained and reshipped every few months. So why restructure 40 of your pages against an architecture that may be gone before the work ships?

Fair enough. And the pipeline will change. Fan-out counts will move, rerankers will be replaced, someone will ship an architecture nobody has described yet (probably this year).

What will not change is the constraint that produced this shape.

A model's context is finite next to the web, and retrieval is not free. So a system must always reduce a corpus it cannot read (the web) to an evidence budget it can.

That is the whole constraint.

Context windows have grown far faster than the web. If capacity were all that mattered, the retrieved unit would drift upward: span, then section, then whole document. This chapter would age badly.

It will not, and the reason is economic rather than physical. The binding constraint is cost per answer. And cost per answer is a competitive variable in a market where somebody is always undercutting you.

A system can afford to read whole pages. It cannot afford to read whole pages a billion times a day at a margin.

We have not found a deployed design that resolves it any other way. Cut documents into smaller units. Score the units. Keep a few. A design that reads whole pages end to end can only do that for a handful of pages, which is the same selection problem one level up.

Which is why the advice here is older than the technology. Make a passage that answers one question completely and survives being cut out of its page.

That was correct for the featured snippet in 2016. It is correct for a cross-encoder in 2026. It should hold for whatever replaces both, for as long as evidence budgets stay small next to the corpus.

One honest defeater, because the argument has one.

All of this assumes the evidence budget fills with text you wrote. It need not.

A system can pre-process the corpus offline into its own representation: index-side summaries, extracted claims, an entity store. Chapter 3 documents ChatGPT already storing a converted copy of fetched pages, stripped and cached for 90 days.

If the budget increasingly holds the engine's distillation rather than your prose, span craft becomes the floor and being the consensus across many sources becomes the game. That is Chapter 8, and it is a different discipline.

The objection that actually deserves your attention

Architecture obsolescence is the weak objection. Here is the strong one.

Citation may stop being the outcome worth winning.

If assistants increasingly act rather than answer, the winning asset is a machine-readable offer: feed, API, price, availability, verifiable spec. Booking, comparing, filtering against constraints.

We think the passage work survives it. An agent filtering on constraints still has to read a claim about your product from somewhere. And an unbounded qualifier is as useless to an agent as to a model.

But the hedge is real. If your category is one where an assistant will transact, the structured data work in Chapter 7 is not a supporting act.

Architectures expire.

Evidence budgets do not.