On-page mechanics
One H1 per page: what actually breaks when you use two
Two H1s will not get a page penalised — but they do cost you clarity for assistive technology and extraction systems. Here is the honest version of the rule.
7 min read
The advice "use only one H1 per page" is repeated so often, and justified so rarely, that plenty of developers now treat it as folklore. They are half right: Google has said publicly that multiple H1s are not a problem for Search, and pages with two H1s rank every day.
That does not make the rule useless. It makes it a clarity rule rather than a ranking rule — and clarity is exactly what matters now that snippets, AI Overviews and assistants extract passages instead of reading whole pages.
This article separates what genuinely breaks with two H1s from what does not, explains the HTML5 outline algorithm myth that caused most of the confusion, and gives the specific patterns that cause duplicate H1s in real templates.
The short answer
Use exactly one H1 per page. It should name the specific subject of that page, and it is normally the first heading a reader meets. Not because a second H1 triggers a penalty — it does not — but because the H1 is the only element whose job is to say, unambiguously, what this document is about. Two answers to that question is one too many.
| Concern | Real impact of two H1s |
|---|---|
| Ranking penalty | None. Google has repeatedly stated multiple H1s are fine for Search |
| Understanding the page | Degraded. Two competing top-level topics on one document |
| Screen-reader navigation | Degraded. Users navigate by heading level and expect one document title |
| Passage extraction and quoting | Degraded. Section boundaries become ambiguous |
| Automated on-page checks | Fails almost every audit tool, including our own |
| Content reuse (RSS, CMS, exports) | Unpredictable — many pipelines take the first H1 as the title |
The HTML5 outline myth
For about a decade, one specific justification circulated for multiple H1s: HTML5 defined a document outline algorithm in which each sectioning element — <section>, <article>, <nav>, <aside> — created a new outline scope, so an H1 inside a <section> would automatically be treated as a second-level heading.
That algorithm was never implemented. No browser and no assistive technology ever shipped it, and the HTML specification has since removed it and now explicitly advises using h1 through h6 to convey document structure, with headings ranked according to their real nesting depth.
So a page with five <section> elements each containing an H1 does not have one H1 and four H2s in the eyes of any real consumer. It has five H1s, and a screen reader will announce five level-one headings.
What a second H1 actually costs
Screen-reader navigation
Screen-reader users routinely navigate by pulling up a list of headings and jumping between levels — it is one of the primary ways of skimming a page without sight. The W3C's guidance is that heading levels should reflect the structure of the page, with a single top-level heading describing the page as a whole and nested levels beneath it.
Two H1s mean the heading list shows two apparent document titles. Nothing is inaccessible, but the mental model the user builds from the outline no longer matches the page.
Extraction and quoting
Featured snippets, AI Overviews and assistant citations all work by lifting a passage and needing to know what it is a passage of. Heading structure is the cheapest available signal for that. When the top level of the document is ambiguous, the system has to guess which heading contextualises the passage, and guesses are worse than facts.
This is the reason the rule is more relevant now than it was when it was purely an SEO superstition: the consumers of your heading tree have multiplied.
Automated checks and content pipelines
Practically every SEO auditor, accessibility linter and CMS import routine treats "more than one H1" as a finding. That has a real cost even when the underlying issue is minor: it generates noise that hides the findings that matter. The wordiqo optimizer is no exception — its structure check looks for exactly one H1 plus at least two H2s, and its rewrite enforces a single H1, creating one from the primary keyword if the pasted text has none.
H1 vs title tag: the same words are usually wrong
The title tag is written for a results page where the reader has not arrived yet and sees a handful of competing lines. The H1 is written for a reader who is already on the page. They serve different moments, so they can — and often should — differ.
- Keep them close in meaning: a title promising a checklist and an H1 announcing a philosophy essay is a mismatch that shows up as pogo-sticking, not as an SEO error.
- Do not duplicate the brand suffix in the H1 — it wastes the most prominent line on the page.
- If the title needs a qualifier only to survive the SERP (a year, "guide", "free"), that is a title decision, not an H1 decision.
| Title tag | H1 | |
|---|---|---|
| Audience | Someone scanning a results page | Someone who already clicked |
| Length constraint | Roughly 50-60 characters before truncation | No hard limit; readability governs |
| Brand | Often appended, since context is missing | Rarely needed — the reader can see whose site this is |
| Disambiguation | May need year, format or qualifier to stand out | Only if genuinely part of the subject |
| Wording | Front-load the primary term | Natural phrasing wins over keyword placement |
Where duplicate H1s come from
Duplicate H1s are almost never a writing mistake. They are template mistakes, which is good news: fixing one template fixes hundreds of pages.
| Pattern | What happens | Fix |
|---|---|---|
| Hero + article title | The layout hero renders an H1 for the marketing headline, and the article component renders another for the post title | Decide which one is the document title; demote the other to a <p> with heading styling or to an H2 |
| Logo wrapped in an H1 | An old convention put the site name in an H1 in the header, on every page | Use an <img> with alt text, or a <p>/<span> — the site name is not the page subject |
| Rich-text editor headings | Authors pick "Heading 1" from the editor dropdown because it is the biggest option | Restrict the editor to H2-H4 for body content |
| Component libraries | A card, banner or CTA component hardcodes an H1 and gets reused mid-page | Make the heading level a prop with a non-H1 default |
| Merged or imported content | A pasted article brings its own H1 into a page that already has one | Demote on insertion — the same rule applies when adding a section to an existing article |
How to check, in ten seconds
For a check that also covers keyword placement, heading counts and length, paste the page text into the free optimizer — it reports the missing-H1 and too-few-H2s cases directly, alongside the rest of the on-page checklist it can see from text.
- Run one line in the browser console — document.querySelectorAll("h1").length — anything other than 1 on a content page is a finding. Add [...document.querySelectorAll("h1")].map(h => h.textContent) to see which ones.
- Look at the rendered DOM, not the CMS editor — The editor does not show what the template wraps around your content, and the hero H1 is a template element.
- Check the whole tree while you are there — [...document.querySelectorAll("h1,h2,h3,h4")].map(h => h.tagName + " " + h.textContent) prints the outline. Skipped levels show up immediately.
- Fix it at the template level — If two pages in the same layout both fail, the layout is the bug. Fixing the page instead of the layout guarantees the finding returns.
Edge cases where the rule bends
| Situation | Guidance |
|---|---|
| Homepage | Still one H1, describing what the site does. The logo does not count and should not be an H1 |
| Landing page with a hero | The hero headline is the H1. Do not add a second one further down for the "real" title |
| Feed or listing page | The list itself is the subject: one H1 for the listing, and H2s for each item |
| Single-page app with client-side routing | One H1 per rendered view. Ensure the H1 updates on navigation, since assistive technology relies on it |
| Documentation page inside a shell | The page title is the H1; the sidebar section name is navigation, not a heading level |
| A genuinely two-topic page | That is two pages. The H1 problem is a symptom of the structural one |
Questions people ask
Is more than one H1 an SEO penalty?
- No. Google has said multiple H1s are fine for Search, and there is no penalty. The cost is in clarity for assistive technology, extraction systems and automated checks, not in a ranking demotion.
Does the H1 have to contain the target keyword?
- It should contain the subject, which usually means the primary term appears naturally. Forcing an exact-match phrase into an otherwise awkward H1 trades reader clarity for nothing measurable.
Can a page have no H1 at all?
- Technically yes, and it will still be indexed, but you are discarding the clearest statement of what the page is about. Most audit tools, including the wordiqo optimizer, flag a missing H1 as a structural failure.
Should the H1 match the title tag exactly?
- Not necessarily. They can match when the subject is short and unambiguous, but the title tag often needs a qualifier or brand suffix to work in a results page, and none of that belongs in the H1.
Do H1s inside <section> elements count separately?
- No. The HTML5 outline algorithm that would have rescoped them was never implemented and has been removed from the specification. Every H1 on the page is a level-one heading, whatever wraps it.
References
- Google Search Central — Google SEO 101: multiple H1 tags — Google confirming that multiple H1 elements are not a problem for Search.
- HTML Living Standard — Headings and outlines — The current specification text after the outline algorithm was removed.
- W3C WAI — Page structure: headings — Why heading levels must reflect real structure for assistive technology.
- MDN — The HTML section heading elements — Practical guidance on heading levels, nesting and avoiding skipped ranks.
Keep reading
- Demote it to an H2 and keep the tree intact — The H2/H3 rules that decide where the demoted heading belongs.
- The on-page SEO checklist that is actually checkable — The full pass/fail list this rule is item 1 of.
- How to run a content audit on a page you already published — Where duplicate-H1 findings usually surface across a whole site.
- The on-page checks a content generator should enforce — Single H1 and heading-tree rules applied automatically to generated and rewritten text.