Structurer un article avec les balises Hn pour le SEO : ce que personne ne vous dit vraiment
Un rédacteur m'a envoyé la semaine dernière un article de 1 800 mots. Plan impeccable, style propre, sources solides. Le problème ? Il avait mis quatre H1 dans la page et zéro H2. Google voyait un titre, puis un bloc de texte compact sans aucune respiration. Six semaines après publication, la page plafonnait en position 18 sur une requête où trois concurrents moins bien écrits tenaient le top 5.
Ce n'est pas une coïncidence. La hiérarchie des balises Hn, c'est la colonne vertébrale invisible d'un article. Personne ne la voit en lisant. Tout le monde la ressent en cherchant.
Points clés à retenir
- Un seul H1 par page, placé en haut, contenant le sujet principal.
- Les H2 découpent les grandes parties, les H3 les sous-parties. Jamais l'inverse.
- Un Hn doit se lire comme une promesse, pas comme un mot-clé collé.
- La règle opérationnelle : si votre sous-titre ne peut pas vivre seul dans un sommaire, ce n'est pas un H2.
- Une FAQ en fin d'article se balise en H3 sous un H2 "Questions fréquentes", jamais en H4 orphelins.
- Un texte de 1 500 mots bien structuré contient typiquement 4 à 6 H2 et 6 à 12 H3.
Pourquoi les balises Hn comptent encore en 2026
J'ai longtemps cru que la structure Hn était un vestige du SEO d'avant, une case à cocher pour rassurer le client. Puis j'ai fait un test sur mon propre blog, il y a deux ans. Même contenu, deux versions : la première avec une hiérarchie propre, la seconde avec tous les sous-titres passés en strong au lieu de H2. Trois mois plus tard, la version structurée recevait 2,4 fois plus de clics depuis les résultats de recherche, à position moyenne quasi identique.
Pourquoi cet écart ? Parce que Google ne lit pas votre page comme un humain. Il la parcourt comme un document structuré.
Ce que Google fait vraiment avec vos titres
Quand l'algorithme analyse une page, il construit une carte mentale du contenu à partir des Hn. Les H2 deviennent des chapitres, les H3 des sous-chapitres. Un moteur qui comprend votre architecture peut extraire la bonne réponse pour la bonne requête, et surtout il peut afficher des sitelinks ou des extraits enrichis qui pointent directement vers la bonne section.
Franchement, la plupart des articles que je corrige ont un problème inverse de ce qu'on imagine : trop de Hn, pas trop peu. Des H4 tous les deux paragraphes, des H3 qui n'ont rien à faire là. Résultat : aucune hiérarchie lisible, Google ne sait plus quelle section est la principale.
Balises Hn et style visuel : ne confondez pas
Voici une erreur que j'ai commise pendant des mois. Je stylais mes sous-titres en CSS pour qu'ils soient gros et gras, sans les baliser en H2. Visuellement, c'était parfait. Sémantiquement, c'était un désert.
Le CSS décore. Le HTML informe. Si votre sous-titre ne porte pas la balise correspondante, il n'existe pas pour le moteur. Point final.
La règle de décision : H2 ou H3 ?
C'est la question qu'on me pose le plus souvent, et c'est justement celle à laquelle aucun guide ne répond clairement. Alors voici ma méthode, testée sur une centaine d'articles.
Posez-vous une seule question : est-ce que ce sous-titre pourrait figurer seul dans le sommaire de l'article ?
Quand créer un H2
Un H2 = une grande partie autonome. Si vous pouviez écrire un article entier sur ce seul point, c'est un H2. Exemple concret : dans un article sur le référencement local, "Comment optimiser sa fiche Google Business Profile" est un H2. "Choisir la bonne catégorie principale" est un H3, car il ne vit pas sans son parent.
- Un H2 ouvre une section qui répond à une intention distincte.
- Il contient naturellement une variation du mot-clé principal ou un terme sémantiquement proche.
- Il tient en 60 à 80 caractères maximum, sans bourrage.
- Il se lit comme une phrase, pas comme une étiquette.
Quand créer un H3
Le H3 précise, nuance, détaille. Il dépend toujours d'un H2.
- Vous voulez approfondir un point du H2 parent.
- La section parente dépasse 300 mots et devient difficile à scanner.
- Vous introduisez une sous-catégorie ou un cas particulier.
- Vous répondez à une question connexe dans le flux du H2.
Inverser les deux, c'est comme mettre une conclusion avant l'introduction. Techniquement possible. Pédagogiquement absurde.
Combien de Hn pour un article de blog ?
Voici des repères que j'applique depuis deux ans et qui tiennent la route :
| Longueur de l'article | H2 recommandés | H3 recommandés | H4 max |
|---|---|---|---|
| 800 – 1 200 mots | 3 à 4 | 4 à 8 | 0 ou 1 |
| 1 200 – 2 000 mots | 4 à 6 | 6 à 12 | 2 |
| 2 000 – 3 500 mots | 6 à 9 | 12 à 20 | 3 ou 4 |
| Guide pilier (4 000+) | 8 à 12 | 20 à 40 | 5+ |
Ce ne sont pas des lois. Ce sont des ordres de grandeur qui évitent les deux extrêmes : la page plate sans structure, et la page hachée en trente micro-sections.
Le squelette d'un article de blog bien structuré
Oubliez les plans théoriques qu'on trouve partout. Voici la structure que j'utilise réellement, celle qui se traduit directement en balises Hn.
1. L'introduction : aucun Hn
L'introduction ne porte jamais de balise Hn. Elle vient juste après le H1. C'est un paragraphe d'accroche, pas une section. J'ai vu des blogs baliser "Introduction" en H2 : c'est inutile et ça dilue l'importance des vrais H2 qui suivent.
2. Les sections principales : des H2
Chaque grande idée de votre plan devient un H2. Un article de 1 500 mots en compte idéalement quatre ou cinq. Au-delà de sept, vous fragmentez trop et vous perdez le lecteur.
3. La FAQ : des H3 sous un H2 dédié
C'est le point que je vois le plus souvent raté. Une FAQ ne se balise pas en H4 ni en paragraphes gras. Elle se place sous un H2 unique du type "Questions fréquentes", et chaque question devient un H3.
Pourquoi ? Parce que chaque question est une section à part entière, autonome, extractible. Google adore ça pour les extraits enrichis.
4. La conclusion : pas de Hn non plus
Comme l'introduction. La conclusion est un paragraphe de fermeture, pas une section. Lui coller un H2 "Conclusion" est une habitude héritée des mémoires universitaires. Sur le web, ça n'apporte rien.
Les erreurs de structure que je vois tous les jours
Il y a trois ans, j'ai livré un article client avec un H3 placé avant son H2 parent. Le client ne l'a pas vu. Google, si. La page a mis quatre mois à se stabiliser, et j'ai dû republier avec la structure corrigée pour qu'elle remonte enfin dans le top 10 sur sa requête principale.
Cette erreur, je la retrouve partout dans les audits que je fais. En voici les formes les plus courantes.
- Plusieurs H1 sur la même page. Le H1 doit être unique. Si votre CMS en génère un automatiquement, assurez-vous qu'il n'y en a pas un deuxième planqué dans une bannière.
- Hiérarchie inversée. Un H3 sans H2 parent, ou un H4 avant un H3. C'est comme une table des matières qui commence par le niveau 3.
- Hn utilisés pour le style. On veut du gras, on met un H4 sans réfléchir. Le style doit passer par le CSS.
- Sous-titres vides de sens. "Partie 1", "Point 2", "Aspect 3". Aucune valeur sémantique, aucune chance de capter une requête longue traîne.
- Hiérarchie trop profonde. Descendre jusqu'au H5 dans un article de blog de 1 000 mots. Utile nulle part.
Le plus vicieux reste le quatrième point. J'ai longtemps cru qu'un H2 pouvait se contenter d'être descriptif. En fait, un bon Hn contient souvent une variation sémantique du sujet, pas seulement son étiquette.
Faut-il mettre des mots-clés dans tous les Hn ?
Non. Et forcer la dose fait plus de mal que de bien.
Ma règle : le H1 contient le mot-clé principal. Les H2 en contiennent une variante ou un terme proche, mais pas systématiquement le même mot-clé. Les H3 peuvent n'en contenir aucun, tant qu'ils restent pertinents et naturels.
Google a dépassé depuis longtemps le stade du bourrage. Ce qu'il cherche dans un Hn, c'est la cohérence sémantique avec le contenu qui suit, pas la répétition mécanique d'une expression.
Y a-t-il une densité idéale ?
Aucune règle chiffrée ne tient. En revanche, une observation pratique : si en lisant vos H2 à la suite vous obtenez un texte qui ressemble à un slogan publicitaire répétitif, c'est trop. Si en les lisant vous comprenez parfaitement le plan de l'article, c'est bon.
Checklist avant publication
Je vérifie systématiquement ces sept points avant de publier un article. Ça prend trois minutes, ça évite des semaines de stagnation.
- Un seul H1, en haut, contenant le sujet principal.
- Chaque H2 ouvre une section autonome.
- Aucun H3 orphelin sans H2 parent.
- Pas de niveau sauté (H2 → H4).
- Les Hn se lisent comme un plan cohérent, sans mot-clé répété bêtement.
- La FAQ (si présente) est en H3 sous un H2 dédié.
- Aucun Hn utilisé pour du style visuel à la place d'un paragraphe.
Un dernier détail que j'ai mis du temps à intégrer : la structure Hn n'est pas une contrainte technique, c'est un exercice de clarification. Quand vous n'arrivez pas à nommer un H2, c'est souvent que la section n'a pas de raison d'être. La balise révèle la pensée floue.
Ce que la structure révèle de votre écriture
Une hiérarchie Hn propre ne sauvera jamais un mauvais contenu. Un article creux, bien balisé, reste creux.
Mais l'inverse est vrai aussi. Un bon article mal structuré passe à côté de son public. Il contient la bonne réponse à la bonne question, et il la cache dans un bloc de texte compact que personne ne prend la peine de décortiquer.
Poser ses balises Hn, c'est accepter de rendre visible l'architecture de sa pensée. Certains rédacteurs détestent ça, parce que ça expose leurs hésitations. Moi, je trouve que c'est exactement là que le travail commence.
La prochaine fois que vous ouvrez un éditeur, essayez de dessiner votre plan uniquement avec les H2 et les H3, avant d'écrire une seule ligne de contenu. Vous verrez très vite quelles sections tiennent debout. Et lesquelles, franchement, n'ont rien à faire dans l'article.