Chunking

Chunking is the practice of splitting a document into smaller passages — chunks — that a retrieval system indexes and an AI answer engine retrieves and quotes. Because engines quote the chunk rather than the whole page, paragraph length and section boundaries decide which of your sentences can appear in an answer.

The term comes from retrieval engineering, but it earns a place in a publisher's vocabulary for one reason: it is the mechanism behind half the writing rules this library teaches. "Every section stands alone" is not a style preference — it is a response to how answer engines actually handle text.

Why do AI systems chunk documents?

Because retrieval and generation both work at passage scale, not page scale. In retrieval-augmented generation — RAG, in marketer's terms — a system cuts source documents into passages, indexes each one, and at answer time retrieves the handful of passages that best match the query for the model to ground its response in. Chunking is the cutting step, and everything downstream inherits its boundaries.

The consequence for publishers is blunt: the model composing an answer about your topic is usually reading a few passages from your page, not the page. A passage retrieved without its neighbors must carry its own meaning — define its terms, name its subject, contain its evidence. That retrieval pipeline, from crawl to quoted answer, is walked through step by step in how AI search works.

How do engines decide chunk boundaries?

Nobody outside the platforms knows precisely, and honest treatments say so. None of the major engines publishes its chunking parameters — sizes, overlap, boundary logic are all undisclosed. Two things are still solid. The observable output: answers quote passage-length excerpts, a few sentences at a time, not whole articles. And the working assumption in technical treatments, including iPullRank's AI Search Manual framing of retrieval and relevance engineering: document structure — headings, paragraphs, lists — is the natural seam a splitter follows, so structure is the part of chunking a writer can influence.

That uncertainty is worth respecting in both directions. Writing to a rumored chunk size of N tokens is optimizing for an unpublished parameter that can change without notice; writing so that every structural unit stands alone is robust to any boundary a system draws.

What are the common chunking strategies?

Three families recur in retrieval engineering, and knowing them explains why structure is the writer's lever. Fixed-size chunking cuts text into windows of a set length, often with overlap between neighbors — simple, fast, and indifferent to meaning, which is exactly its weakness: a window can end mid-argument. Structural chunking splits along the document's own seams — headings, paragraphs, list items — so each chunk inherits whatever coherence the author gave that unit. Semantic chunking groups text by topical similarity, drawing boundaries where the subject shifts rather than where a length limit falls.

A writer controls none of the engine's choices among these — and benefits from all three for the same reason. A page whose sections are short, single-topic, and self-contained produces coherent chunks under every strategy at once: the fixed window is less likely to orphan a thought it can fit whole, the structural splitter inherits clean seams, and the semantic splitter finds its topic shifts exactly at the section boundaries. Robustness to the unknown splitter is the practical definition of well-structured content.

What does chunking mean for how you write?

That formatting decisions are retrieval decisions. Each rule below exists because of what a chunk boundary does to the text it cuts:

These are the rules our own content contract enforces across the 400+ published pages of our 3 production builds [our data]. We did not adopt them as taste; they are chunking accommodations, and the contract exists so no page depends on a writer remembering that.

What is the evidence that passage-level writing matters?

The strongest controlled result in this niche is passage-level. The Princeton GEO study (KDD 2024) — the paper that named generative engine optimization — tested content-level edits in a benchmark of generative engines and measured visibility gains of up to 40% from additions like citations, quotations, and statistics in the source text. Its levers all operate inside the retrieved passage: what the chunk contains decides how it competes. A benchmark result is not a field guarantee, but its direction is unambiguous — the wins were in the words, and specifically in the words that travel when a passage is lifted.

That is also the honest limit of the concept: chunking explains why extractable passages matter, and nothing about writing for it can promise retrieval or citation. What it buys you is eligibility at the passage level — a page whose every section could be quoted, which is the shape getting cited by ChatGPT and every other engine-specific play depends on. The full passage-first writing system, evidence tiers attached, is our generative engine optimization guide.