You are retrieved as a chunk, not a page

A retrieval-augmented AI engine does not score your page, it scores a chunk of your page: a passage cut by the engine's own segmentation rules, embedded on its own, and handed to the model without the rest of the article around it. The cut is made by the engine. You do not get a vote, and you rarely get to see where it landed.

This is the least visible layer in GEO work. Crawl reports tell you whether a bot fetched the URL. Citation trackers tell you whether the domain showed up in an answer. Neither tells you which 400 words of your long guide actually entered the candidate set, or whether the sentence carrying your key qualifier ended up in a different chunk from the claim it qualifies.

The idea is not new to search. Google shipped passage ranking in 2020, describing it as a way to surface answers "buried deep in a web page," and said at the time that the technology would improve 7% of search queries across all languages. Search Engine Land later pinned down the important clarification: Google still indexes the full page and applies passage ranking afterwards, so the page remained the storage unit even when the passage became the scoring unit. In a RAG pipeline that separation collapses. The chunk is both.

#The boundary moves the result more than the writing does

Two 2026 papers put numbers on how much the cut matters, and they disagree in a useful way.

The first is A Systematic Investigation of Document Chunking Strategies and Embedding Sensitivity, submitted in March 2026. The authors benchmark 36 segmentation methods across five embedding models and six knowledge domains, varying the boundary mechanism (deterministic, structural, semantic, adaptive, model-driven), the size control, and post-processing.

The spread is the finding. Paragraph Group Chunking reached a mean nDCG@5 of roughly 0.459, with Precision@1 near 24% and Hit@5 near 59%, while naive fixed-size character chunking landed below 0.244 nDCG@5 and at Precision@1 of 2-3%. Same corpora, same embedding models, same queries. The only thing that changed was where the text was cut.

The paper also closes an escape hatch people reach for. Larger embedding models scored higher in absolute terms but stayed sensitive to poor chunking, with better models and better boundaries described as complementary rather than substitutable. A stronger retriever does not rescue a badly split document.

The second paper is more skeptical, and worth reading alongside the first. Chunking Methods on Retrieval-Augmented Generation compares eight methods across nine datasets, and on one metric the gaps look small: fixed-size chunking hit 87.71% average Accuracy@5 against Recursive Semantic at 89.36%. On another metric they are enormous. GraphSeg led Recall@10 at 78.16% average while fixed-size managed 44.75%.

Both things are true. If the engine only needs one good passage, a blunt split usually finds one. If it needs to assemble several passages, or rank yours against a crowded candidate set, the blunt split loses badly. GEO lives in the second case.

#The cheap method is the one you will actually meet

The cost column in that second paper explains why you should not plan around sophisticated segmentation.

Fixed-size chunking ran in under a second on average. DenseX averaged 15.05 hours and LumberChunker 8.37 hours, while Recursive Semantic averaged 4.90 minutes. Several of the expensive methods did not finish at all: the authors report timeout failures past a 48-hour limit for DenseX and LumberChunker, and memory crashes for GraphSeg and TextTiling on large documents. Only four of the eight methods were consistently reliable. Their conclusion is blunt, that chunking is a more difficult and fragile problem than is often assumed.

Now apply that to an engine ingesting the open web rather than a curated corpus. LLM-assisted segmentation at eight hours per document does not survive contact with billions of pages. The economics push hard toward the fast, structural, and partly blind end of the range. Write for the method that scales, not the one that wins benchmarks.

#There is no single size to write for

You cannot pick a target paragraph length either, because production defaults disagree with each other inside a single vendor.

Google's Agent Search layout parser defaults to 500 tokens per chunk and accepts a configured range of 100 to 500. Its useful property is layout awareness: all text in a chunk comes from the same layout entity, such as headings, subheadings, and lists, and an optional includeAncestorHeadings setting appends the title and parent headings to chunks taken from the middle of a document. Vertex AI RAG Engine, from the same company, defaults to 1,024 tokens with 256 tokens of overlap.

Research on size points the same way. Rethinking Chunk Size For Long-Document Retrieval finds small chunks of 64 to 128 tokens best for concise factual answers and 512 to 1024 tokens better where broader context is needed, with 64-token chunks taking the highest Recall@1 on SQuAD at 64.1%. Embedding models differ too: the authors report Stella benefiting from larger chunks and Snowflake performing better with smaller ones.

So the same page will be cut at 100 tokens by one system and 1024 by another, sometimes with heading context attached and sometimes without.

#What survives an arbitrary cut

If you cannot control the boundary, the goal is to write passages that hold up wherever it falls.

Make each section answer its own question. A section that only makes sense after the previous one is a section that half the pipelines will present stranded.

Repeat the entity instead of referring back to it. "It," "the platform," and "the company" are cheap in a full-page read and expensive in a chunked one, because the antecedent may be two chunks away. Name the thing again.

Keep the claim and its qualifier in the same paragraph. A number three paragraphs from its scope, date, or sample size will be retrieved without them, and that is how accurate pages produce inaccurate answers.

Keep sections shorter than the smallest plausible window. A long, unbroken run of prose under one heading will be split blind, because no heading boundary is available at the point the splitter needs one. Frequent, descriptive subheadings give structural chunkers somewhere sensible to cut.

Caption your tables and lists in prose. Layout-aware parsers treat these as their own entities, which means a table can arrive with no surrounding sentence explaining what it shows.

None of this is new writing advice. It is the same advice that makes documentation readable out of order. What changed is the reason: the reader is now a retriever that will only ever see a few hundred tokens of your work, chosen by a rule you do not control.