The design review opens on a landing page that looks clean. The hero line is an h3 because the brand type scale already used the largest size on a label above it. The pricing table jumps from h2 to h4 so the section titles sit closer to the cards. Nobody changed the copy. They changed what the document claims about itself. When SEO or accessibility pushes back, the answer is often some version of “we can’t sacrifice the layout.” That is the wrong frame. Heading hierarchy is not a design trade-off. CSS controls how headings look. HTML controls what they mean.
What heading hierarchy means in HTML (and what it is not)
In HTML, h1 through h6 are structural markers. They tell browsers, assistive technology, search crawlers, and downstream tools what the outline of the page is: title, major sections, subsections. Typography is a separate job. You can make an h2 look like a whisper and an h4 look like a billboard if the stylesheet says so. What you should not do is pick heading levels to match font size. That confuses every consumer that reads the DOM for structure, not computed style.
A healthy page usually has one h1 that names the document, then h2 elements for the main sections a reader would skim, then h3 (and occasionally h4) for subsections under each h2. Skipping levels (h2 straight to h4) or using multiple h1 elements because “each block is important” breaks the outline. The page can still win a screenshot review. It fails the structural one.
Why teams treat headings as a visual problem
The habit is understandable. Design systems ship type ramps first. Components arrive with a “title” slot that maps to whatever size looks right in Figma. Marketing pastes a new hero and keeps the existing class names. A/B tests swap modules without anyone checking whether the outline still makes sense. By the time the page ships, the heading map is a record of layout decisions, not content hierarchy.
That drift is easy to miss because most sighted users infer structure from size, weight, and whitespace. Screen reader users get a list of headings in level order. Crawlers and summarisers often weight headings heavily when they guess what a page is about. LLM pipelines that extract “sections” from HTML follow the tags, not the CSS. When visual hierarchy and document hierarchy diverge, you are asking non-visual readers to reverse-engineer your design choices.
How broken heading levels hurt SEO and internal linking
Search engines still use headings as one signal among many, not as a magic lever. They do help parsers understand which blocks belong together, which questions a page answers, and which phrases are section titles rather than body copy. A pricing page whose only h2 is buried under three decorative h4 labels makes the commercial intent harder to read. A service page that restarts at h1 in every component looks like several unrelated documents stitched together.
The damage is often local rather than site-wide: one template with inverted levels can underperform on long-tail queries that match subsection titles you hid inside paragraph styling. That is a different problem from Core Web Vitals scores on the same URL, and a different fix from the metric work we covered when asking which accessibility fixes show up in CWV dashboards. Headings are document semantics. CWV dashboards tell you whether interaction latency and layout stability are hurting real users. Both matter; neither substitutes for the other.
For the broader SEO picture on why performance and experience signals sit beside content quality, see How Core Web Vitals impact SEO rankings: what the data shows on our Watcher blog. Use that guide when a client asks whether fixing LCP is enough; use heading audits when they ask why a well-written section never ranks for its title phrase.
What screen readers do when you skip from H2 to H4
Assistive technology exposes headings as a navigable outline. A keyboard user can jump from section to section without reading every line between. When levels skip, the outline lies about nesting: an h4 after an h2 implies a missing h3 parent that is not in the document. Some users still work through the page linearly, but the quick-navigation feature becomes unreliable. Others lose confidence that the heading list matches the visual layout they cannot see.
The overlap with performance work is real. Focus jumps, late-loading banners, and unstable layout hurt keyboard users and show up in CWV. Semantic headings do not fix INP or CLS on their own. They do stop you from shipping a page that is painful to navigate for reasons that never appear in a Lighthouse performance score. Our Watcher guide on accessibility and Core Web Vitals goes deeper on INP with keyboard input, focus-visible requirements, and CLS from focus management. Treat heading fixes as part of the same accessibility habit, not as a separate “SEO ticket.”
Why LLMs and answer engines read headings differently than CSS
Models and retrieval tools that ingest HTML often chunk content by heading boundaries. If your true section title is a styled p and the nearby h3 is only a kicker label, summaries attach the wrong label to the paragraph block. FAQ modules that mark every question as h2 flatten a page into a list of peer topics with no parent section. Comparison tables that promote each column header to h3 create phantom sections that never appear in the visible layout.
Agencies are already being asked whether pages are “visible in ChatGPT” and similar systems. That question is partly about crawl policy, partly about content quality, and partly about whether machines can parse what humans see. Broken heading hierarchy is a quiet failure mode: the prose is fine, the design is fine, the outline is nonsense. For a measurement-first view of AI search visibility, see Are we visible in ChatGPT? What agencies can measure first. Fix headings before you chase new schema types for the same page.
How to keep one H1 and logical H2/H3 without flattening the design
Separate the two layers in code review. Content authors (or the CMS) own the outline: one h1, ordered sections, no skipped levels without a deliberate subsection. Design owns the presentation: font size, weight, spacing, colour, and responsive behaviour via classes or design tokens. If the hero needs a small kicker above the main title, use a p or span with a kicker class, not an h1 or h2 chosen for size. If a card title should look large but sit under a section h2, use h3 inside the card and style it to match the comp.
Practical rules we use on client templates:
- Map Figma text styles to CSS classes, not to heading levels.
- Ban “heading level” as a prop on generic layout components unless the component is actually a section title.
- Run an outline check in CI or pre-publish QA: export heading levels in order and read them without the stylesheet.
- When you refactor, fix the HTML first, then adjust CSS. Never the reverse.
You do not need ugly pages. You need honest pages: the DOM outline should match the story a competent reader would tell from the layout. When design and semantics disagree, the stylesheet is the right place to compromise, not the heading level.
How to audit heading structure on a client template before the next deploy
Open the page, disable author styles or use the accessibility tree, and list headings in level order. Read only that list aloud. If it sounds like nonsense, the template is not ready. Compare the list to the sitemap intent: does each h2 name a section a client would put in a report slide? Do h3 elements belong to the h2 above them, or did a carousel inject stray levels?
Pick one high-traffic template (homepage, pricing, core service) and one long-form article layout. Fix those two before you normalise every blog component. Pair the heading pass with the accessibility and CWV checks you already schedule: keyboard tab through the same URLs, note focus surprises, and keep monitoring LCP, INP, and CLS in Apogee Watcher so semantic fixes do not get credited while regressions slip in elsewhere. On Monday, send the design lead the heading list without CSS and ask one question: “If you could not see the page, would this outline still be the story we want?” When the answer is no, reach for the stylesheet, not a lower heading level.
Top comments (0)