Heading Structure That AI Engines Can Parse

A heading is a structural marker — <h1> through <h6> in HTML, # through ###### in markdown — that tells a parser what a section of content is about, distinct from styling text to merely look bigger. Headings form a document outline, and that outline is what retrieval systems use to chunk a page into sections before deciding which section answers a given query.

Why this affects AI citations

When a retrieval-augmented engine fetches a page, it generally doesn't treat the page as one undifferentiated blob of text. It uses structural cues — headings chief among them — to break the document into sections, so that a query about one specific aspect of a topic can be matched against the specific section that addresses it, rather than requiring the whole page to be read and re-summarized every time. Headings are, in effect, the pre-built index the engine uses instead of reconstructing document structure from scratch.

A page with a clean, correctly nested heading outline gives a chunking system exactly the map it needs: one H1 stating the page's overall subject, H2s marking distinct subsections each worth their own chunk, and H3s marking sub-points within those. A page with no headings, or headings used purely for visual size rather than structure, forces the system to guess at section boundaries using weaker signals like paragraph breaks — which correlate with topic shifts far less reliably than an actual heading does.

One H1 that states the page's claim

The H1 should be a specific statement of what the page is about — closer to a headline than a generic label. "Guide" or "Overview" as an H1 wastes the single most structurally important heading on the page; "Heading Structure That AI Engines Can Parse" (this page's own H1) states the actual claim.

Exactly one H1 per page is the convention worth holding to strictly. Zero H1s means the page has no stated top-level claim for a parsing system to key off. More than one H1 removes the hierarchy entirely — if two headings both claim to be the top level, nothing marks which one is actually primary, and downstream sections lose a clear parent to nest under.

H2s as standalone section claims

Each H2 should be able to function the way this guide's citable-definitions companion piece describes for opening sentences: a standalone claim, understandable without needing the H1 or surrounding paragraphs to make sense of it. "How to check" is acceptable as a section label because it's a self-explanatory instruction, but a heading like "More on this" or "The next part" says nothing on its own and forces a reader (or a parsing system) back into the body text just to find out what the section covers.

Why do question-form headings work especially well?

Question-form H2s or H3s map directly onto how people actually prompt AI engines. A user doesn't type "heading structure background information" into ChatGPT — they ask something closer to "why do headings matter for AI search" or "how many H1 tags should a page have." A section headed by that literal question, verbatim or close to it, is the easiest possible retrieval match: the query and the heading are nearly the same string, and the paragraph immediately beneath the heading is a natural, pre-packaged answer.

This doesn't mean converting headings into questions artificially — a section called "How to check" doesn't need to become "How do I check?" to be effective, since it's already a clear instruction. Where a genuine question is being answered, phrasing the heading as that question can be a useful retrieval optimization. It is not part of whether the underlying H1-H3 hierarchy is structurally valid.

Don't skip heading levels

An H3 is a subsection of the H2 immediately above it in the document. Jumping from an H1 directly to an H3, with no H2 in between, leaves that H3 with no stated parent — a system building a structural outline of the page has to either guess where it belongs or treat it as a malformed, effectively orphaned section. The same problem applies to jumping from H2 to H4.

This is a common byproduct of styling-driven heading choices: a writer picks whichever heading level happens to render at the visual size they want, rather than the level that reflects the section's actual place in the document's logical structure. The fix is to always choose heading level based on nesting depth, then adjust font size separately through your site's styling if a particular level doesn't look the way you want — level and appearance are two different decisions that formatting-focused writing tools often conflate.

Headings-as-design vs. semantic headings

It's possible to make text large and bold without using a heading tag at all — bold paragraph text, larger font sizes applied directly, or a styled <div> that looks like a heading but isn't marked up as one. This satisfies a human skimming the page visually. It does nothing for a system parsing document structure, because that system is reading tag names (h1, h2, h3), not visual weight. Text that looks like a heading but isn't tagged as one is invisible to exactly the kind of structural chunking this guide is about.

The reverse mistake also happens: using a heading tag purely to get a certain visual size for a short line of emphasis text that isn't actually introducing a new section. Every heading tag you add should correspond to an actual section boundary in your content's logic, not just a place you wanted bigger text.

A quick audit walkthrough

Open your page and look at (or generate, if your editor supports it) the document outline — the list of headings in order, with their levels, stripped of body text. Ask three questions of that outline alone, without looking at the rest of the page:

Is there exactly one H1, and does it state a specific claim rather than a generic label? Does each H2 make sense as a standalone line, without needing surrounding paragraphs to explain what it means? And does the level sequence ever skip — an H3 appearing with no H2 above it, or an H2 appearing with no H1 at the top?

If you can answer all three cleanly from the outline alone, a parsing system looking at the same outline can build an accurate structural map of your page. If the outline is confusing on its own, it will be at least as confusing to whatever system is trying to chunk the page automatically.

How to check

Most browsers' developer tools let you inspect the DOM and search for heading tags directly, or you can view page source and search for <h1, <h2, and so on. Some accessibility browser extensions also generate a heading outline view directly, since screen readers rely on the same heading structure for navigation that retrieval systems rely on for chunking — the two use cases want exactly the same correct markup.

The CitationsAI Inspector extension checks a page's heading structure as part of its audit: whether there's exactly one H1, whether that H1 comes first in the outline, and whether heading levels are skipped. Question-form headings can help when they fit the content, but the extension does not treat their absence as a structural error.

How to fix it

Start by fixing structural violations, since they're unambiguous: consolidate multiple H1s into one, add an H1 if none exists, and correct any skipped heading levels so each H3 has an H2 parent and each H2 has the H1 above it. These are mechanical fixes with a clearly right answer.

Then do an editorial pass on your H2 and H3 text: rewrite any heading that isn't a standalone, comprehensible claim on its own. Where a section directly answers a question your reader is likely to ask, consider using that question as the heading rather than an abstract label—but keep declarative headings when they are clearer.