September 21, 2026

Designing an Answer-First Page: Heading Hierarchy AI Can Extract

Here is the most common structural failure on a B2B website. A page titled "Our approach to CMS migration" opens with three paragraphs about how the digital landscape has changed, then a paragraph about the company's history, then finally, in paragraph five, the thing the visitor came for.

A reader who skims will leave before paragraph five. A screen reader user navigating by headings will find nothing useful to jump to. And a system assembling an answer from passages will lift whichever passage best matches the question, which will be someone else's.

Answer-first design fixes all three at once. It is not an AI technique. It is good technical writing, applied to web pages, with the side effect that machines can extract from it cleanly.

Short answer

Put the direct answer immediately after the heading that poses the question, in two or three sentences, before any context or qualification. Use headings that describe what the section contains rather than chase keywords. Make each section readable on its own. Keep one H1 and a logical H2 and H3 sequence, not because search engines require it but because humans and assistive technology do. Add evidence a language model could not generate.

Everything below is an elaboration of that paragraph, which is itself an example of the pattern.

What headings actually do, and what they do not

Worth clearing up first, because the SEO industry and the specifications disagree, and the specifications win.

For Google Search, heading order is not a ranking concern. Google's SEO Starter Guide states that semantic heading order is excellent for screen readers but that from Google Search's perspective it does not matter if headings are out of order. Gary Illyes confirmed in 2024 that the guidance is current. John Mueller has said since 2019 that multiple H1s on a page are a common pattern and not a problem. Google's May 2026 generative AI guidance says the same thing again: perfectly semantic HTML is not required, though it is generally a good idea because it helps screen readers parse and navigate the page.

For accessibility, heading structure is a requirement. WCAG 2.4.6 (Level AA) requires that headings and labels describe topic or purpose. WCAG 1.3.1 (Level A) requires that structure be programmatically determinable, which means a heading must be a real heading element and not styled text. Screen reader users routinely navigate a page by jumping between headings, so a page with no heading structure, or with headings that say "Introduction" and "More", is genuinely harder to use.

For extraction, structure is incidental but real. A generated answer is assembled from passages. A passage that depends on three paragraphs above it for meaning is harder to lift than one that stands alone. Headings are the most reliable signal a machine has for where a passage begins and ends.

So: build a clean hierarchy for the reader and for accessibility. Extractability comes free. Do not build one because a tool flagged a skipped H3.

The answer-first block

The unit of an answer-first page is not the page. It is the block: a heading, an answer, an explanation, and evidence.

1. A heading that poses the real question. In the words the reader would use, not in keyword form.

2. A direct answer, two to four sentences, immediately below. No preamble. No "it depends" as the opening. If it genuinely depends, say what it depends on in the same sentence: "Two languages, yes. Four, no, and the reason is per-locale pricing."

3. Supporting explanation. The reasoning, the nuance, the exceptions. This is where "it depends" belongs.

4. Evidence. A number, an example, a source, a case. This is the part that makes the block worth retrieving rather than paraphrasing from general knowledge.

Most B2B pages have parts one and three. They are missing two and four, which are the two that matter.

How long should the direct answer be?

Two to four sentences, or roughly forty to eighty words. Long enough to be complete on its own, short enough that a reader sees the whole thing without scrolling.

The constraint that matters is self-containment, not length. Test it by reading the answer with everything above it removed. If it still makes sense, it works. If it opens with "This is why we recommend the second option", it fails, because "the second option" refers to something the reader may never have seen.

Definition blocks

When a page introduces a term, define it once, early, in a self-contained sentence of the form "X is a Y that does Z."

Grounding is a retrieval technique, also called retrieval-augmented generation, in which a system fetches relevant documents from an index and generates its answer from the specific information in those documents rather than from model memory alone.

Three properties make that work. It names the category ("a retrieval technique"). It gives the distinguishing behaviour ("fetches relevant documents... generates from the specific information"). And it contains no pronouns pointing outside itself.

Compare with a definition that fails: "This is what makes the whole thing possible, and it is why the technique has become so important." That sentence cannot be lifted, cannot be understood alone, and tells a reader nothing.

Lists, tables and comparison blocks

Each of these earns its place under a specific condition, and each is overused.

A list is right when the items are genuinely parallel and the order either does not matter or is strictly sequential. It is wrong when it is used to break up prose that has an argument in it, because a list strips the connective tissue that carried the reasoning.

A table is right when you have two or more subjects assessed against the same criteria. That is the only case. If one column is mostly empty, or the "criteria" differ per subject, it is not tabular data and a table will actively mislead.

A comparison block is right when the reader's decision is binary or near-binary, and it should carry a verdict. A comparison that ends without saying which option fits whom has done half the work.

Keep tables simple, with a header row and consistent units. A table with merged cells and nested markup is harder for assistive technology to read and harder for anything else to parse. A wide table also needs a horizontal scroll container on mobile, or it breaks the page layout.

FAQs: where they belong and where they do not

An FAQ section is appropriate when there are genuine recurring questions that do not fit the article's main argument. Objections, edge cases, adjacent questions. Three to six of them, each answered in fifty to a hundred and fifty words.

It is not appropriate as a place to restate the article in question form, which is the most common abuse. If a question is already answered by an H2 above, it does not belong in the FAQ.

On the markup: Google deprecated FAQ rich results on 7 May 2026. FAQPage remains a valid Schema.org type and causes no harm, but it produces no Google search appearance for anyone now, and no platform documents it as an AI citation factor. Write the FAQ because readers use it. Treat the schema as optional.

Chunking: what it means and what it does not

"Chunking" is used in two different ways and only one of them is sound.

The sound version means writing in self-contained sections with clear boundaries, so a reader can enter at any heading and understand what they find. That is just good structure.

The unsound version means breaking content into deliberately small fragments because a model supposedly parses them better. Google addresses this directly: there is no requirement to break content into tiny pieces, its systems understand multiple topics on a page, and there is no ideal page length. Shorter or longer pages can both work depending on the audience and subject.

Write sections that stand alone. Do not shred the page.

Entity references and internal links

Name things fully on first mention in each major section, then use the short form. A reader arriving mid-page from a search result, or a system lifting a single section, has not read your first paragraph.

Internal links belong in the body text where the reference genuinely occurs, with anchor text that describes the destination. "Read more here" tells a reader nothing and tells a machine less. Two to five contextual internal links on a long page is a reasonable range. More than that and they stop being navigation and start being noise.

Semantic HTML and accessibility

Use the elements that mean what you want. <article> for the content, <section> for major divisions, <nav> for navigation, real heading elements for headings, <table> with <th> for tabular data, <dl> for definition lists where they fit.

Two rules that matter more than the element inventory:

Never style a lower heading to look bigger than a higher one. If an H4 needs to look like an H2, the problem is the CSS, not the markup. This is the single most common cause of broken hierarchy in production, and it comes from designers and editors picking heading levels by visual size.

Never skip a level for visual reasons. Going H2 to H4 to avoid a font size is the same mistake in reverse.

Google will cope with either. Screen reader users will not, and WCAG 1.3.1 requires that the structure be programmatically determinable rather than merely visual.

Information gain, stated honestly

The phrase comes from a Google patent: US 11,354,342 B2, "Contextual estimation of link information gain", filed in October 2018 and granted in June 2022. It describes scoring a document by the additional information it contains beyond documents the user has already viewed, and using that score when presenting results.

Two qualifications the industry usually drops. The patent describes a mechanism relative to what a specific user has already seen, which is closer to session-level deduplication than to a global novelty score. And Google has never confirmed that this mechanism operates in Search. A granted patent is evidence of an idea, not of a shipped system.

What survives the qualification is still worth acting on, because it aligns with guidance Google does publish. Its May 2026 generative AI guide states that unique, compelling, useful content will likely influence presence in generative AI search more than anything else in the guide, and explicitly contrasts commodity content with content carrying real expertise or experience.

The practical translation: for every page, ask what it contains that a language model could not produce from general knowledge. If the answer is nothing, the structure will not save it. Structure makes good content extractable. It does not make thin content worth extracting.

A complete recommended hierarchy

A worked example for a comparative B2B page. Every heading is descriptive, every H2 opens with a direct answer, and the outline reads coherently on its own.

H1 Headless or traditional CMS: which fits a mid-sized B2B company? [Direct answer, 3 sentences, before any heading] H2 Short answer [Verdict, 4 sentences] H2 What "headless" actually means H3 The technical definition [Definition block] H3 What changes for the editorial team H3 What changes for the development team H2 The five criteria that decide this [Criteria table: traditional vs headless] H3 Editorial autonomy H3 Front-end flexibility H3 Time to first page H3 Total cost over three years H4 Build cost H4 Running cost H4 The cost nobody budgets: editorial friction H3 Team capability required H2 Where traditional CMS still wins [Direct answer, then three named scenarios] H2 Where headless is the right call [Direct answer, then three named scenarios] H2 What migration actually involves H3 Content modelling H3 The migration itself H3 What breaks, and when H2 How to decide in one meeting [A decision rule with four questions] H2 Common questions [3 to 5 genuine questions not covered above] H2 Sources and further reading

Note what the outline does. The H1 is a question. The first H2 answers it. The middle H2s are the argument. The last two H2s are what the reader does next. Read the headings alone and you can follow the whole piece, which is the test.

Note also what it does not do. No H5 or H6. No heading that exists only to hold a keyword. No "Introduction". No "Conclusion", because a conclusion labelled "Conclusion" is a heading that describes its position rather than its content.

Three poor structures and their fixes

Poor: the buried answer.H1 "Our CMS migration service", then four paragraphs of context, with the actual scope of the service under an H3 near the bottom.Fix: move the scope to a two-sentence answer directly under the H1, and demote the context to a later section that the reader can skip.

Poor: headings as keyword slots.H2 "CMS migration services for businesses", H2 "Professional CMS migration services", H2 "Best CMS migration services 2026".Fix: one H2 per actual topic. "What a migration includes", "What it costs", "How long it takes", "What can go wrong".

Poor: visual hierarchy driving semantic hierarchy.H1, then H4 for major sections because H2 looked too large in the design, then H2 for a minor aside because it needed emphasis.Fix: correct the markup to H1, H2, H3, then fix the CSS so each level looks right. This is a thirty-minute job that most sites never do because nobody owns it.

What to avoid

Headings that describe their position rather than their content: "Introduction", "Overview", "Conclusion", "Final thoughts"
Keyword strings used as headings
More than one idea per heading
An H1 that differs materially from the page title in the <title> tag, which confuses readers arriving from search
Answers that begin with a qualification instead of an answer
Bullet lists used to break up an argument that needed its connective reasoning
Tables built for two subjects where the criteria differ between them
FAQ sections that restate the article in question form
Fragmenting the page on the theory that models prefer small pieces. Google says otherwise.

None of that is new, and none of it is specific to AI. That is rather the point. The pages that machines extract from most cleanly are the pages that were well written for people in the first place.