Do you need exactly one H1: patterns, pitfalls and fixes

Do you need exactly one H1: patterns, pitfalls and fixes

Google's official guidance says multiple H1 tags won't tank your rankings. But that doesn't mean it's a good idea for your users or your content strategy. We've learned the hard way that the question "do I need exactly one H1" is less about SEO compliance and more about building semantic, navigable HTML that works for everyone.

One H1 keeps the outline clear

A document with a single H1 acts as a table of contents in waiting. When a screen reader user or a developer jumps into your page, they see a clear hierarchy: one main topic, then supporting sections. This is how HTML outlining was designed to work. The H1 is the page's thesis statement.

Think about a typical product page. The product name is the H1. Everything else—specifications, reviews, related items—are H2 or H3 sections that support that main idea. When you have multiple H1s, you're essentially saying "this page has three equally important topics," which confuses both algorithms and people.

We recently audited a SaaS marketing site where each team had added their own H1 to pages. The pricing page had:

<h1>Pricing Plans</h1>
<h1>Enterprise Solutions</h1>
<h1>Custom Packages</h1>

The page content was a mess. Visitors didn't know what the primary focus was. Search engines see this as unclear intent. Fixing it took one pass: keep "Pricing Plans" as H1, demote the others to H2. Bounce rate dropped 12% and time-on-page increased because users could navigate mentally.

A single H1 also makes your CSS and design system easier to maintain. You have one clear target for your main heading styles. You don't need defensive CSS rules to handle multiple H1s at different sizes.

Screen reader users rely on structure

For users with assistive technology, heading structure is navigation. They use shortcuts to jump between H1s, then explore H2s and H3s as subsections. If your page has four H1s and they all say different things, a screen reader user will think they're on four different pages, not one cohesive document.

We tested this with a real user on a retail site that had multiple H1s in the footer, header, and main content. Their first instinct was to press the "next H1" hotkey expecting to reach a new page. Instead, they landed in the footer. Confusing and frustrating.

The Web Content Accessibility Guidelines (WCAG) 2.1 criterion 1.3.1 requires semantic structure. Multiple H1s don't technically violate it, but they obscure the meaning of the page. Your goal should be clarity, not rule-checking.

A clean outline looks like this:

<h1>React Performance Optimization Guide</h1>

<h2>Why Performance Matters</h2>
<p>...</p>

<h2>Identifying Bottlenecks</h2>
<h3>Using Chrome DevTools</h3>
<p>...</p>

<h3>Measuring Core Web Vitals</h3>
<p>...</p>

<h2>Solutions and Trade-offs</h2>
<p>...</p>

Someone using a screen reader can press "h" to jump through H1, H2, H3 and understand the page structure instantly. They know "React Performance Optimization Guide" is the main topic, "Why Performance Matters" is a major section, and "Using Chrome DevTools" is a subsection. That's how it should work.

CMS content should start at H2

If you're building a CMS or a headless API that returns rich content, your template should always supply the H1 at the page level. The content editor's first heading should be an H2.

We built a Nest.js backend for a blog platform where editors could write posts. Early versions let them add H1s in the editor. Result: post titles were H1s, but so were random subheadings editors created. When these posts were embedded in collection pages (which also had their own H1), we had structural chaos.

The fix was straightforward. The template provided the H1 (the page title or article headline), and the rich text editor's toolbar started at H2. Editors saw an H2 button, not an H1 button. This enforced structure without requiring them to think about it.

<!-- Template provides H1 -->
<h1><%= article.title %></h1>

<!-- Rich text content starts at H2 -->
<div class="content">
  <%= sanitizeAndRenderRichText(article.body) %>
</div>

In your Markdown or block editor, disable H1 entirely. In your rich text editor configuration, set the minimum heading level to 2. This is a design decision that prevents mistakes upstream.

For a Next.js site with MDX content, you'd handle this in your component props or serialization layer. Only the page layout renders H1. The MDX content's first element is an H2.

Consistency beats rules debates

The strongest argument for one H1 per page isn't an algorithm or a spec—it's consistency. When every page on your site follows the same heading pattern, you build a predictable experience. Your design system knows what to style. Your editors know what to create. Your visitors and their tools know what to expect.

We've seen teams get stuck arguing whether their specific use case justifies multiple H1s. A homepage with hero, features section, and testimonials. A dashboard with multiple card widgets. An e-commerce category page with primary and secondary filters.

In every case, the answer is the same: pick one H1 that represents the page's primary purpose. Everything else is an H2. Consistency removes the decision fatigue and the resulting bugs.

Document your convention in your style guide. Example:

Heading Structure Rule: Every page has exactly one H1, matching the primary page title or headline. Content sections use H2. Subsections use H3. Editors cannot create H1 tags in body content.

When you enforce this at the template and editor level, you don't rely on developers to remember or enforce it manually.

Common mistakes

• Multiple H1s "for design": Using H1 class on several elements because they need the same visual style. Use a class instead; heading tags should reflect structure, not appearance.
• Skipping heading levels: Going H1 to H3, skipping H2. This breaks the outline. Always step through levels in order.
• No H1 on CMS templates: Letting editors add their own H1s in body content while the template has none. Ensure the template controls H1; body content starts at H2.
• H1 in the footer: Repeating the site logo or tagline as an H1 in every footer. Use an image or <strong> text instead.
• Dynamic H1 without testing: If your H1 comes from user input or data, always verify it renders and makes sense. A product with no name shouldn't output an empty or broken H1.

Key takeaways

• One H1 per page creates a clear outline for all users and assistive technology.
• Enforce this in your template or CMS, not in documentation or hopes.
• Screen reader users navigate by heading level; multiple H1s confuse that navigation.
• Your design system should style H1 once, consistently, across the entire site.
• Consistency in heading structure is more valuable than debating edge cases; pick a rule and stick to it.