How to write answer-first content that LLMs can quote

What answer-first content is

Answer-first content is writing that puts the complete answer at the start of a page and at the start of each section, then uses the rest of the section to explain, qualify and support it. It is the inverted pyramid of journalism applied at the level of the passage rather than the article. Nielsen Norman Group describes the inverted pyramid as a structure in which the most important information is presented first, followed by supporting detail in descending order of importance.

Answer engines make that structure necessary, for two reasons.

First, they do not read pages; they read passages. A retrieval-augmented system splits a page into chunks and scores each chunk against the question on its own. The Dense Passage Retrieval paper by Karpukhin et al. split Wikipedia into "disjoint text blocks of 100 words" as its basic retrieval unit, and many production systems work at a similar scale: a heading plus a paragraph or two. Whatever sits in the first hundred words after a heading is what the retriever sees.

Second, language models use what they retrieve unevenly. The Lost in the Middle study by Liu et al. found that model performance "is often highest when relevant information occurs at the beginning or end of the input context" and degrades in the middle. A passage that states its answer up front is easier to use than one that reaches it at the end.

None of this is a vendor requirement. Google's documentation on AI features says there are "no additional requirements to appear in AI Overviews or AI Mode". The method follows from how retrieval and generation work, described in What is Answer Engine Optimization.

The 40–70 word direct answer

The central unit of this method is the direct answer: a paragraph of roughly forty to seventy words that sits directly under the page title, with a shorter one- or two-sentence version under each major heading.

Forty words is about the minimum needed to name the entity, state what it is or does, and add one qualifying detail. Seventy words keeps the whole answer, plus its heading, inside a single hundred-word retrieval chunk. Longer than that and a chunker may split the answer in two, or a model may quote half of it.

A direct answer follows a fixed shape:

1. Sentence one names the entity and answers the question. "llms.txt is a proposed convention for a Markdown file at the root of a website that gives language models a curated overview of the site."
2. Sentence two adds the detail that makes the answer usable. What it contains, how it works, who it is for.
3. Sentence three states the scope or the limit. Who proposed it, what it does not do, when it applies.

There is no preamble. The paragraph does not begin with "In this guide", "Many people ask" or "Before we get into it". Those openings spend words the chunk cannot afford.

The length is easy to enforce in CI or in the CMS:

const words = (s: string) => s.trim().split(/\s+/).filter(Boolean).length;

const n = words(guide.short_answer);
if (n < 40 || n > 70) {
  throw new Error(`short_answer is ${n} words (want 40–70)`);
}

The GEO study by Aggarwal et al. tested nine ways of rewriting a source page and measured how much of each generated answer was drawn from it. Its authors report that their "top-performing methods, Cite Sources, Quotation Addition, and Statistics Addition, achieved a relative improvement of 30-40%" on their position-adjusted word count metric, while keyword stuffing offered "little to no improvement".

Put a source, a quotation from a named authority or a concrete figure in the direct answer or in the sentence immediately after it, not three sections down.

One question per heading

Each H2 and H3 should name exactly one question, and the first sentence under it should answer that question. The heading can be phrased as a question ("How long should the direct answer be?") or as the noun phrase people would type ("Direct answer length"). What matters is that a reader, or a retriever, can tell from the heading alone which question the section resolves.

Two failure modes are common: the clever heading ("Less is more") that tells a retriever nothing about the content beneath it, and the heading that covers several questions ("Length, tone and formatting"), which dilutes the answer to each. Split the second kind into one heading per question.

Inside a section, repeat the inverted pyramid: answer, then reasons, then examples, then edge cases. If a section grows past three or four paragraphs, it usually contains a second question that deserves its own heading.

In Markdown, the pattern looks like this:

## How long should a direct answer be?

A direct answer should be 40–70 words: long enough to name the entity,
state the answer and add one qualification, and short enough to fit
inside a single retrieval chunk together with its heading.

Forty words is roughly the floor because ...

### What happens if the answer is longer?

...

Name entities; do not lean on pronouns

Every paragraph should survive being lifted out of the page. That means naming the entity rather than pointing at it with "it", "this", "the tool" or "as described above".

Anthropic's engineering post on contextual retrieval gives the example. A chunk that reads "The company's revenue grew by 3% over the previous quarter" is accurate inside its document and useless outside it: the chunk does not say which company or which quarter, so a retriever cannot match it to a question about either. Anthropic's fix is to prepend a generated sentence of context to every chunk before indexing it. You cannot rely on every answer engine doing that, so write the context in yourself.

The rules that follow:

• Use the full name on first mention in each section, with the abbreviation in parentheses: "Generative Engine Optimization (GEO)". After that, use either form consistently.
• Do not start a section with a pronoun. "It also supports…" at the top of a chunk has no referent.
• Replace "above", "below", "earlier" and "as we saw" with the thing itself: "the 40–70 word rule", not "the rule above".
• Keep the entity name in the heading and in the first sentence beneath it, so that both heading-based and paragraph-based chunkers see it.

Sentence length, lists and prose

Short declarative sentences are easier to quote than long ones. A sentence a model can lift verbatim states one claim, has one subject, and does not depend on a subordinate clause three lines back. Around twenty words is a comfortable ceiling for a sentence that carries the answer; sentences that explain or qualify can run longer.

Lists and prose do different jobs:

Two cautions. Make each list item a complete sentence or a parallel fragment, so that an item quoted on its own still reads correctly. And never put the answer only in a table, an image or a diagram: Google's AI features documentation asks that "important content is available in textual form", and text is the only form every crawler can read.

A worked rewrite

Below is a typical blog-post opening, then the same information rewritten answer-first.

That is 66 words without an answer in them. The entity is named once, in the first sentence, and referred to as "it" five times afterwards. Nothing in the passage could be quoted in response to "what is llms.txt".

The rewrite is 69 words. It names the entity in the first sentence, answers the question, and adds two qualifications. The only pronoun, "It", refers to llms.txt inside the same passage, so the chunk stays self-contained.

The same discipline applies deeper in a page:

Before: It also works with the full-text version. This can get large, so you'll want to think about that.

After: The optional companion file, llms-full.txt, is a convention for putting the full text of the linked pages in one document. On a large site it grows substantially, so include only the pages worth a model's context window.

Editing checklist

Run this pass before publishing and after every update.