Aller au contenu

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.

Balise hreflang : syntaxe, erreurs fréquentes et outils de vérification

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-FR est valide, fr-fr aussi puisque la casse est ignorée, mais fr-BEL, uk pour le Royaume-Uni ou eu pour 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.
Le réflexe qui évite la moitié des erreurs

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

ÉcritureCe que ça cibleValide
frTous les francophonesOui
fr-FR, fr-BE, fr-CA, fr-CHFrancophones d’un pays donnéOui
en-GB, en-US, es-ES, es-MX, pt-BRLangue et marchéOui
x-defaultVersion par défaut, faute de correspondanceOui
ukCroit cibler le Royaume-Uni, désigne l’ukrainienNon
eu, latam, fr-EUZones géographiques inventéesNon

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.

Tom Lionne Consultant SEO indépendant depuis 2018. Parlons de votre site.
À lire ensuite
La lettre du lundi

Un récap, chaque lundi matin.

Les articles publiés dans la semaine, résumés en quelques lignes. Rien d'autre : pas de relance, pas de promotion.

Un e-mail de confirmation vous sera envoyé. Désinscription en un clic, votre adresse n'est ni revendue ni utilisée ailleurs.