Multiple H1 headings
When several components each render their own <h1>, a page ends up with three or four competing “main topics”, and search engines have to guess which one describes the page. It also breaks the heading outline that screen-reader users rely on. Component libraries and AI-generated sections are the usual culprits — each card or hero brings its own <h1>.
Symptoms
How VibeCheck catches it
In your widget · Problems
Multiple <h1> headings
To your coding agent · MCP
agent › get_detected_issues
→ { detector: "seo", issue: "Multiple <h1> headings", threshold: "more than one <h1> element" }
The same string in your widget and in your agent’s context — no screenshot, no copy-paste.
Root causes
The fix
Keep a single <h1> for the page’s main topic and demote every other to <h2> or lower based on its place in the outline. Make reusable components accept a heading level (or default to <h2>) so they never emit a second <h1>.
- Find every
<h1>on the page - Keep the one that names the page; change the rest to
<h2>/<h3> - Parameterise shared components so they do not hard-code
<h1>
<h1>Product overview</h1>
<section>
<h2>Pricing</h2> <!-- was <h1> -->
</section>
<section>
<h2>Features</h2> <!-- was <h1> -->
</section>FAQ
- Is multiple H1 actually penalised?
- There is no direct penalty, but it weakens the topic signal and hurts accessibility. Keeping one
<h1>is a clear, low-cost best practice. - What about the HTML5 outline algorithm?
- The sectioning-based outline algorithm was never implemented by browsers or assistive tech. In practice, use a single
<h1>and ordered<h2>+ headings.