Chunk Theory: AI Reads Passages, Not Pages

Your page is never read the way you wrote it. Before an engine quotes you, it has already cut your writing into pieces and discarded most of them. Winning starts with knowing where the knife falls.

How does an AI actually read your page?

The pipeline behind a retrieval-based AI answer looks roughly the same everywhere. A crawler fetches your HTML. The boilerplate gets stripped: navigation, footer, sidebars, cookie banners. What remains is split into chunks, passage-sized segments of text. Each chunk is converted into an embedding, a numeric vector that encodes its meaning. Those vectors sit in an index. When a user asks a question, the question is embedded the same way, the index returns the chunks whose vectors sit closest to it, and a handful of top-scoring passages are handed to the language model, which composes the answer and cites some of them.

Notice what never happens in that pipeline: the model composing the answer never reads your full page. It sees perhaps three to eight passages, pulled from different domains, stitched into one context window. Your intro does not warm it up. Your conclusion does not land. Your competitor in that moment is not another website, it is another paragraph. The original GEO research paper demonstrated this concretely: passage-level edits, such as adding quotations, statistics, and clear sourcing, measurably changed how often content was carried into generated answers, without touching anything else on the page.

Some engines complicate the picture further by fanning a single question out into several sub-queries, retrieving passages for each, and merging the results before the model writes a word. That multiplies the lottery tickets in play, but every ticket is still a passage. Nothing in any modern answer pipeline rewards the page as a whole. The page is a shipping container. The chunks are the cargo, and customs only ever inspects the cargo.

What is a chunk, exactly?

Chunk sizes vary by system, but most implementations land in the range of a few hundred tokens, roughly 100 to 300 words, with boundaries drawn at headings and paragraph breaks where possible. Clean structural boundaries produce clean chunks. A page with descriptive H2s and tight paragraphs gets sliced along its own seams. A 2,000-word wall of text gets sliced arbitrarily, often mid-thought, producing chunks that begin in the middle of an argument and end before the payoff.

A chunk also carries very little context with it. Depending on the system, it may keep the page title and its nearest heading. It does not keep the author byline from the top of the page, the definition you gave two sections earlier, or the caveat you placed at the end. Whatever is not inside the chunk, or attached to it through structure and structured data, effectively does not exist at retrieval time.

Chunk size tradeoffs: too small versus too large

Chunk size is not a setting you control directly, since it is decided by the retrieval system ingesting your page, but understanding the tradeoff on either side tells you how to write so your natural section length lands in the workable middle. Neither extreme serves you.

How chunk size at either extreme degrades retrieval, compared to a section scoped to one idea.

The practical implication is straightforward: write each section as if you were choosing its length for a chunker, not for a human's attention span. One idea, stated completely, closed off before the next heading begins.

How chunk embeddings decide who gets cited

An embedding is a numeric vector, typically a few hundred to a few thousand numbers, produced by a model trained to place similar meanings near each other in that numeric space. When a page is chunked, each chunk is run through this embedding model and stored as a point in that space alongside every other indexed chunk, from your site and everyone else's. A user's question goes through the same embedding model and lands as its own point. Retrieval is then, at its core, a nearest-neighbor search: which stored chunks sit closest to the question's point.

This is why specificity and clean topic boundaries matter more than clever phrasing. A chunk that mixes your pricing philosophy with your onboarding process produces a vector that sits between two clusters of real questions, close to neither. A chunk that states one claim, in the vocabulary a buyer would actually use, produces a vector that sits squarely inside the cluster of questions it should answer. You cannot see the vector space directly, but you can reason about it: write the section so a reasonable person would say it answers exactly one question, and the embedding will tend to follow that same discipline.

Multiple chunks can and do get retrieved for a single query, which is part of why a coherent knowledge base outperforms a single strong page. When several of your chunks, from different pages, all sit near a cluster of related questions, you occupy more of the retrieved set for that topic, and the language model composing the answer sees your name attached to more of the evidence it is drawing from.

Writing so the right chunk gets retrieved, not just a plausible one

Getting some chunk from your site retrieved is a lower bar than getting the right one retrieved, the one that actually names you, states the claim you want associated with you, and carries the specific evidence that makes it worth quoting. Three habits close that gap.

1. Match vocabulary to the question, not to your internal jargon. If buyers ask "how much does a rebrand cost," a section titled "Investment" using the word "engagement" throughout will embed further from that question than a section that uses the words a buyer actually typed.
2. Keep the highest-value claim in its own section, not folded into a bigger one. If your single best proof point sits inside a 500-word paragraph about your general philosophy, its embedding is diluted by everything around it. Give it a heading of its own.
3. Duplicate the core claim in more than one place, in different phrasing. Because retrieval depends on vector proximity to the exact question asked, restating the same fact once in formal language and once in the phrasing a buyer would use gives you two chances to be the nearest neighbor instead of one.

None of this is guesswork you have to run blind. The practical way to check it is described in the 25-prompt audit: run your actual buyer questions against live engines, see which passages get quoted, and compare them against your own chunks to see where the vocabulary or scoping is costing you the retrieval.

Why page-level thinking quietly fails

Most professional writing is optimized for the exact opposite of retrieval. The intro builds tension. The argument develops. Pronouns refer back to nouns introduced paragraphs earlier. The key term appears once, then becomes "it" or "this approach" for the rest of the piece. That is elegant for a human reading top to bottom and hostile to a system scoring passages in isolation.

Consider a chunk that reads: "This approach also works well for consultants, and the results tend to compound within a quarter." Against any real question, that passage scores near zero, because "this approach" resolves to nothing. The meaning lived in a previous chunk, and the previous chunk did not make the retrieval cut. The same failure hits pages that save the answer for the end, and pages that try to cover ten subtopics at once: ten diluted topics produce ten mediocre chunks, none of them the strongest passage on anything.

This is also why two pages with identical information can perform completely differently in AI answers. The engine is not weighing your overall quality. It is comparing your third paragraph against someone else's third paragraph, one passage at a time.

The self-contained passage rule

A liftable passage has a consistent anatomy, and you can apply it mechanically:

• Heading as the question. Phrase the H2 or H3 the way a user would ask it. The heading travels with the chunk and anchors its relevance.
• First sentence answers directly. No wind-up. Full noun phrases, not pronouns: names, products, and methods written out.
• Two to four sentences of support. Include at least one specific, verifiable fact, a number, a date, a named source. Specifics raise a passage's retrieval score and its citation odds.
• Entities restated. If the section makes a claim about you, your name appears inside that section, not three sections up.

This produces mild redundancy across a page, and that is fine. Humans skim past repeated names without noticing. Machines depend on them. The craft of doing this without sounding robotic is its own discipline, which we cover in answer-shaped writing.

A before and after

Before: "Beyond that, this approach also works for founders, and results usually follow quickly." Read alone, that passage identifies nobody, claims nothing checkable, and answers no question. It is filler to a machine, whatever it meant in context.

After: "Passage-level rewrites, the four-week format described in this guide, work for venture-backed founders as well as consultants, because the deliverable is a rewritten set of core passages on the pages engines already crawl, not a new website." Same idea, but the chunk now carries the method's name, the audience, the timeframe, and the reason it works. Either version might get pulled into an answer. Only one of them does you any good when it is.

What does chunk theory mean for your name?

SEO ranks pages, GEO promotes brands, PEO names you, and the naming happens at the passage level. When someone asks an engine "who should I hire for X," the engine is not evaluating your website. It is retrieving passages that connect a name to a capability to a proof point, and most personal sites do not contain a single passage that does all three.

The typical about page interleaves biography, philosophy, and career history so thoroughly that no individual chunk states plainly who you are, what you do, for whom, and why you are credible. Fix that by building one dense bio block that stands entirely alone: name, role, specialization, one concrete proof point, in one passage. Then repeat the pattern across your service descriptions and case entries. We walk through the full structure in the machine-readable about page teardown, and the identity layer underneath it in structuring your identity for machines. If you maintain a set of canonical reference pages about your work, the kind described in building a knowledge base AI will cite, apply the passage rule to every section of them.

Common chunking mistakes that cost citations

Five failure patterns account for most of the losses we see when auditing personal sites:

• The buried answer. The direct answer arrives in the final section, after 1,200 words of context. Engines quote whoever answered in their first paragraph, and the context never gets retrieved at all.
• The pronoun bridge. A section opens with "This is why it matters so much," where both "this" and "it" resolve to a previous section. The chunk is grammatically complete and semantically empty.
• The mega-section. One heading, 700 words, three distinct ideas. The chunker splits it arbitrarily, and every fragment inherits a heading that only describes the first idea.
• The styled-div page. Headings built as styled divs instead of real heading tags. The visual hierarchy is invisible to the chunker, so the seams fall in the wrong places on an otherwise well-written page.
• The orphan stat. A strong number with no entity attached: "conversion doubled in eight weeks." Doubled for whom, measured by whom? A statistic without an owner is retrievable but not attributable, and attribution is the entire point.

None of these are content problems. They are packaging problems, which is what makes them cheap to fix and expensive to ignore.

The passage optimization checklist

Run any page you care about against this list. Every item is checkable in minutes:

• One idea per H2 or H3 section, never two.
• Heading phrased as the question the section answers.
• First sentence of each section is a complete, standalone answer using full names.
• No opening sentence contains a pronoun that points outside its own section.
• Each section runs 75 to 300 words.
• At least one specific, verifiable fact per section, with a source where it matters.
• Your name, or the entity the page is about, restated in every section that makes a claim about it.
• Semantic HTML throughout: real heading tags and real lists, not styled divs.
• Key definitions repeated where they are needed rather than referenced by link alone.
• Structured data on the page naming the person or organization the passages describe.

A page that passes all ten is not guaranteed a citation. A page that fails most of them is guaranteed to lose to one that passes, given roughly equal authority.

How to test whether your chunks survive

The cheapest test requires no tooling. Copy one section of your page, alone, into a blank document. Read it as a stranger. Can you tell who it is about, what it claims, and why you should believe it? Then run the machine version: paste that single section into an AI assistant and ask, "What question does this passage answer, and who is it about?" If the model cannot name you from the passage, the passage fails, and no retrieval system will connect it to your name either.

After rewriting, verify against live engines. Ask the real questions your buyers ask, note which sources get quoted, and compare the winning passages against yours. The pattern is usually visible within minutes: the cited passages are self-contained, specific, and named. If you would rather have this run as a structured audit across your whole footprint, that is exactly the baseline work described in our services.