Multiple h1 tags: 170 of 1,059 home pages declared more than one, and 259 declared none

Are multiple h1 tags a problem for AI search?

Two documents own this question and they do not agree, so the honest starting point is to read both rather than to pick the one that suits.

The MDN reference for the heading elements, last modified 26 August 2026, is the stricter of the two, and it carries a subsection headed Avoid using multiple h1 elements on one page. It states that while using multiple h1 elements on one page is allowed by the HTML standard as long as they are not nested, this is not considered a best practice, and that a page should generally have a single h1 element that describes the content of the page, similar to the document's title element. A note under it adds that nesting multiple h1 elements in nested sectioning elements was allowed in older versions of the HTML standard, was never considered a best practice, and is now non-conforming. Its summary line leaves little room: prefer using only one h1 per page and nest headings without skipping levels.

Google's SEO starter guide, last updated 2025-12-10 UTC, puts the same subject in a different place. The heading Number and order of headings sits inside a section the guide titles Things we believe you shouldn't focus on, next to PageRank and the duplicate content penalty. Under it Google writes that 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, and that the web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification. It then says there's also no magical, ideal amount of headings a given page should have, and closes with a qualifier worth keeping: however, if you think it's too much, then it probably is.

Neither document is about AI answer engines and this post does not pretend otherwise. One is a browser vendor's markup reference, the other is a search engine describing its own index, and no figure below is evidence about either. What can be settled without an opinion is narrower and more useful: how many h1 elements real home pages carry, and what a text extractor of the kind an AI crawler runs does with the ones it finds. The first is a count of the web and the second is a property of this repository's own code. Heading coverage on article pages has been measured here before. The number of top level headings had not been.

What 1,059 home pages actually declared

The distribution is the whole finding, and it is less tidy than either document implies. 630 of the 1,059 readable home pages carried exactly one h1 element, which is 59.5 percent, a majority but not a convention. 259 carried none at all. 170 carried more than one, and those 170 pages held 865 of the 1,495 h1 elements counted across the entire corpus, so a sixth of the pages accounted for well over half the top level headings.

The tail is long and it matters more than the mean. 78 pages carried two h1 elements, 58 carried between three and five, 18 carried between six and ten, and 16 carried more than ten. The largest was thejakartapost.com, a news home page carrying 85 h1 elements, where nearly every story headline on the front page is marked up as a top level heading. khiry.com, built on Webflow, carried 47. One page carried 36 and another 28, both built on Framer. At that scale the question stops being a style preference: a document with 85 top level headings has no top level heading, because the element that was supposed to say what the page is about has been spent 85 times.

Which stack a site is built on predicts this better than which industry it is in. Among the 31 readable Framer sites, 13 carried more than one h1, a rate of 41.9 percent, the highest of the eighteen strata; the Framer stack guide covers the rest of what that platform does to a crawler's view. 20 of 54 Wix and Squarespace sites carried more than one, and 13 of 36 WordPress small business sites did. At the other end, only 1 of the 31 static documentation sites carried more than one, and only 3 of 74 travel sites did. Page builders that let a designer drop a styled heading block anywhere produce multiple top level headings as a by-product; hand written templates and documentation generators do not.

Word count does not separate these groups. The 630 single h1 pages served a median of 632 words of main content to a crawler, the 170 multiple h1 pages a median of 636. Whatever the extra headings are doing, they are not marking out more prose. The frame behind the strata, and what it can and cannot represent, is set out in the crawlability study, and the same corpus has been read for which schema.org types reach home pages.

On 47 of the 170, the extra h1 repeats a sentence already there

The interesting part of the multiple h1 population is not that there are several headings. It is that so many of them say the same thing twice. On 47 of the 170 pages at least one h1 carried text that another h1 on the same page already carried, after lowercasing, stripping punctuation and collapsing whitespace. On 28 of those pages every single h1 held an identical sentence.

The shapes behind that number are worth naming because they have different causes. daytona.io carried three h1 elements, all reading Run AI Code on Daytona. heatbureau.com carried two, both reading a FULL-service DESIGN studio. marmitedefontes.com carried three copies of one line. This is the signature of responsive duplication: a builder emits one heading for the desktop layout and another for the mobile layout, CSS hides whichever does not apply, and a client that reads bytes rather than pixels receives both. The same mechanism has shown up here measuring pages that answer a phone and a desktop differently and in the words that sit behind a visibility marker, where 121,312 of 1,269,054 words were hidden from a reader but not from a parser.

The extreme case of partial repetition was iheald.com, with 36 h1 elements carrying just 3 distinct sentences between them, each one a health outcome claim repeated many times over. isapinheiro.com carried 28 h1 elements holding 17 distinct texts. thejakartapost.com, the largest page in the run, carried 85 h1 elements with 65 distinct texts, so even there 20 of the 85 repeated another headline on the same front page.

This is the part that bears on retrieval rather than on style. An extractor building a document from bytes does not know that two identical strings were meant to be one heading shown at two screen widths. It records a document whose top level heading appears three times, which inflates nothing useful and can distort any weighting that treats a heading as a statement about the page. Prose parity is the measure this product uses for the gap between what a browser renders and what a crawler receives, and duplicated headings sit squarely inside it. What this run did not do is test whether any named engine penalises the repetition, and no figure here should be read as evidence that one does.

The 259 pages with no h1 are two different problems

A count of pages missing an element is only useful if you check what those pages were, and in this run the 259 split cleanly into two groups that deserve different responses.

110 of them served a crawler fewer than 100 words of main content, and 69 served none at all. Those are not markup decisions. A page that delivers zero words and zero headings under an HTTP 200 is a bot challenge, a script shell, a redirect stub or a consent interstitial, and its missing h1 is a symptom of the page never arriving rather than of anybody's choice about heading levels. The same population has turned up every time this corpus is read: 418 of 1,419 sites gave a crawler no words to read in an earlier run, and a 403 or a 200 tells you very little on its own. Counting these 110 as sites with a heading problem would put the number at 259 rather than 149, an overstatement of three quarters.

The remaining 149 are the real ones. They answered with 100 words or more, a median of 607, which is within a few percent of the 632 median on single h1 pages. These are ordinary home pages carrying ordinary amounts of prose and no top level heading anywhere in the document. 34 of 61 readable ecommerce sites and 31 of 74 travel sites sat in the no h1 group, two of the three highest rates in the corpus with news on 28 of 60 between them, which fits a layout where the first thing on the page is a hero image with the brand name set as styled text rather than as a heading.

Two caveats bound this, and both cut against reading the number as larger than it is. The count is of h1 elements in the HTML delivered to a client that runs no JavaScript, so a heading injected by a framework after hydration is absent here by construction; JavaScript supplied 7.6 percent of the prose on this corpus when it was measured with a browser, and two of nine crawler operators say either way on whether they run it. And a missing h1 is not a missing heading: several of the 149 carried h2 and h3 elements in quantity, so the document had structure, just no declared top.

Where the h1 sits decides whether an extractor counts it

Counting h1 elements in the HTML is one question. What a text extractor records is a different one, and the gap between them is large enough to change the answer on more than a tenth of the corpus.

The extractor in core/src/extract.ts classifies every text block as main content, neutral or boilerplate, and anything inside a nav, header, footer or aside element is boilerplate. Headings in boilerplate are dropped before the heading list is built, so they never reach the h1 count. Across these 1,059 pages, 224 h1 elements sat inside one of those four elements, spread over 149 pages, and on 120 of those pages every h1 in the document was inside boilerplate. The result is that the extractor recorded zero h1 elements on 136 pages whose HTML plainly contained at least one.

lu.se is the clearest case in the run. Its home page carries 18 h1 elements, most of them faculty names, with texts including Ekonomihögskolan, Juridiska fakulteten and Medicinska fakulteten. Not one of them is the page's subject heading: 13 sit inside a nav inside the footer, four more sit directly in the footer, and the eighteenth sits in the header and carries no text at all. The raw HTML therefore has eighteen top level headings and this scanner reports none. That behaviour was first written up here from five golden fixtures, where an h1 inside a header element counted as no h1 at all; this run is the same rule seen at corpus scale, and it is a defensible rule rather than a bug, because a heading that labels a navigation block is not a statement about the page. It is still a rule a site owner cannot see from their own markup.

The divergence runs the other way too, and that part is less defensible. On 80 pages the extractor recorded more h1 elements than the document contains, because its count increments per text block rather than per element: an h1 containing a nested block level element flushes more than one block, and each is attributed to the h1 that anchored it. marmitedefontes.com has three h1 elements and the extractor reports six. That is a counting artefact in our own code, it is logged here rather than tidied away, and it does not move any figure in this post, all of which are counted from the elements. The related reading is what deleting the main element costs, the 379 of 1,066 pages that declared no main at all and the links named only by an aria-label, all of which turn on the same question of which bytes an extractor treats as content.

One more measure belongs here because it is easy to overclaim. 411 of the 1,059 pages put at least one h1 inside a section, article, aside or nav element, and 86 put two or more there. MDN's non-conforming case is specifically multiple h1 elements in nested sectioning elements, which is narrower than what was measured: this run recorded whether an h1 had a sectioning ancestor, not whether those ancestors were nested within one another. So 86 is an upper bound on the pattern MDN names, not a count of it, and it is reported that way on purpose.

What our own check does, and why that is awkward

The uncomfortable part of this measurement is what it says about our own scoring, so it belongs in the post rather than in a footnote.

One of the seven checks behind this scanner's structure sub-score is exactlyOneH1, and it passes only when the extractor's h1 count is exactly one. In STRUCTURE_CHECK_WEIGHTS in core/src/config.ts it carries a weight of 1 against a total of 6.5, and SCORE_WEIGHTS gives structure 0.15 of the composite, so exactly one h1 is worth about 2.3 percent of a page's grade. Those are settings somebody chose, not findings, and that distinction is the whole point of stating them: no measurement in this repository established that one h1 is worth 2.3 percent of anything.

Run that check across this corpus and it passes 481 of the 1,059 pages, which is 45.4 percent. 464 of those are pages whose HTML carried exactly one h1 and whose single h1 sat outside boilerplate. So the check fails the majority of the readable web, on a signal that one of the two publishers who documents it files under things not to focus on. That is not a comfortable position and it is not resolved by this post. It is worth stating plainly: we weight a page down over a markup pattern that Google files among the things not to focus on and that MDN calls a best practice rather than a requirement, and the honest status of that weight is unverified rather than wrong.

What would settle it is not another count of markup. It would be a measurement connecting h1 count to whether a page is retrieved and cited by a named engine, holding content constant, which is a different and much harder experiment than reading 1,419 home pages once. Until somebody runs it, the defensible move is to keep the check, keep its weight small, and say what it rests on. The grade itself, and how much each dimension actually moves it, is set out on the methodology page and was measured across this same frame when 972 of 1,419 corpus sites were graded and parity took 60.7 percent of every point they lost. Anyone who wants the h1 count on their own page rather than ours can read it from what GPTBot sees, and the vocabulary behind the score sits in the AI visibility entry.

The stability check closes this out, because a one shot read of live sites earns one. The whole corpus was read a second time the same day. 1,397 of the 1,419 hostnames gave the same answer on both reads for whether a page was delivered and for which of the three buckets it fell into, and 1,406 returned an identical h1 element count. Of the 22 that moved, 21 moved on whether a page was delivered at all, which is bot defence rather than markup. Exactly one hostname was readable both times and changed bucket: karolinska.se carried one h1 on the first read and none on the second. The second read gave 1,066 readable pages, 267 with no h1, 630 with exactly one and 169 with more than one, against 1,059, 259, 630 and 170. The finding this post is named for did not move.