Why a Page Can Look Perfectly Structured and Have an Empty Heading Hierarchy Underneath
A page can have visually-perfect headings β right size, right boldness, right spacing β while having a completely empty semantic heading structure underneath, because CSS can style any element to "look like" a heading regardless of what HTML element it actually is. Here's why "div soup" headings happen with visual page builders, why a sparse heading-extraction result for a competitor's visually-organized page is genuinely meaningful (not misleading), and how to check whether your own visual headings are actually marked up correctly.
By sadiqbd Β· June 18, 2026
A page can have visually-identical headings β same size, same boldness, same spacing β and still have a completely broken heading structure underneath, because "looks like a heading" and "is marked up as a heading" are determined by entirely different things, and only one of them affects SEO/accessibility
The previous articles on this site covered heading extraction for content research, accessibility/WCAG implications, and AI-extraction formatting. This article addresses a foundational, but frequently-overlooked distinction: visual heading styling vs semantic heading markup β and how CSS and HTML can diverge, producing pages that "look" correctly structured while being invisible, structurally, to the tools (search engines, screen readers) that rely on the underlying HTML.
"Looks like a heading" is a CSS/visual decision
Visually, a "heading" is just text that's been styled to look like one β larger font size, bold weight, distinct spacing/margins from surrounding text. Any HTML element β a <div>, a <span>, a <p> β can be styled, via CSS, to look exactly like an <h2> β larger font, bold, appropriate spacing β with zero difference in visual appearance compared to an actual <h2> element.
"Is marked up as a heading" is an HTML semantic decision β using actual <h1> through <h6> elements β which carries meaning independent of how the element is visually styled.
These two things β visual styling and semantic markup β are completely independent β CSS can style any element to look like anything; HTML semantic elements carry meaning regardless of how they're styled (an <h2> styled to look identical to regular body text is still, semantically, a heading β just one that doesn't visually "announce" itself as such).
Why "div soup" headings happen
Design tools/page builders (particularly visual, drag-and-drop website builders, and some CMS page-builder plugins) often generate markup based on visual presentation, not semantic structure β a user drags a "large, bold text" element onto the page, styles it to look like a heading β and the underlying generated HTML might be a <div> or <p> with CSS classes applying the visual styling β not an <h1>/<h2>/etc. element.
From a purely visual perspective β the page looks exactly "right" β headings appear appropriately sized/styled, the visual hierarchy looks correct to a sighted user casually viewing the page.
From the perspective of anything reading the underlying HTML structure (search engine crawlers extracting heading hierarchy for content-understanding purposes, as covered in the original article; screen readers, which allow users to navigate by heading level, as covered in the previous accessibility article) β these "visual headings" don't exist β the page's actual <h1>-<h6> structure might be completely empty, or might consist of just one or two headings, with most of what visually "looks like" the heading hierarchy being invisible, structurally.
The reverse problem: heading tags used purely for styling, regardless of hierarchy
The opposite misuse: using <h1>-<h6> tags because they provide a convenient, pre-styled visual appearance β without regard to whether the resulting hierarchy makes sense β e.g., using <h3> for some text simply because "h3 looks like the right size," without regard to whether there's an <h1> and <h2> appropriately preceding it in the document's structure.
This produces a technically "has heading tags" page β but with a structurally incoherent hierarchy (as covered in the previous accessibility article's discussion of skipped heading levels, multiple <h1>s, etc.) β the presence of heading tags, by itself, doesn't guarantee a meaningful hierarchy β both problems ("visual headings that aren't marked up" and "heading tags used without hierarchical coherence") can, and often do, coexist on the same page.
Why this specifically matters for the previous articles' use cases
For competitive content research (covered in a previous article): extracting "the heading structure" of a competitor's page via heading-extraction tools only sees actual <h1>-<h6> elements β if a competitor's page uses "div soup" for its visual headings β a heading-extraction tool would show a sparse, possibly near-empty heading structure β even if the page, visually, appears to have a rich, well-organized heading hierarchy. This could lead to an incorrect conclusion ("this competitor's page has almost no heading structure β easy to outdo") that doesn't reflect the page's actual, visual organization β though, importantly, it does correctly reflect what search engines/screen readers "see" β meaning, for SEO/accessibility purposes specifically, the heading-extraction tool's "sparse" result is, in a sense, "correct" β it's revealing a genuine structural-SEO/accessibility weakness in the competitor's page, even if that weakness isn't visually apparent.
How to check whether your own visual headings are semantically marked up
Browser developer tools (the "Inspect Element" feature, available in all major browsers) allow viewing the actual underlying HTML β selecting what visually appears to be a heading, and checking the element tag shown in developer tools* β is it <h1>/<h2>/etc.? Or is it a <div>/<p>/<span> with CSS classes providing the visual "heading-like" appearance?
Browser accessibility tools (often integrated into developer tools, or available as browser extensions) can show the "accessibility tree" β a representation of how assistive technology (screen readers) would perceive the page's structure β directly revealing whether visually-apparent "headings" are represented in this tree as headings, or are absent/misrepresented.
For checking the heading hierarchy specifically (this site's tool's core function): running this site's Heading Extractor on your own page and comparing the result against the visual appearance of your page β if the extracted list seems "too short" compared to what the page visually "looks like" it has, for "headings" β this discrepancy itself is the diagnostic signal that "visual headings" and "semantic headings" have diverged on your page.
How to use the Heading Extractor on sadiqbd.com
- Run it on your own pages and compare the extracted heading list against the page's visual appearance β a significant mismatch (fewer extracted headings than visual "heading-looking" elements) indicates semantic-markup issues worth addressing
- For competitive research: recognize that a sparse extracted structure for a competitor's page may genuinely reflect a structural SEO/accessibility weakness, even if the page visually appears well-organized β this is valuable, not misleading, information for SEO-focused competitive analysis specifically
- After fixing semantic markup (changing visual-only "heading-like" elements to actual
<h1>-<h6>elements, with appropriate, coherent hierarchy) β re-run the extractor to verify the extracted structure now matches the page's visual organization
Frequently Asked Questions
If I change a <div> styled as a heading to an actual <h2>, will it change how the page looks?
Not necessarily β <h1>-<h6> elements have default browser styling (specific font sizes/weights/margins, which vary by browser and heading level) β but CSS can override these defaults completely β if your existing <div>'s visual styling is defined via CSS classes (rather than relying on any element-type-specific default styling) β changing the underlying element from <div> to <h2>, while keeping the same CSS classes applied β should produce the same visual appearance, while adding the semantic meaning that was previously missing. The visual change (if any) and the semantic change are independent β you can, generally, fix the semantic issue without affecting the visual appearance, by ensuring CSS styling is applied via classes/selectors that don't depend on the specific element type.
Is the Heading Extractor free? Yes β completely free, no sign-up required.
Try the Heading Extractor free at sadiqbd.com β extract the actual semantic heading structure of any page, and compare it to its visual appearance.