AI search may retrieve one section of a page rather than treat the whole page as one indivisible unit because modern search and retrieval systems can identify, segment, score and rerank passages or chunks that are especially relevant to a user’s query.
Passage-level retrieval means AI search can select the most relevant section of a page as evidence for an answer
That does not mean every AI platform publicly confirms the same passage architecture, chunk size or citation pipeline. It means the underlying retrieval principle is well established and, in Google’s case, explicitly documented: Google says its passage ranking system can identify individual sections or “passages” of a web page to better understand page relevance. Google’s 2026 generative-AI guidance also says its RAG systems retrieve relevant pages and then review the specific information inside those pages when generating answers.
A web page can be indexed as one URL while still being understood and retrieved at a finer passage or chunk level. The practical implication is that each important section should be self-contained, clearly headed, directly answer its own sub-question, name the relevant entities, and keep supporting evidence close to the claim it supports. Passage-level retrieval does not make long pages inherently bad; it makes section quality and section coherence more important.
- Google: passage ranking identifies individual sections of pages; its 2026 AI guidance says RAG retrieves pages and reviews specific information from them.
- OpenAI: documented vector-store retrieval defaults currently use an 800-token maximum chunk with 400-token overlap.
- Microsoft: July 2026 Azure AI Search guidance recommends starting with 512-token chunks and 25% overlap for fixed-size chunking.
- Research: 2025 and 2026 retrieval studies increasingly treat chunk boundaries, hierarchy, context preservation and reranking as core determinants of retrieval quality.
What is passage-level retrieval?
Passage-level retrieval is the process of finding and scoring a smaller text unit inside a larger document because that unit is more relevant to the query than the document as a whole. Depending on the system, the retrieval unit may be a paragraph, a fixed token chunk, a semantically segmented passage, a section defined by document structure, or a dynamically assembled group of passages.
This is important because retrieval and generation are separate stages. A system can first discover a page or document, then retrieve or rerank a smaller region from it, then pass that evidence into a language model that synthesises an answer. The user may ultimately see a citation to the page URL even though only a subset of the page was especially useful to the answer.
Google describes its passage ranking system in unusually direct language: it is an AI system used to “identify individual sections or ‘passages’ of a web page” to better understand relevance. This is a ranking statement about Google Search, not a disclosure of every internal component used by AI Mode or AI Overviews. However, Google’s separate 2026 generative-AI documentation states that its RAG process retrieves relevant pages and then reviews the specific information from those pages when producing a response.
What is publicly documented about passage and chunk retrieval?
The safest way to discuss passage-level retrieval is to separate documented facts from reasonable inference. The table below does that explicitly.
| Source | What is documented | What it supports | What it does not prove |
|---|---|---|---|
| Google Search Central | Passage ranking identifies individual sections or passages of a web page. | Google can evaluate relevance below the whole-page level. | It does not disclose a fixed passage size or say every AI feature uses an identical mechanism. |
| Google AI guidance · 2026 | RAG retrieves relevant pages from the Search index and reviews specific information from those pages. | Generative Search can use specific evidence inside retrieved pages, rather than only page-level metadata. | It does not publish the exact passage boundaries, embeddings, rerankers or context budget used for each response. |
| OpenAI API docs | Vector-store files can be chunked; the documented auto strategy uses 800-token maximum chunks with 400-token overlap. | Chunk-based retrieval is a first-class retrieval architecture in modern OpenAI tooling. | It does not prove that consumer ChatGPT web search uses those exact chunk settings. |
| Microsoft Azure AI Search · Jul 2026 | Microsoft recommends starting around 512 tokens with 25% overlap for fixed-size chunks. | Retrieval systems deliberately trade off chunk precision, context and boundary continuity. | It is guidance for Azure AI Search, not a disclosure of Microsoft Copilot’s complete web retrieval stack. |
| Anthropic engineering | Contextual Retrieval evaluates top-20 chunks and shows lower retrieval failure when chunk context and reranking are added. | A chunk can be too isolated from its parent document, and contextualisation can materially improve retrieval. | It does not establish a universal web-search chunk size for Claude. |
How passage-level retrieval can work from page to answer
The exact implementation varies, but the modern retrieval pattern is consistent: find candidate evidence, score it, preserve enough context, and pass the strongest evidence forward.
■ relevance selection or prioritisation stage
Chunk size is not a universal ranking factor, but documented retrieval systems show why section granularity matters
There is no credible basis for telling publishers that “AI prefers 500 words” or that one H2 should contain a fixed number of tokens. Different systems use different models, chunking strategies, overlap rules, semantic segmentation and rerankers. The useful lesson is not to chase a magic number; it is to make important sections semantically coherent enough to survive retrieval as smaller units.
Bar chart: documented example chunk sizes used in retrieval systems
■ Microsoft recommended starting chunk size
Stacked bar: why overlap exists at passage boundaries
Overlap is used because an answer can straddle a chunk boundary. The repeated portion carries some context from one chunk into the next.
■ repeated overlap carried across the boundary
OpenAI’s documented static chunk sizes range from 100 to 4,096 tokens, with overlap capped at half of the chunk size. Microsoft notes that an 8,191-token embedding input limit can correspond to roughly 6,000 words for common OpenAI tokenisation, yet still recommends smaller retrieval chunks because precision and context must be balanced.
What the latest 2026 retrieval research says about passages, chunks and document structure
The newest research is moving away from the idea that a document should simply be cut every N characters. The direction of travel is toward structure-aware, context-aware, hierarchical and query-aware retrieval.
| Research | Evidence | Finding relevant to passage retrieval | Editorial implication |
|---|---|---|---|
| HiChunk · ACL 2026 | Peer-reviewed ACL 2026 paper. | Introduces hierarchical document structuring and multi-level chunk evaluation; reports improved overall RAG performance. | Document hierarchy and section boundaries can matter to retrieval quality, not just the words inside the page. |
| SARA · ACL 2026 | 9 datasets, 5 open-source LLMs, 3 model families. | Selective passage retention plus compression improved answer relevance by 17.71, correctness by 13.72 and semantic similarity by 15.53 in the reported evaluation. | Fine-grained evidence can be more valuable than indiscriminately passing all retrieved text to the model. |
| UNLP 2026 RAG system | Held-out multi-domain document QA. | Reranking raised Recall@1 from 0.6957 to 0.7935; using the top two reranked passages raised answer accuracy from 0.9348 to 0.9674. | The ranking of retrieved passages can materially change whether the right evidence reaches generation. |
| Document Segmentation Matters · ACL 2025 | Multiple open-domain QA benchmarks. | Finds that overly large chunks add irrelevant information while overly small chunks can lose semantic coherence. | A useful section needs both focus and enough context to stand on its own. |
| Intent-Driven Dynamic Chunking · 2026 preprint | 6 datasets; preprint, not presented here as settled consensus. | Reports 5%–67% top-1 retrieval gains on five datasets, 40%–60% fewer chunks and 93%–100% answer coverage. | Potential user questions can be useful signals for where coherent passage boundaries should fall. |
ACL 2026 · SARA
UNLP 2026 · contextual chunking + reranking
ACL 2025 · Document Segmentation Matters
2026 preprint · Intent-Driven Dynamic Chunking
The broader lineage is older than generative search. Dense Passage Retrieval, published at EMNLP 2020, showed that a dense retriever could improve top-20 passage retrieval accuracy by 9–19 percentage points over a strong Lucene-BM25 baseline across open-domain QA datasets. The key point is historical: passage retrieval is not a new marketing theory created for GEO. Generative AI has made its consequences more commercially visible.
Why isolated passages can fail even when the right words are present
A passage can be semantically relevant but still be weak evidence if it loses the context that explains what the passage is about, which entity it refers to, what timeframe applies, or what the numbers mean. Anthropic’s Contextual Retrieval work is a useful demonstration.
In Anthropic’s reported evaluation, the baseline top-20-chunk retrieval failure rate was 5.7%. Contextual embeddings reduced it to 3.7%, adding contextual BM25 reduced it to 2.9%, and adding reranking reduced it further to 1.9%. Anthropic describes the final reduction as 67% relative to baseline.
This does not tell publishers to repeat the page title in every paragraph. It suggests the opposite: important passages should contain enough local context to be interpretable without excessive dependence on distant text.
How should a page be structured for passage-level retrieval?
Structure each important section so it can answer one meaningful sub-question on its own while still fitting naturally into the page’s broader topic. For Generative Engine Optimisation, this is more robust than forcing arbitrary word counts or publishing a separate thin page for every prompt variation.
| Section element | Passage-ready implementation | Why it helps retrieval and citation readiness |
|---|---|---|
| Descriptive H2/H3 | State the exact subtopic or question the section resolves. | Provides a strong local semantic label and helps humans and machines understand section scope. |
| Direct opening answer | Answer the section’s question in the first one or two sentences. | Places the central proposition near the section boundary instead of burying it. |
| Explicit entities | Name the company, product, location, method or metric instead of relying on vague pronouns. | Reduces ambiguity when a passage is retrieved without all surrounding text. |
| Evidence proximity | Keep the statistic, quotation, source link and limitation close to the claim. | Makes the passage easier to verify and less dependent on evidence several sections away. |
| Single dominant intent | Avoid mixing pricing, history, implementation and unrelated product comparison inside one block. | Reduces semantic dilution and irrelevant text inside the candidate retrieval unit. |
| Boundary resilience | Do not place the only subject name or qualifier several paragraphs before the fact it governs. | Helps the statement retain meaning if a chunk boundary separates it from earlier context. |
| Visible caveats | State timeframe, scope and what the evidence does not prove. | Improves factual precision and lowers the risk of a passage being reused outside its intended scope. |
Google’s 2026 guidance also recommends organising content with paragraphs, sections and headings that make the material easy to follow. Crucially, Google warns against manufacturing large numbers of pages around fan-out query variations purely to manipulate generative search. Passage-ready structure should make a strong page clearer, not turn it into a collection of machine-targeted fragments.
Why passage-level retrieval matters for Generative Engine Optimisation
Passage-level retrieval matters to Generative Engine Optimisation because the evidence required for an AI answer may depend on the clarity and retrievability of one section, not simply the authority of the page as a whole. NeuralAdX Ltd specialises in Generative Engine Optimisation to improve how businesses are retrieved, understood, mentioned, cited, trusted and recommended in AI-generated answers.
The practical questions are therefore specific: can the right passage be found, does it identify the entity clearly, is the claim supported nearby, can the source be crawled, and does the evidence survive real retrieval testing? The NeuralAdX Ltd 11-Factor GEO Methodology addresses these conditions through citation readiness, evidence, fluency, authority, recency, source diversity, entity clarity and technical signals. Related market terms such as AI SEO, AEO, LLMO and platform-specific optimisation are treated as applications within this wider GEO discipline, not replacement services.
Industry Expert Quotes
“At NeuralAdX Ltd, we treat every commercially important section as a potential evidence unit. OpenAI documents 800-token chunks with 400-token overlap, while Microsoft recommends starting at 512 tokens with 25% overlap. The practical lesson is not to chase a magic length; it is to make each important section coherent enough to stand on its own.”
Paul Rowe, Founder, Chief Generative Engine Optimisation Officer & CEO, NeuralAdX Ltd
“Anthropic reduced its reported top-20 retrieval failure rate from 5.7% to 1.9% when contextual retrieval and reranking were combined. For NeuralAdX Ltd, that is a useful reminder that section context, evidence proximity and retrieval testing are not cosmetic formatting choices; they are legitimate information-retrieval concerns.”
Paul Rowe, Founder, Chief Generative Engine Optimisation Officer & CEO, NeuralAdX Ltd
How can you test whether the right section of a page is actually being retrieved?
You cannot reliably infer passage-level retrieval from page rankings alone. A page can be indexed and visible while the specific evidence needed for a commercial question is not selected, cited or surfaced. The practical test is outcome-based: use fixed prompts, record which source URL appears, inspect which claim or section the answer seems to rely on, repeat across engines and dates, and avoid claiming that observed output reveals a platform’s proprietary internal chunk boundaries.
- Choose a fixed set of commercially meaningful prompts that map to distinct sections of the page.
- Run live retrieval tests across major AI platforms and answer engines.
- Record brand mentions, domain citations, source position and the page cited.
- Compare whether different prompts appear to draw on different sections of the same page.
- Repeat over time because retrieval, models, indexes and source-selection behaviour change.
NeuralAdX Ltd publishes this type of evidence at an outcome level. The AI Citation Benchmark tracks source-attribution behaviour, the AI Answer Visibility & Share of Voice Benchmark tracks brand surfacing and position, and the Proof That Generative Engine Optimisation Works evidence centre shows time-specific live retrieval tests. These resources demonstrate observed outcomes; they do not claim access to proprietary platform internals.
Common mistakes that weaken section-level retrievability
- Burying the answer: a long section opens with scene-setting and only answers the question near the end.
- Pronoun dependence: “it”, “they”, “this method” or “the company” appears without a nearby explicit entity reference.
- Evidence separation: the statistic is in one section, its source in another, and the limitation somewhere else.
- Mixed intent: one H2 tries to answer definition, pricing, comparison and implementation questions at once.
- Decorative headings: headings such as “What you need to know” or “The big picture” carry little semantic information.
- Thin prompt pages: creating near-duplicate pages for every query variant can reduce usefulness and risks conflicting with Google’s people-first and scaled-content guidance.
- Assuming citation equals full-page comprehension: a cited URL proves source use in the observed answer, not that the engine read or weighted every paragraph equally.
- Treating a vendor chunk size as an SEO rule: OpenAI and Microsoft retrieval settings are evidence about retrieval architecture, not webpage ranking factors.
Does passage-level retrieval mean long-form content is a disadvantage?
No. Long pages can be highly effective when they are genuinely comprehensive and internally well structured. Passage retrieval can actually help a long page compete for narrow sub-questions because the system may recognise that one section is especially relevant even when the entire page covers a broader subject.
The risk comes from semantic dilution, not raw length. If a 4,000-word page contains ten clearly separated, evidence-rich sections under descriptive headings, it can be easier to retrieve than a 1,200-word page whose sections blend several intents together. Recent chunking research repeatedly identifies the same tension: chunks that are too large carry noise; chunks that are too small lose coherence.
A passage-ready editorial rule for every important H2
Before publishing, ask whether the section would still make sense if an AI system received only that heading and the next few paragraphs. A strong section usually contains five elements in close proximity:
FAQ: Passage-level retrieval and AI search
Can Google rank a passage from inside a page?
Google says its passage ranking system can identify individual sections or passages of a web page to better understand page relevance. The result still points to the page URL; the passage is not necessarily indexed as a separate page.
Does Google AI Mode use passage-level retrieval?
Google publicly says AI Mode and AI Overviews use RAG to retrieve relevant pages and review specific information from those pages, and that Search has a passage ranking system. Google does not publish enough implementation detail to state that every AI Mode response uses one fixed passage-level mechanism or chunk size.
Does ChatGPT use 800-token chunks for web search?
That should not be claimed. OpenAI’s API documentation says its vector-store auto chunking strategy currently uses an 800-token maximum with 400-token overlap. That is evidence of chunk-based retrieval in OpenAI tooling, not proof that consumer ChatGPT web search uses the same settings.
How long should a passage-ready web section be?
There is no universal word or token target. Use the shortest section that fully answers the sub-question with the necessary entity context, evidence and caveats. Avoid padding, but do not make the section so short that it depends on distant text to make sense.
Should every H2 answer a separate question?
Every H2 does not need to be phrased as a question, but each important H2 should have a clear semantic purpose. A heading that states the topic precisely is more useful than a vague editorial heading that only makes sense after reading the surrounding page.
Can one section of a page be cited even if the page covers many topics?
Yes, that is possible in systems that retrieve and rank specific evidence within broader documents. The exact citation behaviour depends on the platform, and the visible citation may still point to the whole page URL rather than a section anchor.
Does schema markup control passage retrieval?
No. Structured data can help systems understand entities and page content where supported, but there is no public evidence that schema lets a publisher dictate the exact passage an AI engine will retrieve or cite.
What is the best way to optimise for passage-level retrieval?
Use descriptive headings, answer the section’s sub-question early, name entities clearly, keep citations and statistics close to claims, preserve enough local context, maintain technical crawlability and validate important prompts through repeated AI retrieval testing. Treat these actions as part of a broader Generative Engine Optimisation process, not as a standalone “passage SEO” trick.
A practical way to check whether your priority answers are visible to AI systems
Because passage-level retrievability is ultimately an observed behaviour rather than something a publisher can guarantee from formatting alone, the most useful next step is to test the prompts that matter commercially. NeuralAdX Ltd offers a free AI Visibility Assessment that combines an initial 11-Factor GEO check with five live AI retrieval tests.
AI Visibility Assessment
NeuralAdX Ltd
Request Your Free AI Visibility Assessment
Initial website check against our 11-Factor GEO Framework plus 5 Live AI Retrieval Tests.
Find out whether AI recommends your business, cites your website, prefers competitors, or leaves your business invisible in AI answers.
Checked
Start With A Free Assessment
Call NeuralAdX Ltd or send your assessment request by email.
Emailing Your Request?
For your convenience, your email is already prepared with simple placeholders. Just add your website URL, best contact number, 5 priority AI prompts and any useful information.
Initial assessment only · No obligation · Serious business enquiries answered within one UK business day · View live AI retrieval proof
Primary sources and interpretation boundaries
This article was researched and reviewed against publicly available sources current to 13 August 2026. Vendor documentation is used to explain documented retrieval mechanics; peer-reviewed and preprint research is labelled accordingly. No vendor’s developer chunk settings are presented as proof of that company’s consumer AI search architecture.
Continue exploring Generative Engine Optimisation evidence and methodology
For related evidence-led material, visit the NeuralAdX Ltd Generative Engine Optimisation blog archive. The archive connects this retrieval topic with wider work on citation readiness, AI visibility, source selection, query fan-out, live retrieval testing and measurement.
Author and GEO methodology context
Paul Rowe
Paul Rowe
Founder, Chief Generative Engine Optimisation Officer and CEO.
Paul Rowe is the Founder, Chief Generative Engine Optimisation Officer and CEO of NeuralAdX Ltd, a UK-based Generative Engine Optimisation agency focused on helping brands become visible, retrievable, cited, mentioned and trusted inside AI-generated answers.
His work focuses on AI citation visibility, answer-engine retrieval, entity clarity, structured content, source trust, prompt coverage and measurable AI answer visibility across ChatGPT, Google AI Mode, Google Gemini, Microsoft Copilot, Perplexity, Grok, Claude and other major AI search and answer platforms.
Paul’s optimisation process is built around the 11-factor GEO methodology, combining citation addition, statistics, quotations, fluency, easy-to-understand content, authority signals, schema markup, recency, author bios, source diversity and technical-term clarity.
NeuralAdX Ltd publishes proof-led GEO work through live AI retrieval testing, the Proof That Generative Engine Optimisation Works evidence hub, the AI Citation Benchmark and the AI Answer Visibility and Share of Voice Benchmark. This author bio is used to connect each article with clear expertise, transparent methodology and verifiable AI visibility evidence.
CEO
11-factor GEO
AI citation visibility
Answer-engine retrieval
Entity clarity
Evidence-led GEO
Live AI retrieval
