One page, one question: how to structure headings and FAQ blocks so an answer engine can quote a passage

Someone asks an assistant a question. The assistant fetches a handful of pages, splits them into chunks, and keeps the chunk that looks like an answer. If your page buries the answer under four paragraphs of context, the chunk that survives is the context, and you don't get quoted.

The unit that gets retrieved and quoted is the passage, not the page. Everything below follows from that: write pages whose passages survive being cut out and read alone.

What a chunk looks like by the time it reaches the model

Retrieval systems split HTML into pieces of a few hundred tokens, usually cutting near headings. The piece arrives without your navigation, without the paragraph before it, without the table of contents. A sentence that begins "as mentioned above" or "this approach" arrives with no referent.

Test any paragraph by asking: if I paste only this block into an empty document, does it still say something true and complete? If not, it is a weak chunk.

Should a page answer one question or several?

One. The heading, the opening line and the FAQ should all point at the same question, phrased the way a person would type it. A page that answers "how much does a 3-bedroom move cost in Singapore" will not also answer "how do I pack a kitchen" well enough to be quoted for either.

Splitting is not a rule about word count. A short page answering two questions is worse than two short pages, because the retrieval system may pull half of the first answer and match it against the second question.

When two of your pages answer the same question, merge them. Duplicate answers compete with each other and neither becomes the reference.

The first sentence under a heading has to be the answer

Readers who scan and extractors that chunk both want the answer in the first sentence, before the justification.

Which version would you quote?

## Why is my WordPress site slow?

Performance is a broad topic and there are many factors to consider. In this
article we will look at several areas that affect how quickly a page loads,
starting with the hosting environment and then moving on to caching...

## Why is a WordPress site slow?

A WordPress page is slow when PHP rebuilds the page on every request and the
finished HTML is never stored. The usual causes are no page cache, an expensive
uncached query on each load, and images served at full resolution.

The second version answers inside one sentence and stays understandable out of context. The first version only announces that an answer is coming.

Delete the announcement paragraph entirely rather than shortening it. Openings like "in this article we will cover" have no value as a chunk.

Write chunks that name their own subject

A passage that gets pulled out of your page loses its title. Pronouns lose their reference and the chunk becomes useless.

• Instead of "it handles retries automatically", write "the queue handles retries automatically".
• Instead of "this approach scales", write "the queue-based import scales".
• Instead of "most people prefer the second option", name what the second option is.

Numbers need units and a date. "5 working days" beats "fast turnaround". "Checked in October 2026" tells the reader the number has an owner and an expiry, and both are things a model can repeat without distorting them.

How should FAQ blocks be arranged?

An FAQ block is a set of small, self-contained answer chunks, and it works when you treat each item as its own page in miniature.

• One question per item, phrased the way it gets searched. "Do you charge a yearly fee?" beats "Pricing notes".
• The first sentence answers. Detail, caveats, exceptions come after, and they can be dropped without breaking the answer.
• No nested sub-questions. If an item needs a follow-up question, it needs its own page.
• No filler openings. "Great question!" and "That's a common concern" are the first thing a chunk carries and the first thing a reader skips.
• Only questions someone actually asked. Six invented questions that pad a section produce six useless chunks and dilute the ones that matter.
• Keep the answers in the HTML source. Content injected by JavaScript after load is invisible to a fetcher that does not run scripts. A <details> element is fine because the text is in the markup; a tab widget that loads its panel by request is not.

<h2>Frequently asked questions</h2>

<details>
  <summary>Does a heading have to be phrased as a question?</summary>
  <p>No, but a question heading matches how people search and gives the
  extractor a clean boundary. "Pricing" is a weaker heading than "How much
  does a delivery cost?"</p>
</details>

<details>
  <summary>Can an extractor read text inside a collapsed element?</summary>
  <p>Yes, when the text is in the HTML. A details element ships its content in
  the markup even while collapsed; a panel fetched by JavaScript after load
  does not.</p>
</details>

Structured data for FAQ is optional. Markup can describe a page, but the text is what gets extracted and repeated. Adding schema to thin answers produces well-labelled thin answers.

A page skeleton you can copy

# How much does X cost?          <- the question, in the searcher's words

One or two sentences that answer it, with the number, the currency and
what is included. No preamble.

## What is included in the price?

The first sentence states the inclusion. Then the detail.

## What changes the price?

Named factors, each with a short explanation.

## How do I start?

The concrete next action, one step, not a menu of five.

## Frequently asked questions

Four to six items, each answer-first and self-contained.

Notice the heading is not "Pricing". A heading that repeats the question gives the extractor a clean boundary and gives the reader a reason to stop scrolling.

Small things that break otherwise good passages

• Comparisons that say "the first option" without naming it, in a table where the column headers were cut off with the chunk.
• Answers that begin with "it depends" and never reach the actual answer. Put the dependency in the second sentence.
• Numbers with no date and no scope. A figure that was true last year, or true only for one project size, gets repeated as if it were general.
• A single page that is really six questions stapled together, each half-answered.
• Repeated boilerplate under every heading, so that three different chunks all start with the same sentence about the company.

Before you publish, read the first sentence of every section on its own

Scroll through the page and read only the first sentence under each heading, with the heading attached. If those sentences form a coherent answer to the page's question, the page will survive chunking. If any of them needs the preceding paragraph to make sense, rewrite it.

That check takes two minutes and catches most of what makes a page unquotable.