A citation in an AI answer is usually a paragraph or a sentence, not a page. The engine retrieves candidate pages, then some smaller unit inside them, and then writes an answer around what it kept. The published detail of how that selection works varies by provider and changes; what does not change is the asymmetry — the page author decides how easy the passage is to find, and the engine decides whether to use it.
This article is about the author’s half: what a quotable span looks like, how headings and opening sentences frame it, and which structures a parser can lift without guessing. It is not a claim about any engine’s ranking or a promise that a well-structured paragraph will be quoted.
The pipeline, in general terms
Most answer systems have the same broad shape: take a question, retrieve a set of candidate pages, cut them into passages, rank the passages against the question, and generate an answer with citations to the passages that survived. The exact cut and the exact ranker are proprietary, which is why this article stays at the level of structure rather than algorithm.
Two consequences follow. First, the unit of competition is the passage, not the page: a long page with one excellent section can compete on that section. Second, the passage has to make sense on its own — a fragment that says "this is why it matters" without the thing it refers to is a worse citation than a self-contained sentence.
What a heading does for a passage
A heading is a scope declaration. When a parser cuts a page into passages, the heading above a paragraph is often the cheapest available label for what the paragraph is about. That is why question-shaped headings work: they match the shape of the question, and they tell the reader (and the extractor) exactly what the next block answers.
The scanner’s rule for this is qa-headings, worth 4 points. It counts H2 and H3 headings that end in a question mark or begin with how, what, why, which, when, who, where, is, are, do, does, can, should or will. Three qualifying headings is a pass; one or two is a partial pass. The rule page is candid about the shortcut: "What we do" counts as question-shaped and "Our approach" does not, whatever either one actually answers.
The lesson is structural, not lexical. A heading that names the question the section answers is better than a heading that names the topic; the exact phrasing is yours to choose.
The first paragraph after the heading
If the heading is the label, the opening paragraph is the candidate answer. Engines and parsers tend to treat the first sentences after a heading as the dense part of the section, because that is where the author usually puts the claim. The scanner’s answer-first rule makes this concrete: of the first 30 heading-then-paragraph pairs, at least 60% must open with a paragraph of 80 words or fewer. Fewer than three pairs fails; three or more with a lower ratio gets a partial pass.
An 80-word opener is not a style rule; it is a proxy for "the answer arrives before the caveats". A section that opens with three sentences of context and puts the answer in paragraph four is harder to cut cleanly: the passage either includes the setup (and is bloated) or starts mid-thought (and is self-contained only by accident).
The practical rewrite is: state the answer in the first sentence, qualify it in the second, then spend the rest of the section on evidence, exceptions and method. A reader who wants the short version gets it; a reader who wants the argument keeps reading.
Structures a parser can lift
| Structure | Why it is easier to quote | What to watch for |
|---|---|---|
| Numbered steps | Each item is a claim with an ordinal; the boundaries are explicit. | Steps that depend on "as above" are not self-contained. |
| Comparison table | A row is already a tuple; the header supplies the meaning. | Layout tables and images of tables do not count. |
| Definition + example | One sentence defines, the next instantiates; easy to cut. | Definitions that require the previous section are fragile. |
| Numbers with units and sources | A figure with a denominator and a date can be checked. | Bare years are not findings; five bare numbers are not a dataset. |
| Direct quotation | Someone else’s words are a ready-made span. | Unattributed pull-quotes are decoration; the scanner only checks that a blockquote exists. |
The corresponding rules are deliberately modest: extractables (3 points) wants both a list and a table, and admits that a navigation menu and a layout table count; statistics (4 points) wants at least five numeric claims and explicitly does not count bare four-digit numbers; quotations (3 points) passes on any <blockquote>, attributed or not. Cheap checks, honestly labelled — the judgement about whether the content is worth quoting is still the writer’s.
What makes a passage fail on its own
- Dependent references. "This is why it matters", "as we saw above", "the second option" — without the antecedent, the passage is a fragment.
- One paragraph, three ideas. A cut lands in the middle of a topic change, and the retrieved text answers a different question than the one asked.
- The buried answer. The section opens with a definition of the problem and ends with the recommendation; the extractor takes the opening.
- Figures without denominators. "27%" of what, on which sample, measured when. A number that cannot be checked is not evidence.
- Content that is not in the response. A passage inside a client-rendered tab, a carousel, or an image is not in the HTML a crawler reads. This is the same failure as a JavaScript-only article, one level down.
How to test a page you have
The test is a simulation, not a measurement: cut the page the way a parser would, then read each cut on its own. A few commands get you the raw material.
# 1. Headings, in order curl -sS https://your-domain.com/page/ | grep -oE '<h[23][^>]*>[^<]*</h[23]>' # 2. The first paragraph after each heading is harder with grep; # a rough proxy is the first sentence of each paragraph: curl -sS https://your-domain.com/page/ \ | sed 's/<[^>]*>/ /g' | tr -s ' ' | grep -oE '[^.]+\.' | head -20 # 3. Count lists and tables (both should be non-zero) curl -sS https://your-domain.com/page/ | grep -c '<ul\|<ol' curl -sS https://your-domain.com/page/ | grep -c '<table'
Then read the headings as a list: if they read like a table of contents for the question the page is trying to answer, the structure is doing its job. If they read like sections of a brochure, the passages underneath are harder to retrieve regardless of how good the prose is.
What none of this guarantees
A page can be perfectly structured and still not be quoted: the engine may not retrieve it, may prefer another source, may not have crawled it, or may be answering a different question than the author imagined. Structure improves the odds of being extractable; it does not control selection.
The honest summary is the same one the rest of this series keeps arriving at: make the passage findable, make it self-contained, make the claim checkable. Then measure what happens instead of assuming it.