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.

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.