Retrieval augmented generation picks its sources by scoring passages, not pages, against a rewritten version of the question, and then narrowing that shortlist twice more before anything reaches the model. Four stages, each running on a different rule. Two of them respond to work you can do and two of them are vendor decisions you will never touch.
Most advice about this skips straight to the last stage and tells you to write better content. That is not wrong, it is just aimed at the wrong place. If your passage never survives stage one, nothing about its quality matters, because no model ever reads it.
Stage zero: your question is not the query
The prompt a person types is rarely the string that hits the index. Before retrieval runs, the system rewrites it, usually into several queries at once. A question like what should we use instead of Salesforce for a twelve person team becomes a handful of narrower searches covering alternatives, small team CRM pricing and migration.
This matters more than it sounds. You are not competing for the phrasing the buyer used. You are competing for phrasings generated by a model that has its own habits, and those habits lean plain. Marketing language survives rewriting badly. The flattest version of what you do is the version that matches.
A cheap test. Take the question you most want to win. Write down the four most literal, boring searches somebody would run to answer it. If your page does not obviously match at least two of those, you are optimised for the question rather than for the queries it becomes.
Stage one: candidate retrieval, where most pages die
Two systems run here, usually in parallel, and they fail in completely different ways.
Lexical retrieval scores overlap between the words in the query and the words in your passage, weighted so rare words count more than common ones. The standard implementation is BM25, which has been the default for about thirty years and remains hard to beat on exact terminology. It finds you when somebody searches your product name or a precise technical term. It misses you entirely when the buyer uses a synonym you never wrote down.
Dense retrieval embeds both the query and your passage into vectors and compares them by distance, so it matches meaning rather than words. The approach that made it practical for open domain question answering was dense passage retrieval, and it is why you can now be retrieved for a question that shares no vocabulary with your page. It is also why you can be retrieved for a question you never meant to answer, which is its own problem.
| Lexical (BM25 and relatives) | Dense (embeddings) | |
|---|---|---|
| Matches on | Word overlap, rare words weighted higher | Meaning, as represented in vector space |
| Strong at | Product names, error codes, exact terminology | Paraphrase, synonyms, implied questions |
| Blind to | Synonyms you never wrote | Precise strings it has compressed away |
| Fails by | Missing you | Retrieving you for the wrong question |
| You improve it by | Using the words buyers use, including the ugly ones | Making one passage about one idea |
The practical consequence is that a passage needs to be lexically recognisable and semantically coherent at the same time. Use the buyer’s actual words, including the unfashionable ones your positioning deck removed, and keep each passage on a single idea so its vector points somewhere specific. A paragraph covering four topics embeds to the average of four topics, which is a point in space near nothing.
Stage two: reranking, which is where the real decision happens
Candidate retrieval is built for recall and is deliberately sloppy. It hands over a few hundred passages that are probably relevant. The reranker then does the expensive thing that could not be done at index scale. It reads the question and each candidate passage together, in one pass, and scores how well that passage actually answers that question.
The architecture is a retrieve and rerank pipeline, and the distinction matters. Stage one compares two things that were understood separately. Stage two understands them together. That is why a passage can rank highly on similarity and get dropped here, and it is the single most common reason a page that looks well optimised never appears.
Reranking rewards a specific shape of writing. A passage that contains the whole answer to one question beats three passages that each contain a third of it, even when all three are from a better known domain. This is the most exploitable fact in the whole pipeline and almost nobody writes for it, because writing for it means answering the question immediately instead of building to it.
Stage three: chunking, and the context that gets thrown away
Before any of this, your page was cut into chunks. Typically a few hundred tokens, split on headings and paragraph boundaries, sometimes with a small overlap. The chunk is the unit that is embedded, scored, retrieved and quoted. Your page is a container, not a competitor.
Chunking destroys context, and it does so silently. A paragraph opening with This approach reduces cost by about forty percent is useless once separated from the paragraph naming the approach. Anthropic published measurements on exactly this failure and on prepending a short explanatory line to each chunk before embedding it, an approach they call contextual retrieval. Retrieval failures dropped substantially. You cannot run that process on somebody else’s index, but you can do the editorial equivalent for free by making every passage name its own subject.
The unglamorous fix that outperforms most content strategy
Open every paragraph on your commercially important pages with its own subject. No this, no it, no as mentioned above. It reads slightly more formally to a human and it survives chunking intact, which is the trade worth making on pages you want quoted.
If you want it checked against how engines are currently reading you rather than in the abstract, a free AI visibility check includes the passage level read on your top pages.
Stage four: what fits, and where it sits
The surviving passages are packed into the prompt under a token budget, with duplicates across sources collapsed. Two things happen here that are worth knowing and that you cannot do much about.
Position affects use. Models attend unevenly across a long context, and material in the middle of a large prompt is used less reliably than material at either end. Being retrieved is not the same as being read, and being read is not the same as being credited.
Deduplication penalises the derivative. When four sources say the same thing in the same way, the system keeps one. If your page is a competent restatement of the consensus, you are the one most likely to be dropped, because you are the one adding least. The original framing survives. The good summary does not. That is the single strongest argument for publishing something nobody else has, even something small.
The four questions worth asking about your own pages
This pipeline was first described in something close to its modern form in the 2020 paper that named retrieval augmented generation. Production systems have grown considerably more complicated since, but the shape has held, and the shape is what you need.
| Stage | What it rewards | Can you influence it? | What to actually do |
|---|---|---|---|
| Query rewriting | Plain, literal phrasing of the need | No, but you can anticipate it | Write the boring version of your claim somewhere on the page |
| Candidate retrieval | Word overlap plus single-idea passages | Yes, directly | Use buyer vocabulary, one idea per paragraph |
| Reranking | One passage answering one question fully | Yes, directly | Answer first, qualify second, never build to it |
| Context selection | Non-duplicate, well positioned material | Barely | Publish something only you can say |
None of this is a ranking factor list and it should not be read as one. It is a description of a filter with four gates, where failing any one of them makes the others irrelevant. Most pages that never appear in AI answers are failing gate one for reasons that have nothing to do with content quality, which is covered in more operational detail in indexed, retrieved, cited.
Where entities come into it
Retrieval scores text, but the systems around it increasingly resolve the text to things. Whether the Apex in your passage is your product, a competitor, or a legal firm in Leeds is decided by a resolution step that sits alongside retrieval, and it decides whether your passage is attributed to you at all.
This is why two companies with identical content quality get different outcomes. One is a resolved entity with consistent records across independent sources. The other is a string. We have covered what that actually means in what an entity is in AI search and how the supporting records work in what a knowledge graph holds. If your passages are being retrieved and you still are not credited, resolution is where to look next.
What we would do first
Pick your five most commercially important pages. For each one, take the three questions you want it to win. Then read the page hunting for a single passage that fully answers each question without needing the paragraph above it. Most teams find one out of fifteen.
Fix that before touching schema, before touching internal links, before commissioning anything new. It costs an afternoon of editing per page and it addresses the two stages of the pipeline you have any control over. Everything else in AEO is downstream of whether a machine can lift one clean paragraph out of your page and hand it to a model.
Related reading
- What AEO is. The full picture, with this pipeline as one component rather than the whole story.
- AEO versus SEO. Why the unit of competition moved from the page to the passage, and what carried over unchanged.
- Mention, citation, recommendation. Three different outcomes at the end of this funnel, with different causes.
- How ChatGPT picks companies to name. The same mechanics observed from the answer end rather than the index end.
You can test every claim here yourself, and you should.
Ask an engine a question you ought to win. Read what it cites. Then open those pages and look at the specific paragraph that got quoted. It is almost never the best written paragraph on the page. It is the one that answered a question on its own.
When the pattern is clear but the cause is not, send us the domain and we will run a visibility check. You get the raw answers, the passage level read, and one named constraint rather than a list of forty things to fix.
Shaban runs answer engine optimisation for B2B SaaS companies at Uncited Brands. He works the unglamorous end of the problem, mostly crawler access, retrieval diagnostics and measurement baselines, and publishes the tests that do not go his way alongside the ones that do.