You wrote a genuinely good page. It answers the question, the research is solid, and AI still cites someone else. Before you rewrite a word, check the markup underneath it, because the semantic HTML AI search engines read may be hiding your best section from them. This guide walks you through nine checks on your heading order and your HTML tags, so parsers can find your page's topic, split it into clean sections, and attach an answer to the right one.
None of this requires a redesign. Writing clean HTML for AI crawlers is mostly a tag swap, not a rebuild.
Why your heading tree decides what AI can cite
Here's the part that surprises people: AI systems don't read your page the way you do. They parse the DOM, build a tree out of your headings and sectioning elements, and lean on that tree to work out five things.
What is this page about, from the top of the tree. What are the sub-topics at each level. Where does one section stop and the next begin. Which section answers the question someone just asked. And what to attach the citation to when it surfaces your claim.
Every one of those steps runs on your heading tree. When the tree is well formed, they all work better. When it's broken, with skipped levels, headings that are really styled divs, or no <main> at all, the parser has to guess where your sections start and stop. It guesses wrong often enough that you lose citations you'd otherwise have earned.
That's the whole mechanism. Document structure AI parsing depends on isn't magic, it's your tags.
Here's the piece worth understanding, because it explains all nine steps below. Retrieval systems don't swallow your page whole. They chunk it.
That happens in roughly three ways. Fixed-size token windows slice the page every few hundred tokens, cutting mid-sentence and ignoring your structure completely. Semantic chunking splits on natural boundaries like paragraphs and headings. Structure-aware chunking splits on heading boundaries and pairs every chunk with its heading, which is what makes citation mapping reliable.
You don't get to choose which one an engine uses. But a clean H1 to H2 to H3 tree lets a chunker produce one well-labeled unit per topic. A flat or missing tree pushes it toward arbitrary cuts.
When a heading travels with the chunk, the engine gets three things at once. A readable label for the passage. A way to attribute the answer back to you. And a relevance signal that doesn't lean on raw text similarity alone. Pages without real headings lose all three, and their citations turn generic or vanish. That's how semantic HTML AI search visibility gets decided, one chunk at a time.
Is your content the problem, or is your markup? Work the nine steps and you'll know.
Step 1: Confirm you have exactly one H1
Open your page source, or use a headings outline tool, and count your H1 tags. You want exactly one.
That single H1 is your page-level topic. It belongs at the top of <main>, or inside the page's primary <article>. It should say what the page is about, not what the site is called.
How you know it's done: one <h1>, inside <main>, describing the page's actual subject. Not the site name. Not a hero subtitle. Not boilerplate.
Where people go wrong: they assume the biggest text on the screen is the H1. Often it's a logo or a hero line styled at 48px, while the real H1 is somewhere else entirely, or missing. Size tells you nothing. Only the tag does.
You'll also see the opposite problem, three or four H1s scattered down the body with no wrapper around them:
<h1>Welcome to Acme</h1>
<h1>Our Products</h1>
<h1>Contact Us</h1>
Now nothing tells a parser which H1 is the page. Keep one for the topic and demote the rest to H2.
Step 2: Map your heading outline top to bottom
Generate the full H1 to H2 to H3 tree and read it like a table of contents. That's it. If the outline reads as a sensible summary of the page, parsers will read it that way too.
How you know it's done: no skipped ranks anywhere, and every heading describes the content underneath it in plain language.
Where people go wrong: a reused widget quietly breaks the tree. A "Related Articles" or "Recent Posts" block drops an H4 in right under your H2, and suddenly your outline has a hole in it that nobody wrote on purpose.
A clean outline looks like this:
h1: How to Bake Sourdough
h2: Tools You Need
h3: Optional Tools
h2: Mixing the Dough
h3: Hydration Targets
h3: Autolyse Step
h2: Shaping and Baking
Read yours out loud. If it sounds like a coherent contents page, you're in good shape.
Good news while you're here: this is the same outline your heading hierarchy SEO checklist has always asked for. You're not learning a new discipline. You're getting paid twice for one piece of work.
Step 3: Close every skipped heading level
Skipped levels are the single most common heading mistake, so expect to find at least one. That's normal. Fixing them is usually a one-character edit.
A skipped level looks like this:
<h1>How to Plan a Sprint Retrospective</h1>
<h2>Before You Start</h2>
<h4>Optional Prep</h4>
There's no H3, so the outline has a gap. Promote the H4 to H3 and the tree closes.
The rule is simple, and every H1 H2 H3 order AEO checklist starts with it. Going down, never skip a rank: H1 to H2 to H3 to H4. Going back up by one level when a child section ends is completely fine.
How you know it's done: you can walk the outline top to bottom without ever jumping two ranks in one move.
Where people go wrong: they pick a tag because its default size matched the design. That's the root cause behind most skipped levels, and it's worth naming directly.
Common mistake: using heading rank as a font-size control. If your H1 renders at 14px and an H3 renders at 32px, you're telling humans one thing and parsers the exact opposite. That contradiction reads as low-trust structural data. Style with CSS. Reserve rank for depth. This is the heading hierarchy SEO habit that pays off fastest.
Parsers may still pick up the text under a skipped level, but they can't infer the topic that should have sat in the gap. Every skipped level is signal you're throwing away.
Step 4: Replace div soup with semantic landmarks
Now look at your wrappers instead of your headings. If every block on the page is a <div> with a meaningful-sounding class name, you have div soup:
<div class="header">
<div class="title" style="font-size:32px;">Sprint Retrospective Guide</div>
</div>
<div class="body">
<div class="big-text" style="font-size:28px;">Before You Start</div>
<p>...</p>
</div>
You can read that. A parser can't. There's no H1, no <main>, no <article>, and the "headings" are styled divs that look exactly like body text. Class names like header and title mean something to you and nothing to a machine.
Swap in the real elements. <header> for intro content, <nav> for navigation, <main> for the central content, <article> for standalone pieces, <section> for thematic groups, <aside> for tangential material, <footer> for closing content. Keep <div> for genuine styling hooks with no meaning.
Most well-structured pages land on the same shape:
header site-wide header or hero intro
nav primary navigation
main the central content
article the main content block, heading at the top
section ...
section ...
aside related links or sidebar
footer site-wide footer
One <main>, one or more <article> or <section> inside it, an optional <aside>. That pattern answers two questions a parser is always asking: what is the main content here, and what is supplementary? Two more small things while you're in the markup. If you have several nav regions, primary, footer, breadcrumbs, give each an aria-label so they're distinguishable. And make sure a "skip to main content" link is the first focusable element on the page.
How you know it's done: every page has exactly one <main>, and each major block uses a landmark element wherever one applies.
Where people go wrong: they assume semantic elements will change the layout, so they never try. They won't. Landmarks are a one-line change with no styling cost, which makes this the cheapest win on the list.
Landmarks also let parsers jump straight to your main content instead of guessing where it begins. That's what makes clean HTML for AI crawlers worth the twenty minutes it takes.
Step 5: Wrap each major topic in a section with its heading
Landmarks handle the page. Sections handle the topics inside it.
For every top-level topic, put the heading at the top of a <section> that contains that topic's content and nothing else. The heading goes first, as the section's first child.
<section aria-labelledby="run-the-meeting">
<h2 id="run-the-meeting">Run the Meeting</h2>
<section aria-labelledby="agenda">
<h3 id="agenda">Agenda</h3>
...
</section>
</section>
The aria-labelledby pairing ties the heading to its section, which helps assistive tech and any parser that walks landmark and heading pairs together.
How you know it's done: every H2 sits inside a containing <section>, and every <section> opens with a heading.
Where people go wrong: the heading gets placed after an introductory paragraph instead of before it. Now the parser has to decide whether that paragraph belongs to this section or the last one, and its guess may not match yours.
One caution while you're in here. Don't reach for <section> expecting it to reset your heading levels. That was the HTML5 outline algorithm, and no browser ever implemented it. Ranks still carry the structure, so H1 to H6 is what you rely on.
Step 6: Choose between article and section deliberately
This is the confusion that trips up most teams, and the test is one question: would this content still make sense if you pulled it out of the page and put it somewhere else on its own?
Yes, it stands alone? That's an <article>. A blog post, a product card, a comment, a news story.
No, it only makes sense inside the parent? That's a <section>. Chapters of a guide, "Ingredients" and "Method" inside a recipe, an FAQ block.
Neither, it's just a styling hook? That's a <div>, and that's a perfectly good answer.
How you know it's done: every <article> on the page is genuinely independent, and every <section> groups related content under a heading.
Where people go wrong: <article> becomes the default wrapper for everything. If you've marked six things on one page as articles, most of them are sections.
Both should generally open with a heading. If it has a heading and a distinct topic, it's probably a section. If you could syndicate it, it's probably an article.
Step 7: Mark up figures, dates, and contact details
The small tags matter more than their size suggests, because they turn visible text into machine-readable data.
Wrap captioned media in <figure> with a <figcaption>, so the caption is bound to the image or chart instead of floating near it. Wrap dates in <time datetime="2026-07-15"> so the date is unambiguous. Wrap contact information in <address>.
How you know it's done: every captioned image, chart, or explained code block sits in a <figure> with its <figcaption>, and every visible date on the page is machine-readable.
Where people go wrong: dates. Almost every site writes "January 2026" as plain text and stops there. A human reads it fine. A parser sees a string, not a date.
Pro tip: if a landmark has no visual heading, it still needs a real one. Add the heading and hide it with the standard
sr-onlyorclippattern. Your structure stays consistent, your design doesn't change, and the section keeps its label.
Step 8: Validate the markup and check the outline
You don't have to eyeball any of this. Free tools will do the whole audit in a couple of minutes.
HeadingsMap, a browser extension, generates a document outline for any page and flags skipped levels and multiple H1s on the spot. The HTML Headings Checker at SEO Review Tools does the same from a pasted URL. The W3C Nu HTML Checker validates the markup itself and catches malformed HTML, unclosed landmarks, and duplicate IDs. For the accessibility side, axe DevTools, Lighthouse in Chrome DevTools, and WAVE all flag heading order and missing landmarks.
Run one outline tool and one accessibility scanner. That combination catches nearly everything in steps 1 through 7.
How you know it's done: zero structural errors in the validator, and no landmark or heading-order issues from axe or Lighthouse. Warnings are either resolved or you can explain why you left them.
Where people go wrong: treating "warning" as optional. Warnings are where heading-order problems usually live, and shipping past them is how broken structure survives a redesign.
If you're running this across a whole site rather than one page, that's where it stops being a manual job. Structure is worth building into production rather than auditing back in later, which is the thinking behind how DeepSmith writes: heading structure and internal linking are part of the pipeline that produces the article, not a cleanup pass after it.
Step 9: Spot-check each section for citation-friendliness
Last pass, and it's a judgement call rather than a tool.
Walk your H2s one at a time and ask a single question of each: if an AI answered someone's question using this section, could it cite a heading and a paragraph that actually match?
That's what all eight previous steps were building toward. Engines that produce answer cards and snippets tend to pull a heading plus the paragraph directly beneath it. So the pairing has to hold.
How you know it's done: every section has a descriptive heading, and a clear first sentence underneath that a chunker can attribute to that heading without stretching.
Where people go wrong: a sharp heading sitting above a vague warm-up paragraph. The heading promises one thing, the first sentence delivers throat-clearing, and the chunker attaches the wrong content to your best label.
Watch for headings that don't describe anything, too. "Overview," "Details," "More Information," and "Section 1" tell a parser nothing. Rewrite them to name the actual topic. Keep them short, front-load the noun phrase, and stay under roughly 80 characters. And don't stuff them: "SEO AI HTML Semantic 2026 Best Practices" is worse for parsers than "Best practices for semantic HTML," not better.
What to do next
Don't audit your whole site this week. You'd burn out by Wednesday.
Take your five most important pages, the ones you'd most want cited, and run steps 1 through 3 on each. One H1, a clean outline, no skipped levels. That's an afternoon, and it's the highest-leverage part of the entire list. Get the H1 H2 H3 order AEO checklists keep asking for, and you've done most of the work.
Then come back for landmarks. Then sections. Momentum matters more than completeness here.
You've already done the hard part, which was writing content worth citing. This is the plumbing that lets engines find it. If you'd rather have that structure built in from the first draft instead of retrofitted page by page, you can start a free DeepSmith trial and see what publish-ready output looks like when heading structure is part of the pipeline.
