DANA: Different shape of question today. A developer on a board game publisher’s site wants to use multiple H1 tags on a single page, one per major section, and they’re not wrong on the spec. HTML5 technically allows it, the sectioning model says each section can have its own top-level heading. The content team is uneasy. This isn’t a “bad idea, do we stop it” call. Both sides have a real point. So which way do we land?
ELENA: Start with what’s actually true, because the developer is half right and half out of date. HTML5 introduced an outline algorithm where nested sections each get their own H1 and the browser figures out the hierarchy. The catch is that algorithm was never implemented. No browser, no major screen reader ever built it. So “the spec allows it” is true on paper and meaningless in practice, because nothing on the user’s end actually computes that outline.
HANNAH: And I want to be careful here, because this is exactly where I’d otherwise repeat a claim I can’t stand behind. What I’ll assert: the documented guidance from accessibility and standards bodies has moved toward a single H1 with a properly nested H2 and H3 structure, precisely because the outline algorithm never shipped. What I won’t assert is a specific ranking penalty for multiple H1s, because search engines have said heading structure is a soft signal, not a hard rule. So the strongest case isn’t “Google punishes it.” It’s “the thing that was supposed to make it work doesn’t exist.”
GRACE: Which lands it back in my territory, because headings aren’t decoration, they’re how the document tells you its shape. One H1 is the title of the page, the single thing it’s about. Several H1s tell the reader, and the screen reader, that the page is about several coequal things with no parent. On a board game page covering one game, that’s just false. The page is about the game. The rules, the components, the player count, those are parts of it, not peers of it. H2s say “part of.” A second H1 says “separate.”
MARCUS: Fine, but you’re all ganging up on the developer, and the developer has a point you’re skating past. Their instinct isn’t really about the H1 tag. It’s that the page has several big, distinct sections and they want each one to feel like a strong, standalone entry. That’s a legitimate design goal. So the honest answer isn’t “you’re wrong,” it’s “your goal is right, the tag is the wrong tool for it.” If we just quote the spec at them, we lose them. What does their goal actually need?
SOFIA: That’s the useful reframe. The developer wants each section to carry weight. You get that with a clear, descriptive H2 and visual hierarchy, big type, spacing, a strong lead line. The reader feels the section’s importance from the design and the wording, not from whether the tag is an H1 or an H2. The heading level is for structure, the visual treatment is for impact. Conflating the two is the actual mistake, and it’s an easy one to make.
NOAH: There’s a pattern worth naming, separate from this one page. If the developer is reaching for multiple H1s here, they’re probably doing it sitewide, and probably reasoning from “the spec allows it” as a general principle. So this isn’t one page’s heading question. It’s a template decision that’s likely already replicated across every product page. Whatever we land on, the scope is bigger than the page in front of us.
PRIYA: And from a positioning angle, there’s a quieter cost. A clean single-H1 structure with nested headings is also what makes a page eligible to be understood as one coherent topic. If you fragment the page into multiple top-level headings, you’re subtly telling search engines the page has no single subject. For a publisher who wants each game page to own that game’s name, structural clarity and topical ownership point the same way. Multiple H1s work against the very thing they’d want.
THEO: Process layer. The developer didn’t arrive at this randomly, they read a spec, applied it literally, and didn’t check whether it was ever real. That’s the actual gap, not the heading itself. So the deliverable isn’t “use one H1, we said so.” It’s giving them the why, the outline algorithm was specced but never implemented, so structure has to be built explicitly with one H1 and nested headings. If they understand the reason, they’ll apply it everywhere correctly. If we just hand down a rule, they’ll follow the next plausible spec quote off a cliff.
AIKO: And the system note, which is about how this kind of decision gets made. A developer made a structural call from the spec, and a content team felt something was off, and the two only met because this happened to surface. The fix that prevents the next version of this is a shared definition of who owns heading structure, and a quick reference that captures decisions like this one so it isn’t relitigated per page, per developer, every time someone reads a spec and takes it literally.
MARCUS: I’ll give you that, but let me close my own loop, because I opened defending the developer. Their goal stands, strong distinct sections, and we should deliver it. But on the tag itself, there’s no real tradeoff once you know the algorithm never shipped. The “HTML5 allows it” argument isn’t a competing valid option, it’s a fact about a feature that doesn’t function. So this isn’t a 50-50 we’re splitting. It’s a goal we honor and a method we correct.
DANA: That’s the landing, and I want to be precise about why, because Dana-says-so isn’t a reason. We use a single H1 per page. Not because multiple H1s are forbidden, and not because of a ranking penalty we can’t prove, but because the mechanism that was meant to make multiple H1s work was never built into a single browser or screen reader, so in the real world they only flatten the page’s structure for both readers and machines. The developer’s actual goal, sections that feel strong and distinct, is right, and we deliver it through descriptive H2s and visual hierarchy, which is where impact actually comes from. We explain the outline-algorithm history so the reasoning travels, we check the rest of the templates because Noah’s right that this is already everywhere, and we write down who owns heading structure so we’re not having this conversation again next quarter. The developer keeps their goal. They just get a method that works on the machines people actually use.
GRACE: Which is the whole point. One H1 isn’t a limitation on the page. It’s the page being honest about what it’s about.