Guide
How to Structure a Page So an LLM Can Quote It
The short answer
How do I structure a page so an LLM can quote it?
Put the answer first and make every part of the page survive being lifted alone. Our order across 400+ production pages: a 40–75-word answer block under the H1, 3–6 standalone takeaways, then question-shaped H2s whose first sentence answers the question, paragraphs of 2–4 sentences, and at least 1 real table — all served as crawlable HTML [our data].
Answer engines retrieve passages, not pages. That single fact rewrites the order of a web page: the parts that must survive being pulled out and read alone go first, and the parts that only make sense in sequence go last or not at all. This page is the layout we ship on every content page across our 3 production builds [our data].
Nothing about page shape forces a citation, and this page does not claim otherwise. What structure buys is that when an engine does reach for a passage of yours, the passage works.
What is an answer block?
An answer block is a short declarative paragraph directly under the H1 that answers the page's single question and carries at least one concrete number. On our builds it runs 40 to 75 words, and a build gate rejects any page outside those bounds so the rule cannot quietly erode [our data]. There is no intro above it — the first thing a reader or a retriever meets is the answer.
The test for whether a block is finished is to read it with the rest of the page covered. It passes if it names its own subject, answers the question in the first sentence, and needs nothing above it. It fails if it opens with "this" or "that" pointing at a heading, or if it teases a conclusion instead of stating one.
What order should the page elements be in?
Most extractable first, most contextual last. The order below is what our frontmatter contract enforces, and every element in it has a job that the element after it cannot do.
| Position | Element | Why it sits here |
|---|---|---|
| 1 | H1 stating the page's question | Labels the whole document with the query it answers |
| 2 | Answer block, 40–75 words, 1 number | The passage most likely to be lifted whole |
| 3 | 3–6 standalone takeaways | Quotable facts that survive alone; also the page's skim layer |
| 4 | Question-shaped H2 sections | Each one a retrievable unit tied to a distinct question |
| 5 | At least 1 real table | Figures and comparisons in a liftable, period-stamped form |
| 6 | Limits, caveats, and what not to do | Honest closing that needs the page's context to land |
Two consequences follow. First, the classic essay shape — context, build-up, conclusion — is exactly inverted, because a retrieval system that truncates you mid-build never reaches your conclusion. Second, nothing early on the page may depend on anything later. The mechanics of how documents get split into retrievable units are covered at chunking.
Why do H2s have to be questions?
Because the heading is the label a retrieval system attaches to the passage beneath it, and a question phrased the way people ask is the closest that label can get to the query. "Pricing" describes a topic; "How much does it cost?" matches an ask.
Set the evidence tier honestly: no engine documents a heading preference, so this is a plausible mechanism rather than a proven lever. It costs nothing, it improves the page for human skimmers, and it forces a discipline that matters more than the headings themselves — one question per section, and one primary question per URL. When a section drifts into answering two questions, split it.
The retrieval-and-relevance framing behind this way of working is laid out at length in iPullRank's AI Search Manual, which is a technical reference rather than a dataset — useful for the model of how retrieval works, not for numbers.
Why do paragraphs have to be short?
Because chunking does not respect your sentences. Documents are split into units before they are embedded and retrieved, and a 9-sentence paragraph is likely to be cut somewhere in the middle — leaving half a thought that reads as an incomplete claim. A 3-sentence paragraph either survives intact or fails as a complete sentence.
Short paragraphs also expose weak writing, which is a feature. A claim that needs six sentences of setup usually needs a source instead. Putting a sourced figure inside the quotable sentence is what turns structure into substance: the Princeton GEO study (KDD 2024) measured visibility lifts around 40% in its benchmarks for passages enriched with citations, quotations, and statistics — a lab result on the paper's own corpus, not a field guarantee, but a clear signal that shape and evidence are one job.
What did the page that earned our one AI Overview citation look like?
It followed this order exactly, and it was a definition page. Three days into our insurance lead-gen build we shipped a glossary entry whose opening line was a single quotable sentence defining the term, with DefinedTerm markup and primary-source-cited figures in the sentences underneath. Dated manual checks of the live result showed it as a cited source in the AI Overview for that term within days of publication, including a hyperlinked brand mention in the answer body [our data].
We record that as an observation with an n of 1. A new page on a new domain ships structure, markup, and sourcing at once, so nothing isolates a cause, and no tool reports AI Overview presence as a dimension we could check against. The eligibility half of that story — what Google actually requires before any page can appear — is in how to show up in AI Overviews.
Does the structure need to be in the markup or the words?
The words. Structured data describes a page to machines; the passages an engine quotes are the visible text. Google's own AI features documentation puts eligibility at indexed and snippet-eligible with no AI-specific markup requirement, and its generative-AI optimization guide points at content quality rather than markup. The trade-off between the two layers is worked through in JSON-LD vs visible HTML.
One thing does have to be true at the markup level: the text must exist in the
raw HTML response. Most AI crawlers execute no JavaScript, so a page assembled
client-side has no answer block as far as they are concerned. The 30-second
check is a curl request with an AI crawler's user agent, confirming the answer
text appears in the source. The crawler-permission side of the same problem is
in how to get cited by ChatGPT.
When is this structure the wrong shape?
When the page's job is not answering a question. Sales pages, brand narratives, and long-form essays lose something real when they are forced into answer-block order, and converting a working landing page into a Q&A layout to chase citations is a trade most sites should refuse — the click economics of AI answers do not currently pay for a damaged conversion path.
Against our own interest as people who build answer-first libraries: if your site is 12 pages and none of them are informational, this whole discipline has nothing to attach to. Where it earns its keep is a reference library that people arrive at with questions — the wider system for building one is documented in the operator's guide to generative engine optimization.
Frequently asked questions
How do I structure a page so an LLM can quote it?
Answer block of 40–75 words under the H1, then 3–6 standalone takeaways, then question-shaped H2s that answer in their first sentence, with 2–4-sentence paragraphs and at least 1 real table. Every unit must make sense read alone.
What is an answer block?
A short, plain, declarative paragraph placed directly under the H1 that answers the page's single question with at least one concrete number. On our builds it runs 40–75 words and a build gate rejects pages outside those bounds [our data].
Do question-shaped headings actually matter?
They matter as retrieval handles: a heading phrased the way people ask lines up with the query and labels the passage beneath it. No engine documents heading preferences, so treat this as a plausible mechanism with a low cost, not a proven lever.
How short should paragraphs be?
2 to 4 sentences. Long paragraphs get split mid-thought when a page is chunked for retrieval, and half a paragraph rarely reads as an answer. Short blocks also fail more gracefully — the worst case is a complete sentence.
Does this structure work for classic search too?
Yes, and that is the practical argument for it. The same self-contained passages that answer engines lift are what featured snippets have rewarded for years, so the page is built once for both surfaces rather than twice.
Can structure alone get a page cited?
No. Google's documentation puts eligibility at indexed and snippet-eligible, and selection is competitive against everything else that clears that bar. Structure makes a page easy to quote; it does not decide whether anything quotes it.