AI Answer Engine Retrieval: Chunks, Not Pages

Every habit in SEO is scoped to the URL. You track rankings per page, impressions per page, links per page. Canonical tags, titles, redirects and index status are all page level objects. Twenty years of tooling has trained everyone to treat the page as the atom.

Retrieval systems behind AI answers use a smaller atom. They split documents into passages before anything else happens, and from that point forward the passage travels alone. It gets scored alone, ranked alone, and handed to the model alone. Nothing downstream automatically knows which page it came from beyond a URL stapled to it for attribution.

So the two systems grade different things, and a page can pass one while failing the other.

Nothing in the left column carries over to the right. That's why a site can do well in classic search and stay invisible in AI answers without anything obviously broken.

A chunk is a contiguous slice of a document, usually a few hundred tokens long, stored and scored as an independent retrieval unit. Chunks are typically cut at a fixed size with a fixed overlap, sometimes nudged to respect paragraph or heading boundaries, and each one is embedded as a vector so it can be matched against a query by meaning rather than by exact words.

None of the consumer answer engines publish their chunking parameters. What is documented sits one layer down, in the developer retrieval products the same companies sell, and those are the only public numbers worth reasoning from.

Sources: OpenAI's file search documentation and Anthropic's Contextual Retrieval writeup.

Tokenization varies by model, so convert loosely: 800 tokens is roughly 600 English words, and "a few hundred tokens" is roughly 150 to 220 words. Those are the two scales to hold in your head. One is about the length of a long section. The other is about the length of two paragraphs.

The practical read: assume the smallest plausible unit that could carry your claim is around two paragraphs, and that it may be cut anywhere.

The vocabulary differs by vendor. The shape does not.

Steps three and four are where most content dies, and both are invisible to you. A chunk that never entered the candidate set and a chunk the reranker discarded look identical from outside: no citation, no log line, no difference in any dashboard you own.

This is the distinction almost every article blurs, and getting it wrong leads people to assume classic search already solved the problem.

Google's Search Central ranking systems guide describes passage ranking as "an AI system we use to identify individual sections or 'passages' of a web page to better understand how relevant a page is to a search."

Read the object of that sentence. The thing being assessed for relevance is the page. Passages are evidence used to judge it. That's also why the documented name is passage ranking and it sits in the ranking systems guide rather than in the indexing documentation, after the industry spent the announcement period calling it passage indexing.

Chunk retrieval inverts this.

The search surfaces sit in between, and it's worth being precise about how. AI Overviews and AI Mode are grounded in the Search index, so page level indexing is still a hard gate: an unindexed page cannot appear. On top of that, Google's AI features documentation states that both may use a query fan out technique, "issuing multiple related searches across subtopics and data sources," to build a response. A page level gate, then a passage level selection over the results of queries you will never see in a keyword tool.

Cutting a document into fixed slices destroys information, and the retrieval side knows it. Anthropic's Contextual Retrieval writeup exists specifically to patch this: it prepends generated, chunk specific context to each chunk before embedding, so that a fragment saying "revenue grew by 3 percent over the previous quarter" carries which company and which quarter with it.

The measured cost of not doing that is the most useful number in this whole field. Anthropic reported that adding contextual embeddings cut the top 20 chunk retrieval failure rate by 35 percent, from 5.7 percent to 3.7 percent. Adding a contextual lexical search alongside it took the reduction to 49 percent, and adding a reranking step took it to 67 percent, landing at 1.9 percent. Those are Anthropic's figures for their own evaluation, measured as one minus recall at 20.

Here is the part that matters to a writer rather than an engineer. Engines are paying real compute to put context back into chunks that chunking took out. A chunk that already carries its own subject, scope and date needs less of that repair, and it survives pipelines that never do the repair at all. You cannot know which kind of pipeline is reading you, so write for the one that does nothing.

Overlap helps, and only with one specific problem. OpenAI documents 400 tokens of overlap on 800 token chunks, meaning half of each chunk repeats in its neighbor. That rescues a sentence sitting near a cut. It does nothing for a pronoun whose antecedent is five paragraphs up.

The four patterns that reliably break a fragment:

• Orphan pronouns and demonstratives. "This approach," "it," "the method above." Fine on a page. Meaningless in a slice.
• Subjects that live only in the heading. Headings are frequently stripped or separated during processing. If your H2 says "Pricing" and the paragraph below never says what is priced, the fragment is about nothing.
• Claims split between a list introduction and its bullets. The intro says what the list is; the bullets say the things. Cut between them and you have two useless halves.
• Numbers separated from their units, dates or scope. "Up 40 percent" is not a claim. "Up 40 percent year over year across the 120 pages we tested in 2026" is one.

The two scoring systems diverge most visibly on long form content, which is uncomfortable because long form is what most content strategies produce.

Neither column is "better." A pillar guide earns links and rankings the FAQ page never will. But if you have been wondering why answers sometimes cite pages that would not crack the top ten for the same query, the right column is a large part of the reason.

The fix is not to stop writing long content. It's to make long content survive being cut, which is a structural problem, not a length problem.

About forty minutes for one page, and it replaces guessing with a list you can act on.

Run this against any page before you conclude your content is the problem.

• [ ] Every section names its subject in the body text, not only in the heading.
• [ ] No paragraph opens with a pronoun or demonstrative referring to something above it.
• [ ] Every number appears next to its unit, its time period and its scope.
• [ ] List introductions repeat enough context that the bullets survive a cut between them.
• [ ] Each table has a caption or lead sentence stating what the table compares.
• [ ] At least one sentence per section is a complete, checkable claim someone could quote.
• [ ] Definitions appear as a full sentence including the term, not as a fragment after a colon.
• [ ] Dates are visible in the text, not only in metadata.
• [ ] The content exists in the raw HTML, since several crawlers perform a plainer fetch than Googlebot.
• [ ] No leftover nosnippet, max-snippet or data-nosnippet control is suppressing the text you want quoted.

Be clear about the boundary. You do not choose the chunk size, where the boundaries fall, whether the embedding model captures your phrasing, how the reranker weighs your fragment, or whether a search runs at all for a given prompt. Those are vendor decisions that change without announcement, which is why every claim in this post links to a vendor page you should re-check rather than trust indefinitely.

What you control is what a fragment contains if it happens to land somewhere reasonable. That is a narrower lever than most AI search content implies, and it's a real one.

It also has nothing to do with traffic volume, which is worth saying plainly given what we sell. SparkCliks provides search clicks and website visits through SERP Clicks, Sparky Traffic Bot, Website Traffic and Realistic Traffic. Those change what your analytics records about visits. None of them place text into a retrieval index, and no retrieval pipeline consults your visitor counts when scoring a chunk. Anyone selling AI citations as a traffic product is selling something they cannot deliver.

If you want the engine by engine view of who crawls what and where citations attach, that's covered separately in how AI assistants pick sources. This post is the layer underneath it: whichever engine you are chasing, the thing being scored is a fragment.