SEO Tools·4 min read

Heading Hierarchy for SEO: Fixing Your H1 to H6 Tree

Heading hierarchy for SEO sounds like a solved problem until you extract a real page's outline and find two H1s, no H2s, and a jump straight to H4. Crawlers and screen readers both rebuild your document's structure from those six tags, so a scrambled tree quietly costs you on both fronts. This guide shows how to pull the full H1 to H6 outline from any URL with the Page Headings Extractor, what a healthy tree looks like, and which structural faults are worth fixing this week versus ignoring forever.

Open the tool All insights

The redesign that scrambles every heading level

A true story, repeatedly.

It usually happens after a redesign. The new component library styles text by class instead of by tag, a developer reaches for whatever level looks right, and six months later the blog's outlines are archaeology: an H1 in the logo, section titles rendered as H4s because the H4 font looked better, and bold paragraphs doing heading work with no tag at all.

Nobody notices visually, because CSS hides the mess. You only see it when you extract the actual tags, which is exactly what the tool does: fetch the URL, list every heading in source order, indent each one by level, and count them per tag.

Heading hierarchy for SEO: how machines read your outline

Search engines use headings to understand what a page covers and how its subtopics relate. An H2 tells the crawler a new major section began; the H3s under it are its children. Google's guidance is relaxed about strictness, and its representatives have said heading order alone won't make or break rankings. A coherent tree still helps passage ranking, featured snippet extraction, and the section anchors Google sometimes shows under a result.

The practical rule: one H1 stating the page topic, H2s for major sections, H3s nested beneath, and no level skipped on the way down. Skipping on the way back up, closing an H3 run and opening a fresh H2, is completely fine.

A worked heading extraction, chip by chip

One URL in, six counts out.

Run a typical documentation page through the extractor and the count chips might read: Input: one URL. Output: H1: 2, H2: 0, H3: 9, H4: 3, H5: 0, H6: 0. That single line already tells the story. Two H1s means the template promotes something, usually the site name, alongside the article title. Zero H2s with nine H3s means the authors skipped a level for typographic reasons.

The fix takes minutes in most CMSs: demote the site name out of H1, promote the nine H3s to H2s, and move their three H4 children up to H3. Re-extract and the chips read H1: 1, H2: 9, H3: 3, which is the shape a healthy article of this kind should show.

The multiple h1s debate, settled by your own tree

HTML5 briefly promised that each section could carry its own top-level heading, and the multiple h1s debate has run ever since. Google's position is that several H1s won't hurt you. The accessibility community's position is more useful: browsers never implemented the outline algorithm that would have made per-section H1s meaningful, so a single H1 remains the safe convention.

The extractor takes a side too. When it counts more than one H1 it displays a warning suggesting one per page. Treat that as a nudge rather than an emergency, and fix it the next time you're already touching the template.

Headings and accessibility: the outline screen readers navigate

Headings and accessibility are inseparable, because heading navigation is one of the most used features in screen readers. WebAIM's user surveys have repeatedly found that most screen reader users move through long pages by jumping between headings. A skipped level there isn't cosmetic; the listener hears the jump and loses track of what nests under what.

This is the strongest argument for repairing a scrambled tree even if rankings never move an inch. The same extraction that serves your SEO review doubles as a quick accessibility spot check.

Heading structure faults an extracted tree exposes

Five patterns show up constantly once you start extracting outlines:

Fake headings: bold or enlarged paragraphs that carry no tag, invisible to the tree and to assistive tech.
Level skipping for looks, like jumping from H2 to H4 because the H3 font seemed too large.
Template H1s wrapped around logos or taglines, doubling the H1 count on every page of the site.
Heading tags used as design elements for pull quotes or buttons, which pollutes the outline with non-structural text.
Empty heading tags left behind by page builders, which read as blank items to a screen reader.

Habits worth keeping around heading fixes

Copy the outline before you change it. Every row in the tree has a copy button, and pasting the before and after into your ticket makes the change reviewable. Then re-extract the live URL after deploying, not the staging preview; caching and template differences have embarrassed plenty of people who verified the wrong environment.

If you write content briefs, steal outlines shamelessly. Extracting the top three ranking pages for a query hands you their heading skeletons, and the gaps between them are your angle.

When the headings tree needs a partner tool

The extractor reads structure, not substance. Run the Keyword Density Checker when you suspect the headings repeat the target phrase too aggressively; its URL mode analyzes exactly the title and headings you just extracted. The Meta Tag Analyzer covers the title tag and description, which live outside the H1 to H6 range but fail in similar ways. And when the heading findings raise wider concerns, the WCAG Accessibility Scanner checks the rest of the page's markup against the full ruleset.