Blog · Content that gets cited

Chunking: how your page is cut up before it is read

Published 7 October 2026 · Updated 12 October 2026 · 8 min read

Chunking: how your page is cut up before it is read
Photograph: Mario Badilla / unsplash

The short answer: Chunking is the step where a retrieval system cuts your page into passages of a few hundred tokens, embeds each one on its own, and scores those fragments against the question. The engine rarely reads your page. It reads two or three pieces of it. A passage that does not name the subject, carry the number and stand up alone is a passage nobody can quote, however good the page around it was.

Most advice about writing for AI stops at the page level. The machine does not work at the page level, and that mismatch is where a lot of otherwise strong content quietly fails.

What a splitter does to your HTML

The sequence is dull and worth knowing. Boilerplate goes first: navigation, footer, cookie banner, sidebar. What is left gets flattened into text. That text is then cut at a budget, usually counted in tokens or characters, with a slice of the previous chunk repeated at the start of the next so a sentence straddling the join is not lost. Each chunk is embedded as its own vector. At query time the question is embedded too, the closest few chunks come back, and those chunks, not your page, are what the model writes from.

Microsoft's guidance for Azure AI Search, updated 31 August 2026, recommends starting at 512 tokens with 25 percent overlap, which it puts at 128 tokens of repeated text. The same page recommends 2,000 characters with 500 of overlap for the character based splitter, and says 512 tokens is roughly 2,000 characters, so the two recommendations agree rather than conflict. That is one vendor's documentation for one enterprise search product. We looked for equivalent figures in the public documentation of the five engines we test against on 12 October 2026 and found none, so read these numbers as the ones a comparable system puts in writing, not as the settings your page will meet.

The size of that budget changes everything downstream. The same Microsoft page runs one NASA e-book through its own splitter at several settings, all with overlap set to zero: 5,000 character pages produce 34 chunks, 1,000 character pages produce 172, and splitting at sentence boundaries produces 13,361. One document. One parameter. Three orders of magnitude between the extremes.

You do not get to set that parameter. What you control is where the natural seams in your text fall, so that whatever budget a system uses, the cut lands somewhere survivable.

Bigger chunks are not safer chunks

The intuition says long passages carry more context and therefore win. Measurement says something more awkward.

A public evaluation of chunking strategies published by the vector database company Chroma on 3 July 2024 scored several splitters at the token level across five corpora, retrieving five chunks per query and embedding with text-embedding-3-large. Recursive character splitting at a 200 token maximum with no overlap found 88.1 percent of the relevant text, at 7.0 percent precision. At a 400 token maximum with 200 of overlap, recall was the same 88.1 percent while precision fell to 3.3 percent. In that setup, doubling the chunk bought no recall and halved the signal to noise ratio. The authors say plainly that their dataset is small and limited in diversity, so treat it as one careful experiment on five corpora, not as a law of retrieval.

Read that as a dilution curve. A long passage can still be retrieved, but most of what it drags into the model's context is irrelevant to the question, and the sentence you wanted quoted is competing with four hundred words of its own neighbours. The best precision in that study, 8.0 percent, came from a cluster based semantic chunker the authors built themselves, capped at 200 tokens and averaging about 103, which is roughly one tight paragraph. It is their own method scoring well on their own benchmark, which is a reason to read the direction and not the decimal.

So the practical target is not a long, flowing section. It is a paragraph of 100 to 200 words that would survive being lifted out with a pair of scissors and handed to someone who has never seen your site.

Five failure modes we keep finding in audits

These are the chunking problems that come up repeatedly in our audit work. We have not counted them across audits, so the list is not ranked by frequency and we cannot tell you how common any one of them is across the web.

Orphaned pronouns. A paragraph that opens with "It supports", "They charge" or "This means" loses its subject the moment the chunk before it is dropped. The passage is still retrievable. It is no longer attributable, so an engine that wants to name a brand cannot find one in the text it is holding.

The number and its unit in different chunks. A price in a table, a currency and billing period in the prose two hundred words above it, a splitter that cuts between them. The engine now holds a bare figure. We have traced wrong prices in answers back to exactly this split during audits, though we cannot see inside an engine to prove the cause, and we have no tally that would let us call it the leading reason. It does make pricing pages and what AI says your product costs a layout question as much as a wording one.

Headings doing no work. Markup is a free boundary hint. Microsoft's own documentation notes that embedded HTML or Markdown heading syntax can be used to split content by section. A page with one H1 and nine hundred unbroken words gives a splitter nothing but a character count to cut on, and it will cut mid argument. A page with an honest H2 every two hundred words is effectively telling the splitter where the seams are.

Accordions and tabs. Content that only exists after a click often does not appear in the HTML we get back when we fetch the page without executing its scripts. Whether a given engine executes them is something we cannot observe from outside. That is an access problem before it is a chunking problem, covered in can AI crawlers actually read your site.

Preamble. Four hundred words of throat clearing before the answer pushes the answer into chunk three, and chunk three is competing with every other page's chunk one.

Google's own documentation describes passage ranking as a system that identifies individual sections of a page to judge relevance, so none of this is special to generative engines. It is just far more consequential when the fragment is quoted rather than linked.

Three checks you can run this afternoon

The scissors test. Copy any single paragraph from a page you care about into a blank document. Read it cold. Does it name the company, say what the thing is, and carry its own number with its own unit? If it needs the paragraph above it, a splitter will eventually take that paragraph away.

The character count between headings. Open the page, count characters from one H2 to the next. A section longer than about 2,000 characters is longer than the page length Azure AI Search recommends as a default, so a system using that setting would cut it somewhere you did not choose. We use 2,000 as a working threshold because it is the one figure that is documented, not because we have seen it confirmed by an engine. Add a subheading, or split the section.

The pronoun sweep. Search the rendered text for paragraphs beginning with It, This, They, These or That. Each one is a chunk that may arrive at the model without its subject. Replacing the first pronoun of a paragraph with the actual noun costs nothing, and it keeps the subject inside the passage wherever the cut happens to land.

The self-check has ten of these in one list, including the access and rendering tests that have to pass before chunking matters at all. Chunking only decides what gets quoted once the page has been fetched inside the engine's time budget, and slow pages get dropped before they get read regardless of how well they are structured.

Where this sits in the larger job

Chunk hygiene is cheap and it compounds. It is also not sufficient on its own. A beautifully segmented page, published on a domain the engines have no reason to trust, still loses to an average page from a source it does trust. That is the argument running through what makes a page citable by an AI engine. Good structure does not create demand for your page. It stops you losing retrievals you had already earned.

Honest limits

This post does not establish what any answer engine actually does. Searching the public documentation of the five engines we test against on 12 October 2026, we found no stated chunk size, no overlap value and no statement about whether passages are re-ranked after a first pass. Everything above is drawn from vendor documentation for a comparable enterprise search product, one public benchmark on five corpora, and what we observe in client audits. Absence of a published number is not evidence that the engines behave like Azure AI Search, and the token counts here are the shape of the problem rather than a setting to match.

The audit observations are also not a measured sample. We have not run a controlled study with a stated n, so where this post says we see something, read it as pattern recognition across client work, not as a statistic. Nor can we separate the effect of chunking from the effect of clearer writing, since a page rewritten so each paragraph stands alone is usually a better page in every other way. An audit at least records what changed and when, so the claim can be argued with later. The sample audit report shows how a finding of this kind gets evidenced.

FAQ

What chunk size do AI engines actually use? They have not published it, and we could not find it anywhere in their public documentation when we checked on 12 October 2026. Published guidance for comparable retrieval systems clusters between 200 and 512 tokens, so writing paragraphs that work at 150 words is a reasonable hedge against a range we cannot see.

Does adding more headings help? Usually, up to a point. Headings give a splitter a natural boundary and give the chunk a title to carry. Headings that describe nothing, or appear every thirty words, just add noise.

Should I repeat my brand name in every section? Repeat the subject, not the slogan. If a section is about your pricing, the word for your product should appear in that section rather than only in the introduction. That is one noun, not a marketing paragraph.

Do tables survive chunking? Poorly, often. A long table can be split across chunks, and header rows do not travel with the rows beneath them. Where a table carries something important, state the same fact in a sentence nearby.

Sources

Related reading

What makes a page citable by an AI enginePricing pages and what AI says your product costsSlow pages get dropped before they get readCan AI crawlers actually read your siteComparison pages that get citedPruning thin content to raise AI visibility