aeo

Chunking: why passages have to stand alone

A page is retrieved in pieces of a few hundred words. What splitting does to ordinary prose, and the three edits that make a section survive it.

Nothing retrieves your page. It retrieves a piece of it — a few hundred words cut out of the middle, scored against a question and handed to a model without the paragraph before it, and often without the heading above it or the title of the page it came from. That cut is chunking, and it happens to every page an AI system reads.

Which is why a section that reads perfectly in position can be worth nothing once it’s lifted. The prose isn’t bad; it’s load-bearing on things that didn’t travel with it. This is what splitting does to ordinary writing, and the three edits that make a section survive it.

This is also the most demonstrable item on the answer-readiness list, which makes it the easiest to get budget for. Copy one section out of your best-performing page, delete the heading, and hand it to whoever is asking why rankings are holding while clicks aren’t. If they can’t tell what product it describes, you have shown the problem rather than argued it.

Key Takeaways

  • The unit of retrieval is a passage of roughly 350–600 words, not the page. Every retrieval system that publishes a chunk size lands in that band.
  • The chunk boundary is not your section boundary. A fixed-size splitter cuts where the token count runs out, so a long section becomes two or three chunks and only the first keeps the heading.
  • A chunk that doesn’t say what it’s about is measurably harder to retrieve, not just harder to read.
  • Three edits fix it: cut backward references, name the subject inside every section, keep sections short enough to fit in one chunk.

A chunk is a few hundred words, not a page

The unit that gets retrieved is a passage of roughly 350 to 600 words — about the length of one ## section.

Google’s own ranking documentation confirms the unit without describing the mechanics: “Passage ranking is 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” (Google Search Central, retrieved 2026-07-31). Sections, not pages. How those sections get cut is unpublished.

The systems that do publish land in a narrow band. OpenAI’s file search states that “by default, max_chunk_size_tokens is set to 800 and chunk_overlap_tokens is set to 400,” so “every file is indexed by being split up into 800-token chunks, with 400-token overlap between consecutive chunks” (OpenAI, retrieved 2026-07-31) — roughly 600 words per chunk. Azure AI Search recommends “starting with a chunk size of 512 tokens (approximately 2,000 characters) and an initial overlap of 25%” (Microsoft Learn, retrieved 2026-07-31) — closer to 350 words. Anthropic’s write-up of contextual retrieval describes splitting a knowledge base into chunks “usually no more than a few hundred tokens” (Anthropic, 19 September 2024).

Three independent pipelines, one narrow band. Write for a reader who will see one section of your page and nothing else, because that is close to what a retrieval system actually holds.

Only one kind of splitter keeps your headings

Whether your heading travels with the text underneath it depends on which splitter reads you, and you don’t get to choose.

Azure’s documentation lists the approaches side by side. Fixed-size chunking defines a size “sufficient for semantically meaningful paragraphs (for example, 200 words or 600 characters)” with “some overlap (for example, 10-15% of the content).” Variable-sized chunking partitions on structure instead, noting that “embedded markup, like HTML or Markdown, have heading syntax that can be used to chunk data by sections.”

Only the second approach guarantees a heading stays attached to its passage. A fixed-size splitter counts tokens, and a heading is just more tokens — it lands wherever the arithmetic puts it. That’s the practical limit on heading work: question headings are worth writing because a structure-aware splitter turns them into retrieval handles, and they cost nothing when a fixed-size splitter drops them. What they can’t do is rescue a passage that only makes sense with its heading attached.

The overlap in every one of those defaults is the same admission. Four hundred tokens of overlap on an 800-token chunk is half of each chunk duplicated into the next one, and the reason is that the cut lands mid-thought. Azure’s suggested workaround for long documents is blunter still: “append the document title to chunks from the middle of the document to prevent context loss.” Some pipelines paste context back in. Assume the one reading you doesn’t.

What a chunk that lost its context costs

A passage that doesn’t say what it’s about is harder to retrieve, and the penalty has been measured in public at least once.

Anthropic’s contextual retrieval work opens on exactly this problem — splitting documents “can lead to problems when individual chunks lack sufficient context” — and the example is a financial filing that produced the chunk “The company’s revenue grew by 3% over the previous quarter.” Which company, and which quarter, are both elsewhere in the document. Adding chunk-specific context back in cut the top-20 retrieval failure rate from 5.7% to 3.7%, a 35% reduction, and to 2.9% when combined with keyword search (Anthropic, 19 September 2024).

That’s one pipeline over one corpus, and not the one serving Google’s answer surfaces. What generalises is the direction: roughly a third of the retrieval failures went away once the chunks were made to state their own subject. In Anthropic’s setup a preprocessing step supplied that context. On your site, nobody is going to.

Step 1: Read each section with the page deleted

By the end of this step you know which of your sections mean anything on their own.

Copy one ## section into an empty file, delete the heading as well, and read what’s left. Two questions: what is this passage about, and does anything inside it say so? Backward references are what usually fail — sentence-initial “it,” “this,” and “these,” plus “as described above,” “the table below,” and any figure referred to by position rather than by name. What an answer engine reads covers where those references break in the pipeline.

One distinction saves effort. A pronoun pointing at the section’s own heading is a smaller risk than one pointing at the previous section, because the heading travels under structure-aware splitting and the previous section never does. “It comes from two constraints meeting” opens a section on this blog titled “Where 40–60 words comes from” — fine if the heading is attached, meaningless if it isn’t. A pronoun reaching two sections back has no such fallback.

Verification: every section, read with its heading removed, still names what it’s about.

Step 2: Name the subject inside every section, not once per page

By the end of this step the entity each section discusses appears in that section’s own prose.

Naming the subject in the title, the H1, or the introduction does nothing for a chunk taken from the middle of the page. Titles, navigation, and headers are among the first elements discarded when a page is reduced to the text a model reads — what AI crawlers extract has the inventory — so a passage can’t borrow its subject from the page furniture.

In practice this is a search for placeholders: “the tool,” “our platform,” “the API,” “the service.” Each resolves against something the reader was told earlier. Replace one instance per section with the actual name — once is enough, since the goal is a chunk that identifies itself, not one that advertises.

Verification: each section names its subject at least once, in body text rather than in the heading.

Step 3: Keep a section shorter than one chunk

By the end of this step no section is long enough to be split into pieces that inherit nothing.

A 900-word section under a single heading is not one chunk. Under a 512-token splitter it is two or three, and only the first inherits the heading; the rest are anonymous middles with no subject and no question attached. The section reads as one unit to you and to a person scrolling, and as several orphans to a retriever.

Roughly 400 words is the working ceiling, from the smallest published default — 512 tokens, about 2,000 characters. Above that, add an ### and split, which buys the second half a heading of its own. A section that is genuinely one list is the tolerable exception: a cut mid-list loses less than a cut mid-argument, because the items were already parallel.

Verification: no section runs past about 400 words without a subheading inside it.

Before and after

The before is an ordinary mid-page section that reads fine in sequence:

## Retention

It's configurable. The default is 30 days and the maximum is 400. Changing it
applies to new data only — anything already written keeps the retention it was
given, as described above.

Lifted on its own, nothing survives. “It’s configurable” has no antecedent, “new data” belongs to a product that is never named, and “as described above” points at a paragraph that didn’t come along. The rewrite changes no facts:

## How long does the Events API keep event data?

The Events API keeps event data for 30 days by default, and the retention
window can be set to any value up to 400 days. Changing the window applies to
new events only: events already stored keep the retention they were written
with.

That’s 43 words, it names its subject twice, and it refers to nothing outside itself. The heading now states the question, which helps under a structure-aware splitter — but the passage no longer needs it, which is the part that matters when the splitter isn’t.

Checking it across a site

Two of the three steps above are mechanical, so run them as measurements rather than as a read-through.

Section length, without a terminal. No crawler reports words-per-section, but every crawler reports words-per-page, and custom extraction will count the headings: add a rule for //h2 and export both columns. Page word count divided by heading count is the average section length, and any page averaging over about 400 words per section has sections that will be split. It is a proxy and it hides the distribution — a page with one 900-word section and four 100-word ones averages out fine. Use it to rank pages for a read-through, not to clear them.

On markdown sources, the terminal version prints the real per-section count, longest first:

awk '/^#{2,} /{if (h) print n"\t"h; h=$0; n=0; next} h {n+=NF}
     END {if (h) print n"\t"h}' page.md | sort -rn

Anything above about 400 words will be split into pieces that don’t inherit its heading. Across the eleven posts published on this blog before this one it returns 111 sections, of which two exceed 400 words — the longest is 449, under “The extract list,” which is a list and so the tolerable case.

Backward references, without a terminal. This one scales cleanly in a spreadsheet. Extract //h2/following-sibling::p[1] — the first paragraph under each heading — export it, and in Sheets flag the openers that start with a bare demonstrative:

=REGEXMATCH(TRIM(B2), "^(It|This|That|These|Those|They)[ ,.]")

Filter to TRUE and you have the candidate list. In Excel the same test is REGEXTEST; in either, an older workbook without regex support can fall back to a set of LEFT() comparisons against the same six words.

The terminal version does the same job in one line:

awk '/^#{2,} /{h=$0; want=1; next}
     want && NF {if ($1 ~ /^(It|This|That|These|Those|They)[,.]?$/) print h" -> "$0; want=0}' page.md

Two of 108 opening sentences here trip it, including the one quoted in step 1. That’s a candidate list rather than a verdict — neither route can tell a pronoun pointing at its own heading from one reaching two sections back, and neither sees the references buried mid-paragraph. A person still reads the output. For the diagnostic pass across all five common faults, of which this is one, see five checks for a page that ranks but never gets cited.

At scale the same two questions become per-URL columns. GEOBee scores every page it crawls on the eight answer-readiness signals, of which the self-contained passage is part of the heaviest — the three lenses publishes each check and its weight, and a failing passage comes back as a per-URL finding with the fix attached.

One limit is worth restating. A page whose sections stand alone is a page a machine can split without breaking and lift from cleanly. Whether anything chooses to lift from it depends on competition, authority, freshness, and the question asked — none of which live in your passages. Answer Engine Optimization: a page-level guide sets out the other seven signals this one sits alongside, and the 40–60 word answer block is the same discipline applied to a section’s first sentence rather than to all of it.

On this page