How a Page Becomes a Retrievable Passage
Your page is indexed, fetched, and comprehensive, and it still never gets pulled into an answer. The reason is that no retrieval system has ever selected your page. It selects passages, and a passage is a much smaller and much lonelier thing.
- Retrieval systems split a page into passages, embed each passage on its own, score the passages against a query, and pass a handful of winners to the model. The page is never the unit of selection.
- Google's grounding coverage falls from 61 percent on pages under 1,000 words to 13 percent on pages over 3,000 words, which means making a page longer shrinks the share of it that can be used.
- You do not control where the split happens. Chunk size, overlap and split points are engine parameters that change without notice.
- You do control whether a passage still means anything once it is separated from the page around it. That is the whole lever.
- Anthropic measured a 35 percent drop in retrieval failure purely from giving chunks back the context they lost during splitting. That number is the size of the problem, published by a vendor building the fix.
Your page is not the unit of retrieval
Pages over 3,000 words got about 13 percent of their content used for grounding. Pages under 1,000 words got 61 percent. Same crawl, same index, same eligibility. DejanSEO measured that gradient across 7,060 queries and 883,262 snippets, and it is the best available explanation for why the most comprehensive page on your site is often the least cited one.
The instinct, when a page is indexed and fetched and still absent from every answer, is to make it more thorough. That instinct is backwards. Thoroughness is a page level virtue. Retrieval is not a page level operation.
Retrieval systems do not select pages. They split a page into passages, embed each passage on its own, score those passages against a query, and hand a small number of winners to the model that writes the answer. A self contained passage that answers one question will beat a longer, better page whose answer depends on three other sections the retrieval system never selected.
This is the mechanism that every guide on how to get cited by AI assumes and almost none of them state. Once you can see it, the formatting advice in circulation sorts into three piles: what follows from the mechanism, what is irrelevant to it, and what actively makes it worse.
What happens between the fetch and the answer
Four stages. Each one throws something away, and the thing it throws away is context.
Stage one, fetch and extract. The system gets whatever the bot received. Navigation and boilerplate get stripped. Anything that only exists after client side JavaScript runs is a coin flip: when Vercel and MERJ ran a log study of AI crawler behaviour, GPTBot fetched JavaScript files in 11.50 percent of requests and ClaudeBot in 23.84 percent, and neither executed them. That study is from December 2024 and nobody has replicated it at scale since, so treat it as directional rather than current. What is not directional is access: if the bot never got the page, nothing downstream applies, which is why a crawler access audit sits ahead of every content decision.
Stage two, split. The extracted text is cut into chunks. The parameters are not secret, they are just not yours. OpenAI's file search documentation states a default chunk size of 800 tokens with 400 tokens of overlap, embedded with text-embedding-3-large at 256 dimensions, retrieving up to 20 chunks per query. Google's Vertex AI RAG Engine documentation, last updated 28 July 2026, sets a default chunk size of 1,024 tokens with 256 tokens of overlap, and explains the trade in one sentence: "A smaller chunk size means the embeddings are more precise. A larger chunk size means that the embeddings might be more general but might miss specific details."
Be precise about what those numbers are. They are developer defaults for document retrieval products. Neither OpenAI nor Google has published the chunking parameters used for live web retrieval in ChatGPT search or AI Mode. Anyone quoting a specific chunk size for AI Overviews is quoting a guess.
Stage three, embed. Each chunk becomes a vector on its own. This is the stage that costs you, and it is the stage nobody writes about. Jina AI's researchers used a Wikipedia passage about Berlin to show the failure: the phrases "its" and "the city" reference Berlin, "which is mentioned only in the first sentence," so a chunk containing those phrases and not the name carries no Berlin signal at all. In their benchmark, preserving document context through embedding moved nDCG@10 on NFCorpus from 23.46 percent to 29.98 percent. Identical text, identical model. The only change was whether the chunk remembered where it came from.
Stage four, score and select. Candidate passages are ranked against the query, and increasingly against a set of generated subqueries rather than the query the user typed. Google names a passage ranking system as one of seventeen ranking systems in its own documentation, describing it as "an AI system we use to identify individual sections or 'passages' of a web page." Google has also filed for text ranking with pairwise ranking prompting, a method in which a generative model performs "pairwise comparisons between the first set of text and the second set of text based on the query." Passages are not scored in isolation. They are scored against each other.
The subquery part matters more than the page level part. Ahrefs' analysis of 1.4 million ChatGPT prompts found cited URL titles matched ChatGPT's internally generated fan out queries at a cosine similarity of 0.656, better than they matched the user's original prompt at 0.602, while retrieved but uncited URLs sat at 0.484. If you want the full version of that, it lives in the query fan out mechanics. For chunking purposes the consequence is simple: your passage is competing for a question the user never typed.
The grounding budget is fixed, and your long page competes against itself
Here is the finding that should change how you plan a page. DejanSEO's tokenisation of 2,275 pages found a median grounding budget of roughly 2,000 words per query across all sources combined, with per source grounding plateauing at about 540 words. The top ranked source got 531 words, or 28 percent of the budget. Everything after the plateau is not weighed and found wanting. It is not read.
the point at which grounding from a single source plateaus, regardless of how long the page is
So the 61 percent to 13 percent coverage collapse is not a quality signal. It is arithmetic. A fixed extraction ceiling divided by a growing page produces a shrinking share, and the passages that fall outside the ceiling are dead weight competing with your own best paragraph for the same slot.
The implication for content strategy is clear: density beats length. Focus on being the most relevant source for a query, not the longest.
Two other findings line up behind that, and together they point somewhere specific. Ahrefs' study of 75,000 brands found the number of pages on a site was among the weakest correlates of AI visibility it measured, at a Spearman coefficient of roughly 0.194. Surfer, analysing 10,000 keywords and 33,000 extracted fan out queries, found pages ranking for both the main query and at least one fan out were 161 percent more likely to be cited in an AI Overview.
Read those together and the prescription is neither "publish more" nor "publish longer." It is coverage breadth at the subtopic level, expressed as more distinct, denser, individually retrievable passages. Which is a different instruction from both of the ones the industry currently sells.
Google says do not chunk, Ahrefs says you cannot, and both are half right
In January 2026, on a Search Off the Record episode reported by Barry Schwartz, Google's former Search Liaison went after chunk optimisation directly.
So we don't want you to do that. I was talking to some engineers about that. We don't want you to do that. We really don't.
Separately, Ahrefs published a piece arguing the tactic is not a tactic at all, on the grounds that the mechanism is out of your hands.
Chunking is based on tokens, not paragraphs or sentences, and each model decides its own split points dynamically.
And Mike King published a direct refutation of Sullivan's framing, arguing that the industry and Google were talking past each other about what the word even means.
Structure is no longer about presentation. It is about making meaning legible at the passage level.
These three are not actually in conflict, and the reason matters. Sullivan is objecting to a format, the staccato micro-section page written at a machine rather than a reader. He is right that it is a bad bet, and Google has a long record of the systems catching up with formats built for the systems. Gavoyannis is right about the mechanics: token boundaries and split points are engine side and versioned silently, so any parameter you optimise against today can be changed tomorrow. King is right that legibility at the passage level is a real property of a document and it is yours to set.
The synthesis nobody states: the lever is neither the split nor the format. It is whether a passage survives the split. That is a property of how the writing hangs together, not of how short the paragraphs are, and it is invisible to every formatting checklist in the top ten results for this query. It is also the same property good editors have always demanded. Which is exactly King's other point, that chunking and writing for people are not opposed.
Access, measurement, mapping, earning, proof. The Cited Method is the five stage version of this, with the parts that are mechanically certain separated from the parts that are still correlational.
See the method→The variable you control is dependency distance
Call it dependency distance: how far a passage's meaning has to travel before it is complete. A passage with zero dependency distance answers its question using only the words inside it. A passage with high dependency distance needs the H2 three screens up, the entity named in the intro, the table header 400 words back, or the definition you established in section one.
The retrieval stack will not travel that distance for you. Its whole design assumes it does not have to.
We know the cost of that assumption because the vendors have measured it while building fixes for it. Anthropic's contextual retrieval work reports that prepending chunk specific explanatory context before embedding reduced the top-20 chunk retrieval failure rate by 35 percent, from 5.7 percent to 3.7 percent, rising to 49 percent when combined with contextual BM25 and 67 percent with reranking. Their illustrating example is a chunk reading "The company's revenue grew by 3% over the previous quarter," which, alone, names no company and no quarter.
That is your page. Written by you, about your business, and stripped of its subject the moment it was split.
The retrieval side is noisier than practitioners assume, too. Chroma's benchmark of chunking strategies found the popular 800 token, 400 overlap configuration scored 1.5 percent on intersection over union, among the worst tested, while a 200 token cluster semantic chunker scored 8.0 percent. Brandon Smith and Anton Troynikov concluded that default settings for popular chunking strategies can produce relatively poor performance. The academic picture agrees on direction and disagrees on specifics: a 36 method cross domain benchmark published in March 2026 found paragraph group chunking hit nDCG@5 of 0.459 against under 0.244 for naive fixed length splitting, while a separate January 2026 evaluation found overlap provided no measurable benefit at all and identified a quality cliff past roughly 2,500 tokens of context. Both are preprints on question answering benchmarks, not live web retrieval, so hold them loosely.
The operator reading of all of it: you are not going to out engineer the splitter. You are going to make the split cheap to survive.
| Engine side | Your side | |
|---|---|---|
| Chunk size and split points | Set per engine, changed without notice | Nothing you can set |
| Embedding model and dimensions | Vendor decision, versioned silently | Nothing you can set |
| How many passages get retrieved | Up to 20 chunks in OpenAI file search, unpublished for live web engines | Nothing you can set |
| Whether a passage means anything alone | Assumed, never checked | Entirely yours |
| Whether the answer sits in one place or four | Never reassembled for you | Entirely yours |
| Whether the entity is named or pronouned | Referent is lost at embedding | Entirely yours |
The extraction test, run on one section at a time
This is the only diagnostic I have found that maps cleanly onto the mechanism rather than onto taste. Take a single H2 section, paste it into a blank document with nothing else, and read it as a stranger.
- Is the subject named inside the passage, or does it open with it, this, they, or the company?
- Does the passage answer one question, or does it set up a question answered later?
- Does any sentence reference above, below, as we saw, or the previous section?
- If there is a number, does the unit, the period and the source sit in the same passage as the number?
- If there is a table, does a reader who sees only these rows know what the columns mean?
- Does the passage depend on a definition established in a different section?
- Could a stranger quote this passage in an answer and be correct without your page around it?
Every no is a dependency you can remove with a rewrite that costs nothing and, notably, makes the page better for a human skimmer as well. This is the test I run first on every site I take on, before touching anything else. Every yes you already had is a passage that can be retrieved without help.
Run it against your competitors' pages too. When you analyse which sources an engine actually cites, the pattern that shows up over and over is not authority and not length. It is that the cited passage was quotable standing alone and yours was not. Naming entities explicitly rather than pronouning them is the cheapest single fix, and it is the same discipline that underpins entity level SEO.
One warning, because this is where people overshoot. The test asks whether a passage is self contained, not whether it is short. Chopping a coherent argument into forty labelled fragments is precisely the failure mode Sullivan was objecting to, and there is no evidence it works. Self containment and brevity are different properties, and only one of them has a mechanism behind it.
Where this model breaks down
I would rather you hold this loosely than hold it wrong, so here is what it does not cover.
No major engine publishes the chunking parameters it uses for live web retrieval. Everything concrete in this post about chunk sizes comes from developer facing RAG products, and the honest inference is that the shape of the pipeline is the same while the numbers are not knowable. If someone quotes you a chunk size for AI Overviews, ask them for the primary source.
Second, there is no published controlled experiment showing that rewriting a page for referential self containment increases citations. The evidence chain here is mechanistic and inferential: retrieval works on passages, context loss measurably degrades retrieval, therefore passages that lose less context should retrieve better. That is a defensible chain, and it is not the same thing as a difference in differences study. The GEO field has a habit of dressing mechanism up as proof, which is exactly the failure I try to document in the research base for generative engine optimisation.
Third, none of this is a substitute for classic eligibility. A page has to be indexed and snippet eligible to appear in Google's generative features at all, which is stated plainly in Google's own AI features documentation. Ranking still matters, though less than it did, and the honest picture of that decoupling is in the top ten overlap data. Passage structure is a multiplier on eligibility, not a replacement for it. It is also not schema, which the best available controlled evidence says does not move AI citations.
Fourth, measurement. Repeated prompts do not return stable answers, so any before and after you run on a rewritten page needs repeated sampling to mean anything, which is the whole argument in sample size for AI visibility work.
The useful part of understanding chunking is not a checklist. It is that it retires the wrong question. Stop asking whether your page is good enough to be cited. Start asking which single passage on it is going to be pulled out, dropped into a stranger's answer with nothing around it, and asked to stand up on its own. If you cannot name that passage, the engine will not find it either. More of my work on this is in the insights archive, the operating framework sits at the Cited Method, and what I actually do with it is here.
Frequently asked questions
How do LLMs chunk web content?
The extracted text of a page is split into passages, each passage is converted into a vector embedding on its own, and those embeddings are scored against the query. Google's Vertex AI RAG Engine defaults to 1,024 token chunks with 256 tokens of overlap. Live web engines do not publish their parameters.
What chunk size do AI search engines actually use?
Nobody outside the engines knows. The published numbers are developer product defaults: 800 tokens with 400 overlap in OpenAI file search, 1,024 tokens with 256 overlap in Vertex AI RAG Engine. No vendor has documented the chunking used for ChatGPT search, AI Mode or AI Overviews.
Should I break my content into short bite sized chunks?
No. Google's former Search Liaison Danny Sullivan specifically told creators not to do that in January 2026. The mechanism rewards passages that are self contained, not passages that are short. Those are different properties, and only self containment has evidence behind it.
Does page length hurt AI citation?
Indirectly. DejanSEO found grounding coverage falls from 61 percent on pages under 1,000 words to 13 percent on pages over 3,000 words, because the extraction budget per source plateaus near 540 words. Length does not penalise you. It dilutes the share of the page that can be used.
What is passage retrieval in SEO?
Selecting and scoring individual sections of a page rather than the page as a whole. Google names a passage ranking system in its official list of seventeen ranking systems, describing it as an AI system used to identify individual sections of a web page and judge their relevance.
Can I control how my content gets chunked?
No. Chunk size, overlap and split points are engine side parameters that change without notice. What you control is whether a passage still means anything after the split, which is a property of how the writing hangs together rather than of the split itself.
Why do pronouns hurt retrieval?
A chunk is embedded alone. If a paragraph says it offers three tiers rather than naming the company, the embedding carries no signal for that company. Jina AI demonstrated this with a Berlin passage where the phrases its and the city lost their referent entirely.
Does chunk overlap help retrieval?
The evidence is mixed and leans no. A January 2026 evaluation on Natural Questions found overlap provided no measurable benefit while increasing indexing cost. It remains the default in major RAG products, which tells you defaults are set for safety rather than measured performance.
Is chunk optimization a real SEO tactic?
Not in the form it is usually sold. Ahrefs argues the split points are out of your hands, which is correct. The actionable residue is narrower: write passages that answer one question without depending on the rest of the page. That is editing, not optimisation.
Sources
- DejanSEO. How big are Google's grounding chunks? (2025-12)
- Anthropic. Introducing Contextual Retrieval (2024-09)
- Jina AI. Late Chunking in Long-Context Embedding Models (2024-08)
- Chroma. Evaluating Chunking Strategies for Retrieval (2024-07)
- OpenAI. File search: default chunking settings (2026-07)
- Google Cloud. Fine-tune RAG transformations (chunk_size and chunk_overlap defaults) (2026-07)
- Google Search Central. A Guide to Google Search Ranking Systems (2025-12)
- Google Search Central. AI Features and Your Website (2025-12)
- Google LLC. Method for Text Ranking with Pairwise Ranking Prompting (US20250124067A1) (2025-04)
- Search Engine Land. Google doesn't want you to create bite-sized chunks of your content (2026-01)
- iPullRank. Moving from a Google-shaped Web to an Agent-shaped Web: A Refutation of Misinformation about Chunking (2026-01)
- Ahrefs. SEO "Chunk Optimization" is Overrated (2025-08)
- Ahrefs. Why ChatGPT cites the pages it cites (2026-04)
- Ahrefs. AI brand visibility correlations (2025-12)
- Surfer. The impact of query fan-out on AI Overview citations (2025-12)
- Vercel with MERJ. The Rise of the AI Crawler (2024-12)
- arXiv preprint 2603.06976. A Systematic Investigation of Document Chunking Strategies and Embedding Sensitivity (2026-03)
- arXiv preprint 2601.14123. A Systematic Analysis of Chunking Strategies for Reliable Question Answering (2026-01)
Joseph Timpson has worked in search since 2010 and runs Timpson Marketing out of St. George, Utah. He built The Cited Method, a five stage framework for earning and proving real citations in AI answers, and publishes what does not work alongside what does.
Want me to run this on your site and show you the before and after?
One call, no pitch deck. We look at what is actually blocking you and tell you the truth about whether we can help.
Book a free consultation →