Strategy 5 AUG 2026 · 8 MIN READ

A model deciding what to say about your category does not read your page the way a person does. It retrieves a chunk of it. Somewhere between a paragraph and a section, pulled out of context, judged on whether it answers the question cleanly enough to be worth quoting. Everything about how you structure a page should follow from that one fact.

This is why beautifully written pages routinely lose to worse ones. A page with a long scene-setting introduction, a narrative build and the actual answer in paragraph nine is optimised for a reader who has already committed. The retrieval system never gets that far, or it gets there and finds a passage that only makes sense if you read the eight paragraphs above it.

Rule one: answer in the first sixty words

If the page is titled "how much does X cost", the first thing under that heading should be a direct, self-contained answer to how much X costs. Not context, not a definition of X, not a promise that you'll explain shortly. The answer, in one or two sentences, with the caveats immediately after rather than immediately before.

This feels abrupt when you write it and reads perfectly well when you publish it. Readers who wanted the answer get it; readers who wanted the reasoning scroll. The only party who suffers is the writer's instinct for a warm-up.

Rule two: make every section survive being taken out of context

Retrieval works on fragments. A section that begins "This is why it matters" or "As we saw above" is unquotable, because the chunk that gets pulled has no idea what "this" refers to. The fix is unglamorous: repeat the noun. Say "structured data" rather than "it", say "the audit" rather than "this process".

The same applies to headings. "The problem" tells a retrieval system nothing. "Why AI engines skip pages with client-side rendering" tells it exactly what the section below contains, which is the entire job a heading has to do now.

A useful test: copy any single section out of the page, paste it into an empty document, and read it cold. If you can't tell what it's about without the rest of the page, a model can't either.

Rule three: put the specifics in text, not in design

Numbers, comparisons and specifications are the parts models reach for most eagerly, and they are also the parts most often trapped in something unreadable. A pricing table rendered as an image is invisible. A comparison built in a JavaScript widget that populates after load is often invisible too. A specification list styled as a decorative graphic is decoration, not content.

This is the single most common gap we find on otherwise well-built sites. The information exists, the team can see it, and the fetcher gets an empty div. If a fact matters enough to influence a buying decision, it needs to exist as text in the initial HTML response.

Rule four: one page, one question

The mega-guide was a rational response to a ranking system that rewarded depth and dwell time. It is a poor fit for retrieval. A twelve-thousand-word page covering nine adjacent topics competes with itself: every chunk is diluted by the others, and the model has to work out which part of a sprawling document is relevant.

Splitting that guide into nine focused pages, each answering one question completely and linking to the others, tends to outperform it. Not because length is bad, but because a page that is unambiguously about one thing is easier to select and easier to quote.

There is a caveat. Nine thin pages are worse than one good one. The split only works if each page genuinely answers its question — with the specifics, the caveats and the edge cases — rather than existing as a stub that points at the others.

Rule five: write the questions your buyers ask, not the ones your category uses

Keyword research trained a generation of marketers to write for the phrasing that had volume. People talking to an assistant do not use that phrasing. They ask full, awkward, situational questions — "we're a fifteen-person agency and half our clients are ecommerce, what should we be using for this" — and the pages that answer those questions in kind get pulled in.

The best source for these is not a tool. It is your own sales calls and support tickets. The questions people ask before buying, in the words they use, are usually sitting in a transcript folder nobody has read for content ideas.

What this looks like in practice

Take a page you care about and restructure it in this order: a question-shaped heading, a sixty-word direct answer, then the reasoning, then the caveats and edge cases, then a short summary that repeats the answer with the qualifiers folded in. Keep every section self-contained. Make sure every number is text.

Then leave it alone for six weeks. Engines have to re-crawl before any of this registers, and the temptation to keep tinkering is how teams end up unable to tell which change did anything. One structural change, one baseline, one measurement window.