vibecheck0.3.0
Search visibilityseoh1-multipleinfo

Multiple H1 headings in Vue

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 Vue

Use a dynamic component so the heading level is a prop, defaulting to h2.

vue
<template>
  <component :is="as">{{ title }}</component>
</template>

<script setup lang="ts">
defineProps<{ as?: 'h1' | 'h2' | 'h3'; title: string }>()
</script>

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.