Document structure for answer extraction: headings as questions

Both extraction systems and readers navigate a long page the same way: they look at the headings, decide which section addresses their question, and read that part. A document whose headings describe topics rather than answer questions makes that impossible for either audience.

Headings are the question outline

The most effective single change to a long page is rewriting its headings so each one states the question the section answers, or the claim it makes. Topic-label headings are shorter and tell nobody anything.

Those right-hand headings are longer. They are also the difference between a reader scanning a contents list and finding their question, and scrolling through five plausible-looking sections. The extraction benefit is a side effect of the readability benefit.

One idea per section, and the section ends when it is answered

Sections that cover two topics cannot be extracted for either, because the relevant passage sits next to unrelated material. The test is whether the heading fully describes everything under it — if it does not, the section needs splitting.

• A section long enough to need its own subheadings usually wants to be two sections
• A section of two sentences usually belongs inside its neighbour
• Never let a heading level be skipped — a h4 directly under a h2 breaks the outline for assistive technology and for anything parsing structure
• Exactly one h1, stating what the whole page is about

The outline should read as a standalone summary

A useful check that takes thirty seconds: extract only the headings and read them in order. If that list tells the reader what the page establishes, the structure is sound. If it reads as a list of vague nouns, no amount of good prose underneath will rescue the page's navigability.

Weak outline — nothing learned from reading it:
  Introduction / Background / Our approach / Considerations /
  Best practices / Conclusion

Strong outline — the argument is already visible:
  What an answer engine actually extracts
  Headings are the question outline
  One idea per section
  Anchors, so a passage has an address
  FAQ markup worth adding, and the kind that is not
  Measuring whether any of it worked

Anchors give a passage an address

A heading with a stable identifier can be linked directly, which matters for three separate reasons — and the third is the one most sites miss.

1. 01Readers can link to the exact answer, which is how a page gets referenced in a forum reply or an internal wiki rather than described.
2. 02Search results can deep-link to the section, taking a visitor to the relevant passage instead of the top of a long page.
3. 03Your own internal links can point at a specific answer, so a related article links to the paragraph that supports its claim rather than to the whole page and a hope.

Generate the identifiers from content rather than by hand, keep them stable once published, and never renumber them — an anchor that changes silently breaks every external reference to it with no redirect available.

FAQ markup: worth adding, with a condition

A frequently-asked-questions section serves answer engines well, because the format is already question-and-answer. Structured data makes that machine-readable. One rule governs whether it is legitimate.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "How long should an extractable answer be?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Two to four sentences for the direct answer, with elaboration after it."
    }
  }]
}

• Answer in the markup exactly what the visible section answers — no expansion, no additional claims
• Use real questions people ask, not restatements of your headings with question marks appended
• Keep FAQ answers self-contained, since they are extracted with no surrounding page at all
• Do not mark up a whole article as one enormous question; the format is for genuine question-and-answer content

Formatting choices that affect extraction

The collapsed-content row is worth acting on. Hiding answers behind a custom accordion that inserts content on click removes it from the page as far as anything reading the markup is concerned — and usually removes it from the browser's own find-in-page as well. A native disclosure element avoids both problems for less code.

Taken together, none of this is an optimisation trick. It is a clear outline, one idea per section, addressable passages, and markup that tells the truth about the page — which is what a well-edited document has always looked like.