What Makes a Page Worth Quoting
8 min read · updated August 4, 2026
Four properties, and each one is derived from a stage of the pipeline rather than observed in a case study. That matters, because a property derived from a mechanism survives the mechanism’s next update and a property inferred from twelve screenshots does not.
Deriving the properties instead of asserting them
Start from four facts about how a citation happens, each of which is either specified or observable rather than folklore:
- Retrieval selects passages, not pages. Documents are split before they are scored.
- The context budget is small. A handful of chunks survive, across every document fetched.
- A citation is a URL. The unit a reader is sent to is the whole page, whatever passage was used.
- Attribution is imperfect. Citations are generated rather than recorded, and some systems run a verification pass that re-checks a sentence against its cited chunk.
Each of the four properties below falls out of one of those. The full pipeline is in how assistants choose what to cite.
One: a passage that stands alone
From: retrieval selects passages. Whatever gets used will arrive without your title, your introduction or your previous paragraph. A passage whose subject is three paragraphs up is a passage that cannot be quoted, no matter how good the page is.
The test is mechanical: copy any four hundred words from the middle of your page into a blank document and read them as a stranger. If you cannot tell what they are about, that passage is not a candidate. The repairs — resolving pronouns, killing structural back-references, repeating the subject at paragraph starts — are worked through in writing pages a model can quote accurately.
Two: a claim specific enough to be checked
From: the budget is small. Only a few passages survive, so the selection is competitive, and generic prose loses to specific prose for a reason that has nothing to do with any ranking system: there is nothing in it to extract. “Consider your requirements when choosing a chunk size” contains no fact. “At four characters per token, a 600-token chunk is about 380 words, so a section under that length usually arrives whole” contains three.
Specificity also has a second-order effect that matters more than it looks. A checkable claim is a claim somebody can verify and then rely on, which is what turns a reader into a citer. A hedge cannot be verified, so it cannot be relied on, so it is never quoted by anybody — human or otherwise.
The forms that work:
- A number with its unit and its conditions.
- A derivation the reader can redo. Arithmetic in front of them beats a figure they must trust, and it cannot go stale.
- An exact string. The real error message, the real parameter name, the real directive syntax.
- A negative. “This does not work when X” is rare, valuable and almost never written.
- A procedure with a pass condition. Something the reader can run and get an answer from.
Three: a URL that answers exactly one question
From: a citation is a URL. When a passage is used, the reader is sent to the whole page. If that page answers five questions, four fifths of it is noise to the person who arrived, and the page competes for five different queries without being the best answer to any of them.
The corollary is the consolidation rule from retrieval-friendly site architecture: three pages half-answering one question should be one page answering it. And the inverse case is just as common — one page answering five questions should usually be five pages, each of which can then be complete.
Stability belongs here too. A URL that moves loses the citations it earned, and unlike a link, a corpus that recorded the old URL cannot follow your redirect.
Four: scope and date inside the claim
From: attribution is imperfect and sometimes verified. A verification pass re-reads the cited passage and asks whether it supports the sentence. A passage that states its own scope answers that question in the affirmative on its own terms; a passage that states an unqualified generality invites the answer no, because the generality is not literally supported.
There is a plainer reason as well, and it does not depend on any system: a claim without scope is a claim that can be repeated in a context where it is false, and you will be the source of the false version. Putting the scope in the same sentence as the claim is the only reliable protection, because the sentence is what travels.
UNSCOPED Streaming reduces perceived latency.
SCOPED Streaming reduces perceived latency for responses over
about 200 tokens, where the buffered wait exceeds a
second; below that it adds complexity for no gain.Dates work the same way. A page-level “updated” line does not travel with the passage, so anything time-sensitive needs its date in its own sentence.
What does not make a page citable
The absent list is as useful as the present one, because these are the things most commonly done in the belief that they help.
- Length. A three-thousand-word page is many chunks, and if none of them is strong, having more of them does not help. The correlation people have noticed between long pages and visibility is a correlation with thoroughness, not with word count, and adding words without adding facts moves the wrong variable.
- Keyword repetition. Retrieval scores semantic and lexical similarity between a query and a passage; repeating a phrase eight times does not make the passage more relevant and does make it worse to read, which costs you the human citations that are the ones you can actually observe.
- A summary box at the top. Useful for readers, and frequently sold as an extraction aid. It is one more chunk, competing with the section that actually answers the question, and if it is a paraphrase rather than the answer it is a weaker candidate saying the same thing.
- Structured data as a substitute for prose. Facts that exist only in your JSON-LD are invisible to a text extractor — the mechanism is in structured data that machines read. Markup restates; it does not carry.
- An FAQ section bolted on at the end. Question-shaped headings help when the questions are ones people ask and the answers are real. A block of five invented questions restating the page is five weak chunks.
- Publishing more pages. Ten thin pages on one subject compete with each other for the same retrieval slot. One complete page is a stronger candidate than the sum of its scattered parts.
The pattern across all six: each adds volume where the constraint is quality per passage. The budget described at the top of this page does not care how much you wrote, only whether one of your passages beats somebody else’s.
The one-minute test
- Copy four hundred words from the middle of the page. Can a stranger tell what they are about? If not, fail on property one.
- Count the checkable facts in that passage. Numbers with units, exact strings, derivations, named negatives. Zero is a fail on property two.
- Write down every question the page answers. More than about two is a fail on property three.
- Take the strongest claim in the passage and ask when and where it is true. If the answer is not in the same sentence or the next one, fail on property four.
- Ask what a competitor would have to do to write the same passage. If the answer is “rephrase it”, the page has no reason to be the one cited.
What this page is not claiming
Everything above is a claim about extractability — whether a passage can be selected, quoted and relied upon — and every one of the tests is something you run yourself on your own text. That makes them tier-2 observable.
It is not a claim that a page with these four properties gets cited more often by any particular assistant. That would be a claim about the ranking and selection stages nobody outside the operator can inspect, and it cannot be established by anybody at your scale — the reasoning is in generative engine optimisation, what is real and what is sold. The reason these four are worth doing anyway is that each one also makes the page better for the human who arrives, which is a return that does not depend on the unverifiable half being true.