How to structure content for AI: the section, not the page, is the unit

How to structure content for AI comes down to one question an extractor has to answer about your page: where does the passage that answers this begin, and where does it end. Headings draw those boundaries, the first sentence under each one carries the claim, and tables carry anything with more than two variables. This chapter is the template, with the numbers that make each rule checkable.

Read this first

Structure is the second problem. The first is whether an engine can fetch your page and find text in the delivered HTML — that is how AI engines pick sources, and a page that fails it gets nothing from this chapter.

What to say is also a separate question from how to lay it out. The writing side — which claims are worth making and how to phrase them so they survive being lifted — is what makes content citable by AI. This chapter assumes you already know what the page is for.

The unit that gets extracted is a section, not a page

An answer engine does not quote your article. It quotes a passage and attributes it to your URL. So the design target is a page made of passages that each stand alone, rather than an essay that only makes sense read in order.

That has a concrete consequence most style guides get backwards: transitions between sections are dead weight. A sentence like "having covered the first part, we now turn to" only works inside a linear read, and it costs you the first line of a section where the claim should be.

The template

Six rules. Every one of them is checkable without a tool, which is why they are stated as numbers rather than as advice.

Write h2s that survive being read as a list

Pull every h2 out of your page and read them in order, with nothing else. If that list reads as a summary of the article, the structure is right. If it reads as a table of contents made of nouns, it is wrong.

This works because a heading is the only part of a section an extractor can read cheaply before deciding whether the section is relevant. A heading that names a topic makes it guess; a heading that states a claim answers the question outright.

The test is blunt because the failure is blunt. "Overview", "Background", "Implementation" and "Conclusion" tell an extractor nothing about what is underneath them, and they are the four most common h2s in bad documentation.

The 80-word rule, and why that number

Put the answer in the first 40 to 80 words under each heading. The lower bound exists because a claim shorter than that usually omits its own conditions and stops being true when lifted. The upper bound exists because a passage longer than that starts to depend on the sentence before it.

This is a working rule, not a measured threshold. We have not tested citation rates against passage length, and we say so rather than dressing a convention up as a finding. What we can point at is the failure mode it prevents: a section whose first sentence is context and whose answer arrives in paragraph three cannot be quoted without also quoting the setup.

Use a table whenever there are three variables

Prose is a bad container for structured facts. Three sites, two attributes each, written as sentences, becomes a paragraph nobody can extract a single row from. The same thing as a table gives an engine six addressable cells.

The rule of thumb: if you catch yourself writing "A does X while B does Y and C does Z", stop and make it three rows. Our own surveys are written that way for exactly this reason, and the tables are the part that gets read.

FAQ questions have to be somebody else's words

Write the question the way it gets typed, not the way it would be phrased in a meeting. "Does blocking GPTBot stop ChatGPT citing me" is a real question shape. "Considerations regarding crawler management" is not a question at all.

Run each intended question through autocomplete before committing to it. If the phrasing produces nothing and a rougher version does, use the rougher version — the clumsy one is the one people actually type.

Where structure cannot help you

None of this makes a thin page worth citing. Structure decides whether a good claim can be found and lifted; it has nothing to say about whether the claim is worth lifting. A well-structured page with nothing to assert is a well-organised nothing.

It also will not survive a rendering problem. Our survey of 27 homepages found six with no h1 at all, and one of those delivered 3 KB of loader — every structural decision on that page exists only after JavaScript runs. That write-up is a missing h1 tag on 6 of 27 homepages, and it is worth reading before you spend a day on heading hierarchy.

And we cannot tell you that following this raises citation rates. No public data ties passage structure to selection, and we are not going to invent a number. What the template does is remove the failure modes we can observe — unquotable sections, unaddressable facts, questions nobody asks.

Three ways this goes wrong

Each of these produces a page that looks fine to its author and reads as unquotable to a machine, which is the worst combination — nothing signals that anything is wrong.

1. Headings written last, as labels for finished paragraphs. They end up describing the shape of the text instead of stating what it says.
2. The answer buried under a preamble. Every section that opens with "before we look at this" has moved its own claim out of reach.
3. An FAQ invented at the desk. Questions nobody types match nothing, and the block reads as filler to a person as well.

The deliverable: how to structure content for AI in five checks

Run these in order on one page you care about. The list is deliberately mechanical, because judgement about structure is exactly what erodes when you are close to your own draft.

1. Fetch the page with curl. Count h1 tags — the answer must be one.
2. Extract every h2 into a flat list. Read it. If it is not a summary, rewrite the headings before touching anything else.
3. For each section, delete everything after the first sentence and check whether that sentence still answers its own heading.
4. Find every paragraph containing three or more comparable facts and convert it to a table.
5. Put each FAQ question through autocomplete and replace any that return nothing.

Steps two and three catch most of it. Running the whole audit across every page rather than the one you remembered to check is what QueryWin is being built to do.

Common questions

How many h2s should a page have?

As many as it has claims. A page with one claim and eight headings has seven headings holding filler, and that is easier to see once you read them as a list.

Does heading order matter?

For a reader, yes. For extraction, less — each section is addressed independently. Order the page for the person and the structure will already be fine for the machine.

Should every page have an FAQ block?

Only where real questions exist. A page that has answered everything in its body does not need to restate it, and a padded FAQ dilutes the page it sits on.

Is there a length target for the page itself?

Not one we would defend. We have measured page length against other things and found no clean relationship worth quoting, so we set targets per section instead — which is the unit that actually gets used.