Le mythe du `h1` unique : quand on réinvente les standards

Ça va piquer. Mais on aime bien.
Pour les pressés par rien, résumé :

• Faux : "Un seul h1 par page est obligatoire pour le SEO" ;
• Faux : "Le W3C/WCAG impose un h1 unique" ;
• Faux : "C'est inutilisable par les lecteurs d'écran" ;
• Vrai : John Mueller (Google) confirme que plusieurs h1 n'ont aucun impact SEO ;
• Vrai : HTML5 permet (et encourage même) plusieurs h1 dans les sections ;
• Vrai : Ce qui compte, c'est la hiérarchie logique, pas le nombre de h1.

Un peu de temps pour lire ? Allez, c'est parti !

Le mythe

Comme tout bon mythe, il a une origine. Mais d'où ça vient ?

La légende urbaine

Depuis des années, on entend partout la même antienne :

"Une page web doit avoir UN SEUL h1, sinon Google va pénaliser le site."

Et gnagnagna…

Cette affirmation est répétée en boucle par :

• Des agences SEO qui facturent des audits sur ce "problème" ;
• des consultants qui se positionnent en experts
• des formations SEO qui recyclent des "bonnes pratiques" d'un autre âge
• des outils d'audit qui flaggent automatiquement plusieurs h1 comme une "erreur"

Le problème ?

C'est aussi vrai que de dire qu'il faut mettre des mots-clés en blanc sur fond blanc pour mieux ranker, ou encore de mettre des button partout à la place de liens pour des histoires de maillage. Vous savez non ? La fameuse obfuscation…
Autrement dit, on est en pleine mythologie.

La vérité…

… et je ne mens pas.
Ce que dit vraiment Google…

John Mueller met les points sur les i

John Mueller, un gars en fin d'alternance chez Google, a confirmé à plusieurs reprises que :

"You can use h1 tags as often as you want on a page. There's no limit, neither upper nor lower bound."

Traduction : Vous pouvez utiliser autant de h1 que vous voulez. Pas de limite haute, pas de limite basse. Aucun impact SEO.

Et il s'est même fendu d'une vidéo (voir les sources plus loin) qui est résumée par :

In this episode of Ask Google Webmasters, John Mueller discusses how to handle multiple H1 headings and accessibility, and whether multiple H1 headings work with Google systems.

Traduction : Dans cet épisode de Ask Google Webmasters, John Mueller explique comment gérer plusieurs titres H1 et l'accessibilité, et si plusieurs titres H1 fonctionnent avec les systèmes Google.

Mais bon, ce n'est « que » John Mueller, hein.

Ce qui compte vraiment pour Google

1. La hiérarchie logique des titres ;
2. La pertinence sémantique du contenu ;
3. L'expérience utilisateur.

Le nombre de h1 ? Google s'en préoccupe autant que de savoir si vous préférez les tabs ou les espaces dans votre éditeur de code.

Le W3C Working Group tranche définitivement

Loretta Guarino Reid, membre du W3C WCAG Working Group, a confirmé noir sur blanc en 2012 que :

"WCAG does not require strict hierarchy in headings. It recommends it but does not require it. Using two h1 headings in an HTML document would not violate any of the success criteria, so WCAG would not prohibit it."

Traduction : Les WCAG ne requièrent pas de hiérarchie stricte dans les titres. Elles le recommandent mais ne l'imposent pas. Utiliser deux balises h1 dans un document HTML ne violerait aucun critère de succès, donc les WCAG ne l'interdisent pas.

Et elle ajoute :

"So long as the heading structures provided match the content, there is no prohibition against an HTML page having multiple H1 heading elements or not following a strict hierarchy of headings."

Traduction : Tant que la structure des titres fournie correspond au contenu, il n'y a aucune interdiction contre une page HTML ayant plusieurs éléments H1 ou ne suivant pas une hiérarchie stricte de titres.

Conclusion officielle du Working Group :

"Rewrite the response to state that 2 h1 headings does not violate the success criteria so WCAG conformance would not prohibit it."

Traduction : Réécrivez la réponse pour indiquer que deux titres h1 ne violent pas les critères de succès et que la conformité aux WCAG ne l'interdit donc pas.

TPGi enfonce le clou

TPGi, référence mondiale en accessibilité numérique, confirme dans son article de référence :

"Users typically expect only a single h1, which is used to represent the main heading or title on the page. As long as the visual presentation of multiple h1s doesn't imply a hierarchy (such as the first h1 being styled visually to be larger or bolder than the second h1), then having more than one h1—while potentially confusing—does not represent a WCAG failure."

Traduction : Les utilisateurs s'attendent généralement à un seul h1, utilisé pour représenter le titre principal de la page. Tant que la présentation visuelle de plusieurs h1 n'implique pas de hiérarchie (comme le premier h1 stylisé visuellement plus grand ou plus gras que le second h1), alors avoir plus d'un h1 — bien que potentiellement déroutant — ne représente pas une violation WCAG.

Et TPGi précise également :

"While such a heading hierarchy may be unusual, the absence of an h1 does not represent a WCAG failure. The converse is also true: a top-heavy heading hierarchy is unusual but not incorrect."

Traduction : Bien qu'une telle hiérarchie de titres puisse être inhabituelle, l'absence d'un h1 ne représente pas une violation WCAG. L'inverse est également vrai : une hiérarchie de titres surchargée en haut est inhabituelle mais pas incorrecte.

Les standards

Qu'est-ce qu'ils en disent ?
Spoiler alert : rien. Absolument rien.

Quand on dit standards : W3C, WCAG, WAI…
Ce qui exclut les articles qui remontent des stats qu'on ne verra jamais, mais volontiers mises en avant dans « Pourquoi nous faire confiance ?».

W3C & HTML5

Le W3C ne dit nulle part qu'il faut un seul h1. Si ça se trouve, ils n'y connaissent rien, en vrai.

En réalité, HTML5 encourage même plusieurs h1 grâce au concept de sectioning :

<body>
  <header>
    <h1>Mon site web</h1>
  </header>

  <main>
    <article>
      <h1>Article principal</h1>
      <section>
        <h1>Section de l'article</h1>
      </section>
    </article>
  </main>

  <aside>
    <h1>Widget latéral</h1>
  </aside>
</body>

C'est valide W3C.
C'est même la spécification officielle HTML5.

WCAG 2.2 (Accessibilité)

Les WCAG ne mentionnent pas le nombre de h1.

Ce qui compte pour l'accessibilité :

• Hiérarchie logique : h1 > h2 > h3 (pas de saut, genre h1 > h3 direct) ;
• Structure cohérente : les titres doivent refléter l'organisation du contenu ;
• Contexte clair : un utilisateur de lecteur d'écran doit comprendre la structure.

Aucune mention de "h1 unique obligatoire".

WAI-ARIA

Même son de cloche. Le WAI-ARIA se préoccupe de la sémantique et de la structure, pas du comptage de balises.

Le mythe persiste

L'héritage de HTML4 (pré-2014)

Avant HTML5, il y avait une convention (pas une règle) de n'utiliser qu'un seul h1 par page, car HTML4 n'avait pas de sectioning.

C'était l'époque où on faisait des mises en page avec des tableaux imbriqués sur 12 niveaux. On a un chouilla évolué depuis.

Le business model de l'audit SEO

Imaginons que l'on vous dise : "Faites ce que vous voulez avec vos H1, du moment que c'est cohérent." Difficile de facturer 3000 euros d'audit avec ce discours.
En revanche, si je vous explique que vos 3 h1 sont un problème critique qui massacre votre SEO, vous allez sortir la carte bleue illico.

C'est la différence entre un consultant et un vendeur de poudre de perlimpinpin.

La confusion avec l'outline algorithm HTML5

Un élément souvent oublié : l'algorithme d'outline HTML5, cette promesse jamais tenue. L'idée était séduisante : utiliser <section>, <article> et consorts pour recalculer automatiquement les niveaux de titres selon l'imbrication. Un composant avec son h1, réutilisable partout, le navigateur s'occupant d'ajuster le niveau. Sauf que aucun navigateur ne l'a jamais implémenté.
En 2016, la spec HTML 5.1 a officiellement abandonné cette recommandation, et les éditeurs comme Steve Faulkner ont été clairs : utilisez h1-h6 explicitement. Point barre.

Le piège ? Certains navigateurs réformistes ont ajouté un rendu visuel partiel qui donnait l'illusion que ça fonctionnait, mais l'arbre d'accessibilité restait plat avec des h1 partout. Les développeurs voyants pensaient avoir une hiérarchie correcte, les utilisateurs de lecteurs d'écran se retrouvaient dans le chaos.

C'est en partie cette confusion historique qui alimente encore aujourd'hui la méfiance de certains consultants SEO envers les multiples h1. Ils mélangent une fonctionnalité morte avec les standards actuels.
Résultat : ils interdisent quelque chose qui n'a jamais été problématique, tout en se basant sur un algorithme qui n'a jamais existé en dehors du papier virtuel de nos nuits blanches.

Les outils d'audit mal configurés

Beaucoup d'outils SEO (Screaming Frog, Semrush, etc.) flaggent automatiquement plusieurs h1 comme une "erreur" ou un "warning".

Pourquoi ? Parce que leurs développeurs ont codé des règles basées sur… le mythe. On tourne en rond, c'est charmant.

Ce qui compte vraiment

Pour le SEO et l'Accessibilité, on y vient aussi.

La hiérarchie logique

Mauvais exemple (hiérarchie incohérente)

<h1>Page d'accueil</h1>
<h4>Sous-titre</h4> <!-- On saute allègrement H2 et H3 -->
<h2>Section</h2>

Bon exemple (hiérarchie cohérente)

<h1>Page d'accueil</h1>
<h2>Sous-titre</h2>
<h3>Détail</h3>

La pertinence sémantique

Vos H1/H2/H3 doivent refléter la structure logique du contenu, pas juste être là pour faire plaisir à un algorithme fantasmé.
Et encore moins pour répondre à un design ! Un titre de niveau 4 peut tout à fait ressembler à un titre de niveau 1. C'est du style CSS, pas de la sémantique.

Mauvais : <h1>Cliquez ici</h1>
Bon : <h1>Guide Complet de l'Accessibilité Web en 2026</h1>

L'expérience utilisateur

Un utilisateur (voyant ou non-voyant) doit pouvoir naviguer dans la structure pour trouver l'information rapidement.

Les lecteurs d'écran permettent de sauter de titre en titre. Si vos titres sont bien structurés, c'est fluide. Si c'est le chaos, c'est comme essayer de lire un livre dont les chapitres sont mélangés.

Cas pratiques

Quand plusieurs h1 sont justifiés

Exemple 1 : Page avec plusieurs articles (blog, news)

<main>
  <article>
    <h1>Article 1 : Le mythe du `h1` unique</h1>
    <p>Contenu...</p>
  </article>

  <article>
    <h1>Article 2 : Les standards web mal compris</h1>
    <p>Contenu...</p>
  </article>
</main>

Valide W3C. Aucun impact SEO négatif. Accessible.

Exemple 2 : Dashboard avec widgets

<main>
  <section>
    <h1>Statistiques de vente</h1>
    <!-- Graphique -->
  </section>

  <section>
    <h1>Activité récente</h1>
    <!-- Liste d'activités -->
  </section>
</main>

Pertinent sémantiquement. Chaque section est autonome.

Exemple 3 : page produit e-commerce

<main>
  <h1>Nom du produit</h1>

  <section>
    <h2>Description</h2>
  </section>

  <aside>
    <h1>Produits similaires</h1> <!-- Sidebar autonome -->
  </aside>
</main>

Ici, un seul h1 dans le main suffit amplement, mais techniquement, plusieurs h1 ne casseraient rien.

Combien de h1 utiliser ?

La vraie réponse : ça dépend.

• Une landing page simple ? 1 seul h1 suffit amplement
• Un blog avec liste d'articles ? 1 h1 par article, c'est logique
• Un dashboard ? 1 h1 par widget/section
• Une page sans contenu principal ? 0 H1, et alors ? Google n'en fera pas une crise existentielle

La règle d'or

Utilisez la structure de titres qui reflète le mieux votre contenu.
Pas celle qui "plaît à un outil d'audit mal configuré".

Valider la structure

Comment vérifier si la structure est bonne ? Comme la musique.

Utilisez HeadingsMap

Extension Chrome/Firefox qui affiche la hiérarchie des titres sous forme d'arbre.
Si l'arbre est logique, c'est bon. Si on dirait un sapin de Noël après le passage d'un chat hyperactif, c'est à revoir.

Testez avec un lecteur d'écran

Activez NVDA, Narrateur ou VoiceOver et naviguez de titre en titre.
Si vous vous y retrouvez facilement, c'est bon. Si vous êtes perdu comme dans un labyrinthe sans plan, c'est à revoir.

Relativisez les "warnings" des outils d'audit

Screaming Frog qui signale "Multiple h1 found" ? Prenez une grande inspiration et demandez-vous si c'est vraiment un problème dans votre contexte.
Google Search Console qui remonte une "erreur" ? Vérifiez le contexte, mais ne changez pas systématiquement juste pour faire plaisir à un bot. Pour ce site, il n'y a jamais eu d'erreur dans console Google, d'ailleurs.

Test en conditions réelles

Cette page contient plusieurs h1. Testée avec les outils de validation reconnus :

Aucun outil conforme aux standards ne remonte d'erreur. Normal : ce n'en est pas une.

Le cas du validateur W3C et ses warnings obsolètes.
Le validateur W3C peut afficher un warning (pas une erreur) sur les pages contenant plusieurs h1 :

"Consider using the h1 element as a top-level heading only — or else use the headingoffset attribute"

Deux choses à noter :

1. C'est un warning, pas une erreur. Le code reste valide.
2. L'attribut headingoffset suggéré… n'existe pas. C'était une proposition HTML5 abandonnée il y a plus de 10 ans.

Ce warning illustre parfaitement le problème : même les outils officiels traînent encore des recommandations obsolètes basées sur des specs jamais implémentées.
En pratique : si votre structure de titres est logique et cohérente, ignorez ce warning. Il ne reflète pas les standards actuels.

Conclusion

Arrêtez de croire les légendes urbaines.

Les faits

1. Google se préoccupe du nombre de h1 comme vous vous préoccupez du nombre de grains de sable sur une plage ;
2. Le W3C n'impose rien sur le nombre de h1 ;
3. Les WCAG ne mentionnent pas le h1 unique ;
4. HTML5 encourage même plusieurs h1 dans les sections.

Ce qui compte vraiment

• Hiérarchie logique (pas de saut h1 > h3) ;
• Pertinence sémantique (vos titres décrivent le contenu) ;
• Expérience utilisateur (navigation fluide au clavier/lecteur d'écran).

In fine…

Faites confiance aux standards officiels, moins aux consultants qui réinventent les règles pour justifier leurs prestations. Même s'ils coûtent cher, ce n'est pas un gage de connaissance.

Et si quelqu'un vous dit "Vous avez 3 h1, c'est catastrophique pour le SEO", demandez-lui poliment de citer une seule source officielle Google qui le confirme.
N'attendez pas et allez prendre l'air en attendant la réponse, la recherche va être looooongue.

Sources & Ressources

Ah ben oui, on n'invente rien, on a lu et écouté.

• John Mueller (Google) sur les h1 multiples - YouTube ;
• Spécification HTML5 W3C ;
• Working Group
• WCAG 2.2 - Critère 1.3.1 Info and Relationships ;
• HeadingsMap Extension.
• TPGI Heading off confusion