The chunk, not the page: content an AI can actually extract

The page is read by humans. The chunk is retrieved by machines. And a page that works perfectly for a human reader can fail the retrieval system entirely.

Everything you were taught about writing good long-form content is optimised for a human reader. Build a narrative. Lead with context. Pay off the introduction in the conclusion. Let the argument accumulate. All of it assumes one reader, moving top to bottom, holding the whole page in their head. And none of it is optimised for the retrieval system that now decides whether an AI answer mentions you at all.

So let’s notice the sentence that this whole lesson turns on. The page is read by humans, the chunk is retrieved by machines, and this is not the same thing. A retrieval system does not ingest your article as a whole. It cuts it into segments and judges each segment on its own. Which means a brilliant introduction cannot rescue a weak middle section, because the machine may never see the two together.

Three numbers define the problem. Roughly five hundred tokens per chunk, which is about three hundred and fifty to four hundred words extracted at a time. Three to eight chunks passed to the generator per query, which your content is competing for against every other indexed source. And zero, which is the amount of context a chunk carries about what came before or after it on the page. That last number is the one that changes everything, and it pairs directly with the funnel in the five-stage retrieval funnel.

Zero carried context is the whole problem

When a system extracts a passage from your content, it does not know what your introduction said and it does not know what your conclusion will say. It sees only what is inside the window it cut. If that window is not independently coherent, the chunk fails. Let’s make that concrete by handing the same page to two readers.

The human reads your introduction for context, follows the build-up, resolves “as noted above” from memory because the earlier paragraphs are still in their head, and reads a table together with the paragraph that explains it. The human understands the full page. The retrieval system gets chunk four with no introduction, hits “as noted above” with no prior chunk to resolve it against, finds “it” with no antecedent anywhere in the extracted text, and receives a table stripped of the paragraph that gave it meaning. The result is that the system drops the chunk or misuses it.

So “as noted above” is not a stylistic tic here. It is a retrieval failure. Every navigational phrase you write for a sequential reader, see below, as we discussed earlier, as we will explain, becomes an unresolvable broken reference the moment the chunk is extracted. The design test is blunt: open your content at random, read any four-hundred-word window, and you should understand exactly what is being claimed and what it means. If you cannot, neither can the machine.

Semantic sharpness beats comprehensiveness

There is a second failure that hides inside “good” writing. A well-crafted two-hundred-word paragraph that covers a problem, its cause and its solution is logically unified from a writing perspective. From an embedding perspective it is three topics blended into one vector, and a blended vector matches nothing well. It scores too low for every individual query it competes on, because it is not sharply aligned to any single one of them.

Meanwhile a competitor who wrote three separate headed sections, one for the problem, one for the cause, one for the solution, produces three sharp vectors, and each wins its own query. This is the part that feels counterintuitive: covering more in less space is a disadvantage in retrieval, not a virtue. Semantic sharpness beats comprehensiveness. One claim per headed section, so each vector sharpens and each competes on a query it can actually win.

This connects directly to how complex queries get answered, which I cover in the five-stage retrieval funnel. A question does not run as one retrieval, it decomposes into several independent sub-retrievals, and the pools barely overlap. So the diffuse paragraph that tried to cover everything is not competing once and losing narrowly. It is entering several separate contests and losing each of them to a page that built one sharp section per sub-question. Modularity is not a tidiness preference. It is how you get to compete in more than one of those contests at all.

Headings are retrieval targets, not decoration

This is where the heading stops being a label and becomes infrastructure. When a system scores a chunk for topic match, the heading is one of the strongest signals it has for classifying what the section is about. A heading that reads “What is the cost of stockouts for retailers?” is directly matchable to a query about stockout costs. A heading that reads “A closer look” carries zero retrieval signal. It tells the system nothing.

So the heading is not a decoration anymore. Every vague, clever or narrative heading you write is a retrieval slot you are handing to a competitor who wrote a more specific one. That is not a small stylistic loss. In a world of independent sub-retrievals, the heading that mirrors the sub-question as a real user would type it is often the difference between being in the pool and being invisible.

The same facts, two extraction outcomes

Modularity is not about reducing the depth of your content. It is about how you structure the information inside it. The same facts can be written to extract cleanly or to fail entirely. Here is the difference, drawn from the course.

Watch what happens when your chunk competes against others in a live synthesis. The query is about the risks of vendor lock-in with CRM software. Your page contributes a chunk that reads: CRM vendor lock-in occurs when migration costs exceed the cost of staying on a suboptimal platform; for mid-market companies migration costs forty to one hundred and twenty thousand euros and takes six to nine months. Self-contained, scope quantified. A competitor contributes a chunk built on “as discussed earlier,” which is unresolvable, so it is dropped. A third source contributes a chunk citing a 2024 Gartner survey of 320 CRM buyers, of whom sixty-seven percent named switching cost. Also self-contained and sourced. The generator uses yours and the third one. The competitor, of course, is dropped. Same topic, three structures, two survivors.

Attribution has to live in the body

One more thing the chunk does not carry: your metadata. The author byline sits in the page header, not in the chunk. The publication date sits in the post metadata, not in the chunk. The company name, the references list, all of it lives outside the body text and is therefore invisible to the generator when it reads an extracted passage. If a claim needs a source or a date to be trusted, and that source is only in your byline or your footer, then it is absent from every chunk the machine ever reads.

So attribution has to move inline, into the body text of the section where the claim is made. Not “according to our research” with the research named at the bottom of the page. The source, the scope and the value belong in the same sentence as the statistic. This is one of the most common and most invisible ways good content quietly disqualifies itself.

The same applies to author expertise and to dates. “Our analysts found” fails, because “our” has no referent inside the chunk, so name the entity: “WordLift’s analysis of X found.” “Current best practice” fails, because “current” decays the moment the page ages and gives the system no fixed point to reason from, so give it the date. None of this is difficult writing. It is just writing that assumes the reader has no memory of the rest of the page, which, for the machine, is exactly the situation.

An entry point: write the chunk proposition-first

If you want one principle to start rewriting with today, it is this: lead with the proposition. A chunk that gets selected tends to do four things, and you can begin with the first three without any tooling. Make the heading the query it answers. Define the subject in the first sentence, even if you defined it earlier in the article, so the section stands alone. And put scope, source and value in the same sentence as the claim, rather than scattering them across the page.

That alone will pull most of your important sections up out of the failure zone. It is the entry point, not the whole method. In the course the full four-part proposition-first structure adds the fourth part, the implication that closes the section without pointing anywhere else, and I run it against the four structural failure patterns and a set of worked before-and-after rewrites so you can see the mechanism, not just the rule. The point here is only that you can start, and starting well changes outcomes.

You do not need to rewrite everything

The good news, and I mean this literally, is that you do not need to rewrite everything. A page produces roughly eight to ten chunks, and only the well-structured ones win retrieval slots. So the work is diagnostic first: find the sections that fail, and fix those. The two highest-frequency failures are catchable with nothing more than a text search. Read every H2 and H3 in isolation and ask whether it could stand alone as a real search query. Then run a find for “as noted above,” “see below,” “as we will explain,” and drive those to zero.

Those two checks are the front of a five-check Extraction-Readiness Audit that takes under ten minutes per page, and the full version, with the remaining checks and the scoring, is in the lesson resources. But even the two you can run today will show you, quickly, how much of your best content is currently being cut before the machine ever gets to judge whether it is any good.

Where this goes next is the sentence level. A chunk can be perfectly modular and still lose because its claims are vague, and vagueness, it turns out, is not a soft writing problem. That is vagueness is a disqualifier.