vibecheck0.3.0
Search visibilityseoh1-multipleinfo

Multiple H1 headings in React

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>.

Framework fixes

Symptoms

  • Multiple <h1> elements across cards, heroes, or sections
  • The heading outline has several top-level entries
  • Reused components each declare their own <h1>

How VibeCheck catches it

In your widget · Problems

infoseoMultiple <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

  • Reusable section/card components each hard-code an <h1>
  • A page composes several “hero” blocks that each own an <h1>
  • Heading level was chosen for size, not hierarchy

The fix for React

Give reusable section components a level prop so only the page owns the <h1>. Next.js is identical.

tsx
function Section({ as: Tag = 'h2', title }: { as?: 'h1' | 'h2' | 'h3'; title: string }) {
  return <Tag>{title}</Tag>
}
// page renders <h1> once; sections default to <h2>

Steps

  1. Find every <h1> on the page
  2. Keep the one that names the page; change the rest to <h2>/<h3>
  3. Parameterise shared components so they do not hard-code <h1>

See the general, framework-agnostic fix →

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.