Heading structure for SEO and accessibility: a deep dive

I've seen plenty of production sites where developers style a large font and call it a heading, then wonder why their page structure confuses both screen readers and search engines. Heading structure for SEO and accessibility isn't about what something looks like—it's about what something means. Your headings form the outline of your page, and that outline matters to both humans using assistive technology and algorithms trying to understand your content.

Why heading structure matters for both SEO and accessibility

When I build a new feature or page, I think of headings as a table of contents. A user with a screen reader can navigate by jumping through headings—they should land on meaningful sections in a logical order. Search engines parse that same structure to understand your page hierarchy and extract key topics. If your headings jump from H1 to H4, or if you have five H1s scattered across a page, you're sending conflicting signals about what matters.

Accessibility isn't separate from SEO here; they reinforce each other. A well-structured heading hierarchy helps both screen reader users and Googlebot. I've watched teams invest in keyword optimization while completely breaking their heading flow, only to find that page doesn't rank as well as expected—and users with visual impairments abandon it immediately.

One clear H1 — The page topic

Every page gets exactly one H1. This is your north star. It should match your page title closely and declare the primary topic of the page. In my experience, if you can't write a clear H1 in 5-10 words, the page probably lacks focus.

Let's say I'm building a help article for an e-commerce platform. The page title might be "How to track your order status | Acme Store." The H1 should be straightforward:

<h1>How to track your order status</h1>

Not:

<h1>Welcome to our help center</h1>
<!-- then later -->
<h1>Order tracking guide</h1>

That second example breaks the rule immediately. A reader (or a screen reader user) expects one main heading per page. Multiple H1s create confusion about what the page is really about. I've debugged crawl reports where pages with multiple H1s weren't ranking for their intended keywords because the search engine couldn't determine the primary topic.

Your H1 should be the only H1 on the page. Period. Everything else lives below it in the hierarchy.

H2s for sections — Each major section gets an H2

Under your H1, every major section of content gets an H2. If I'm writing that order tracking guide, I might structure it like this:

<h1>How to track your order status</h1>

<h2>Track your order on the website</h2>
<p>Sign into your account, go to your order history...</p>

<h2>Track your order via email</h2>
<p>We send tracking links to your email...</p>

<h2>Common tracking issues</h2>
<p>If your status hasn't updated...</p>

Each H2 represents a distinct section that a reader can scan and jump to. A screen reader user can list all headings and hear three clear sections. A search engine sees these topics as supporting the main H1.

I don't use H2s for styling—I use them for structure. The size comes later with CSS.

No skipping levels — Follow the hierarchy strictly

This is where I see the most mistakes. A page will jump H1 → H3 → H2, skipping levels for visual or styling reasons. Don't do this. Your heading hierarchy should descend smoothly: H1, then H2, then H3 if needed, then H4. No gaps.

Here's a bad example from a SaaS dashboard I once audited:

<h1>Dashboard Settings</h1>

<h3>General settings</h3>
<!-- skipped H2 -->

<h3>API configuration</h3>
<!-- skipped H2 -->

A screen reader announced "skipping heading level from H1 to H3"—that's jarring and wrong. The developer wanted H3 to be smaller visually, so they just used H3. But the semantic level and the visual size are different concerns.

Here's the corrected version:

<h1>Dashboard Settings</h1>

<h2>General settings</h2>
<p>...</p>

<h2>API configuration</h2>
<p>...</p>

Then if I need those headings to look like smaller text visually, I apply CSS to the H2 elements.

For a more complex page with subsections, you follow the same logic:

<h1>Building APIs with NestJS</h1>

<h2>Getting started</h2>

<h3>Installation</h3>
<p>...</p>

<h3>Project structure</h3>
<p>...</p>

<h2>Creating controllers</h2>

<h3>Decorators</h3>
<p>...</p>

No skipping. The outline flows naturally. A user navigating by headings encounters a clear path.

Style with CSS — Pick heading levels by meaning, not by size

The biggest mental shift for developers coming from design-first thinking: pick your heading level based on structure, then style it with CSS. Not the other way around.

In real projects, I've had designers hand me a comp where subsection headings are larger than main section headings. That's a design choice, and I honor it with CSS. But the heading level stays true to the structure.

<!-- HTML: semantic structure -->
<h1>Product Guide</h1>

<h2>Installation</h2>

<h3>Docker setup</h3>
<p>...</p>

<!-- CSS: visual design -->
h1 {
  font-size: 2.5rem;
  margin-bottom: 2rem;
}

h2 {
  font-size: 1.5rem;
  margin-bottom: 1.5rem;
}

h3 {
  font-size: 1.25rem;
  margin-bottom: 1rem;
}

/* If a subsection heading needs to look larger, style the H3 -->
h3.prominent {
  font-size: 2rem;
}

That last rule shows the flexibility. I can make an H3 look however I want visually, but it stays an H3 in the document outline because that's where it belongs structurally.

I've worked on platforms with complex layouts—dashboards, admin interfaces, trading terminals—where visual hierarchy doesn't always match content hierarchy. CSS handles that mismatch gracefully. The heading level communicates meaning; CSS communicates aesthetics.

Common mistakes

Multiple H1s on one page: I see this constantly in e-commerce and SaaS sites. One H1 in the header area, another in the main content, sometimes a third in a sidebar. Search engines get confused about the page's primary topic, and screen reader users lose the clear outline.

Using headings for styling only: Wrapping a price in an H3 because it's visually prominent, or wrapping a tagline in an H2 because the designer made it bigger. These aren't headings—they're styled text. Use semantic elements or divs with classes, then style them appropriately.

Skipping heading levels: H1 → H4 with nothing in between. I've debugged accessibility reports where this was flagged by every major testing tool. It confuses assistive technology and creates a broken outline.

Ignoring heading structure in templates and components: On a recent CRM build, our template library had a Card component that always rendered its title as an H3. When that card was used at the H2 level in the page outline, we had a mismatch. We fixed it by making the heading level configurable in the component API.

Empty headings: H2s with no text, or headings that are just images. If a heading has meaning, it should have text content. If it's only an image, provide alt text. Screen readers need something to announce.

Practical checklist for your next page build

• Write your page content first, focusing on structure and meaning.
• Identify the one primary topic (your H1).
• Identify major sections (your H2s).
• Identify subsections if they exist (your H3s, etc.).
• Mark these up with semantic heading elements in order.
• Use your browser's accessibility inspector or a tool like WAVE to verify the heading outline.
• Test with a screen reader (NVDA on Windows, VoiceOver on Mac) to hear how the structure sounds.
• Apply CSS to style headings however the design requires.
• Validate with an automated tool like axe DevTools or Lighthouse.

Key takeaways

• One H1 per page: It's your page's primary topic. Everything else is a child of this heading.
• Headings outline your content: They're not styling choices—they define structure. Pick the level based on meaning, not appearance.
• Never skip levels: Go H1 → H2 → H3 → H4 in order. No H1 → H3 jumps.
• Style with CSS: Use heading levels semantically, then apply whatever visual styling you need with CSS rules.
• SEO and accessibility win together: Search engines and screen readers both parse your heading structure. Getting it right serves both.
• Test with real tools: Use a screen reader or accessibility inspector to verify your outline makes sense to users who can't see it.