Missing H1, multiple H1s, or skipped heading levels

Headings H1 to H6 in the page content are extracted in document order and three things are judged. A page gets the finding when at least one holds, and at most one finding, even if all three do:

1. No H1 at all.
2. More than one H1.
3. A skipped level: a heading is followed by one more than one level deeper, say an H2 directly followed by an H4.

The third condition has two refinements worth knowing, because without them it would raise a great many false alarms:

• Only adjacent headings are compared, not a running maximum. Going back up a level is always fine: an H1 may follow an H3 and nothing happens. Only descending more than one step at a time counts.
• The first heading on a page is compared to nothing. A page starting straight at H3 is not a skip in itself; the missing H1 is reported by the first condition instead.
• Headings in navigation, the site header and the footer are left out of the sequence (since 19 September 2026). A footer link directory routinely places an H4 right after a content H2, and that is how the template is built, not a defect in your content. On one production site this alone caused 45 of 49 findings. An ARTICLE header (<header> inside <article>) is not site chrome and still counts.

What the check does not do:

• It does not judge what the headings say. An empty H1, or an H1 reading “Home”, passes. Heading wording is STR-02's business, and even that only roughly.
• For H1 it does not care where on the page the heading sits. A second H1 hidden in the footer or a sidebar weighs the same as a second H1 in the content, and it is a far more common cause. (Leaving out site chrome applies to the level sequence only; an H1 is never treated as chrome, because templates routinely put the page name in the header.)
• It cannot see text that looks like a heading but is not one. A paragraph set in large bold type is ordinary text as far as the check is concerned.
• It does not look at aria-level, nor at headings injected by JavaScript after load.

The finding is page-level; severity is warning.

We have no evidence that a correct heading hierarchy improves your chances of being cited in an AI answer. Hence the “effect not demonstrated” class. No operator of a language model declares how it treats headings, and no measurement we would trust compares the two cases.

What is documented has to be stated in full, though, including the fact that Google is more relaxed about this than our finding is. Its own starter guide says, literally:

Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order.Google Search Central, SEO Starter Guide

On the ideal number of headings it is equally sober: there is no magical amount, and if you think it is too many, it probably is. So on skipped levels and on multiple H1s our finding is stricter than Google, which is worth knowing before you rebuild a template because of it.

Where the strictness does pay off is accessibility. Let us be precise here too: no WCAG success criterion forbids skipping a heading rank. The support comes from a W3C WAI tutorial (an informative document), and even that is careful: skipping ranks "can be confusing and should be avoided where possible", with an explicit exception for closing a subsection (an <h2> opening a new section may follow an <h4>). What is documented is the part that matters: browsers, plug-ins and assistive technologies use headings for in-page navigation, and screen reader users move through a page by exactly these. It is just about people rather than AI, and it is guidance, not a standard.

Why keep the check at all? Because a heading hierarchy is the cheapest way to split a page into parts that stand on their own, and that property underpins the whole idea that a single passage can be lifted out of a long page as an answer. That language models do that by following headings is not something we can claim. That a well-structured page does no harm and costs nothing, we can.

So weigh the finding by what stands behind each part: fix a missing H1, because a page without a main heading is a badly written page. Fix skipped levels for the sake of people reading with a screen reader; there the evidence is hard. Fix the second H1 in the footer when you have time. And do not expect to appear anywhere as a result: promising that would be claiming something we cannot demonstrate.

Work out which of the three cases you have; each is fixed differently.

A missing H1 usually happens in templates where the main heading is set as <div class="title"> or <p class="heading">. It looks identical; semantically it is not a heading. Change the element, not the styling; font size is CSS's job, not the heading level's.

Multiple H1s nearly always come from an H1 in the header (the logo or site name) alongside one in the content. The site name belongs in an H1 only on the home page; on subpages the H1 is that subpage's own heading:

<!-- Wrong: site name as H1 on every subpage -->
<header><h1>Our Company</h1></header>
<main><h1>Pricing</h1></main>

<!-- Right: a link in the header, H1 belongs to the page content -->
<header><a href="/">Our Company</a></header>
<main><h1>Pricing</h1></main>

A skipped level happens when the heading element is chosen by font size. Somebody needed a smaller heading, reached for H4, and left a hole between H2 and H4. The rule is simple: the heading level expresses nesting in the content, not the size of the type. If you need a smaller H3, change the CSS.

To check without any tooling, open the console in your browser and print the page outline:

document.querySelectorAll('h1,h2,h3,h4,h5,h6')
  .forEach(h => console.log(h.tagName, h.textContent.trim().slice(0, 60)));

If that listing reads top to bottom like a table of contents, the page is fine. If it does not, you will see exactly where.

One closing note: fix the template, not the page. A finding on one page almost never means one page: the header, the footer and the product card are shared, so the same defect sits on hundreds of URLs at once.