Balise hreflang : syntaxe, erreurs fréquentes et outils de vérification
Une balise simple à écrire et facile à casser. La syntaxe aux trois emplacements possibles, les six erreurs qui reviennent, et un vérificateur pour votre bloc.
La balise hreflang indique à Google quelle version d’une page servir selon la langue et le pays du visiteur. Elle s’écrit avec un code langue ISO 639-1, éventuellement suivi d’un code pays ISO 3166-1 alpha-2. Elle doit être réciproque et se citer elle-même : dès qu’une version manque à l’appel, Google ignore l’ensemble du groupe. C’est ce qui rend ce balisage aussi simple à écrire que facile à casser.
Hreflang SEO : à quoi sert vraiment cette balise
Langue, pays, ou les deux
Trois écritures existent, et elles ne veulent pas dire la même chose. Le code seul, fr, cible tous les francophones où qu’ils soient. Le couple langue et pays, fr-BE, cible les francophones de Belgique. Le pays seul n’existe pas : écrire hreflang="be" ne cible pas la Belgique, cela désigne le biélorusse, qui porte ce code langue. C’est l’erreur la plus fréquente sur les sites qui déclinent par marché plutôt que par langue.
Le choix se déduit de votre catalogue. Si le contenu est identique pour tous les francophones, un seul fr suffit et vous évite d’entretenir dix variantes. Si les prix, la devise, les mentions légales ou la disponibilité changent d’un pays à l’autre, alors les couples langue et pays se justifient.
Ce qu’elle ne fait pas
Pour désigner l’adresse à privilégier entre deux versions quasi identiques, c’est la balise canonical qu’il faut utiliser, pas le hreflang.
La balise n’est pas un facteur de classement. Elle ne fait pas remonter une page, elle échange une page contre une autre dans les résultats, à position équivalente. Elle ne remplace pas non plus une traduction : deux pages identiques dans deux langues différentes restent deux pages faibles. Et elle ne bloque rien, contrairement à une idée répandue : ce n’est ni une directive d’indexation, ni une protection contre le contenu dupliqué, seulement un signal de correspondance.
Balise hreflang : la syntaxe, aux trois emplacements possibles
Dans le head de la page
C’est la méthode la plus courante et la plus lisible. Chaque version liste toutes les versions, elle-même comprise.
<link rel="alternate" hreflang="fr-FR" href="https://exemple.fr/page/">
<link rel="alternate" hreflang="fr-BE" href="https://exemple.be/fr/page/">
<link rel="alternate" hreflang="nl-BE" href="https://exemple.be/nl/pagina/">
<link rel="alternate" hreflang="x-default" href="https://exemple.com/page/">
Ce bloc doit être strictement identique sur les quatre pages. C’est cette redondance qui rend le balisage vérifiable par la machine, et pénible à maintenir à la main.
Dans l’en-tête HTTP, pour les fichiers
Une page HTML a un head, pas un PDF. Pour les fichiers, la déclaration passe donc par l’en-tête de réponse du serveur, avec la même logique de réciprocité.
Link: <https://exemple.fr/guide.pdf>; rel="alternate"; hreflang="fr-FR",
<https://exemple.com/guide.pdf>; rel="alternate"; hreflang="en-US"
Dans le sitemap XML, pour les gros sites
Au-delà de quelques centaines de pages multilingues, la déclaration en tête de page devient ingérable : chaque nouvelle langue oblige à modifier toutes les pages existantes. Le sitemap centralise tout au même endroit, ce qui simplifie la maintenance et allège le HTML. C’est la méthode que je recommande dès qu’un site dépasse trois marchés.
Erreur hreflang : les six pièges qui reviennent tout le temps
- Réciprocité manquante. La page A cite la page B, mais B ne cite pas A. Google ignore alors la déclaration, souvent en silence.
- Auto-référence oubliée. Chaque page doit se citer elle-même. C’est contre-intuitif, et c’est obligatoire.
- Codes inventés.
fr-FRest valide,fr-fraussi puisque la casse est ignorée, maisfr-BEL,ukpour le Royaume-Uni oueupour l’Europe ne sont pas des codes reconnus. - Renvoi vers une page morte ou non indexable. Un hreflang qui pointe vers une 404, une redirection ou une page en noindex casse le groupe entier.
- Contradiction avec la balise canonique. Si la version allemande se déclare canonique vers la version anglaise, vous dites deux choses opposées. La canonique gagne, et votre hreflang ne sert à rien.
- x-default absent alors qu’il faudrait. Il désigne la version à servir quand aucune ne correspond. Sans lui, un visiteur japonais tombe sur une page choisie au hasard parmi vos versions.
Générez le bloc une fois, puis collez le même sur toutes les versions, sans le retoucher page par page. La plupart des erreurs de réciprocité viennent d’une modification faite sur une seule version, un mardi après-midi, sans répercuter ailleurs.
Vérifier son balisage avant de le déployer
Collez votre bloc dans l’outil ci-dessous : il contrôle la présence de l’auto-référence, la validité des codes langue et pays, les doublons, les adresses en double et la présence d’un x-default. Rien ne sort de votre navigateur. Une fois le bloc validé, le générateur de balises hreflang du site produit les versions head et sitemap à partir de votre liste d’adresses.
Vérificateur de balises hreflang
Collez votre bloc, tel qu’il figure dans le head de la page. Rien n’est envoyé, tout est analysé dans votre navigateur.
Côté vérification en conditions réelles, la Search Console reste la référence : elle signale les balises sans réciprocité et les codes inconnus, sur les pages qu’elle a réellement explorées. Un explorateur comme Screaming Frog fait le même travail avant mise en ligne, sur l’ensemble du site.
Hreflang WordPress : ce qui fonctionne vraiment
WordPress ne gère pas le multilingue nativement, et aucune extension SEO généraliste ne produit un balisage hreflang correct à elle seule : elles ne savent pas quelles pages se correspondent d’une langue à l’autre. Cette correspondance est le travail des extensions multilingues, qui stockent le lien entre la fiche française et sa traduction, puis émettent le balisage automatiquement.
Les trois familles se valent techniquement, et se choisissent surtout selon votre organisation : traduction interne avec deux ou trois langues, gestion éditoriale complète avec des flux de traduction, ou traduction automatique servie depuis un sous-domaine. Dans tous les cas, vérifiez le rendu réel après installation plutôt que la promesse de la fiche produit, et méfiez-vous des configurations qui produisent une version par pays sans que le contenu ne change d’un octet.
Les codes à connaître, et ceux qui n’existent pas
| Écriture | Ce que ça cible | Valide |
|---|---|---|
| fr | Tous les francophones | Oui |
| fr-FR, fr-BE, fr-CA, fr-CH | Francophones d’un pays donné | Oui |
| en-GB, en-US, es-ES, es-MX, pt-BR | Langue et marché | Oui |
| x-default | Version par défaut, faute de correspondance | Oui |
| uk | Croit cibler le Royaume-Uni, désigne l’ukrainien | Non |
| eu, latam, fr-EU | Zones géographiques inventées | Non |
Un dernier repère utile : le code pays sert au ciblage géographique, pas à la langue parlée sur place. en-CA désigne les anglophones du Canada, fr-CA les francophones du même pays, et les deux peuvent coexister sans se gêner.