Dans cet article
- Ce que signifient vraiment en-CA, en-US, fr-CA et es-US
- Hreflang x-default : la page pour tous les autres
- Liens retour : la règle la plus souvent enfreinte
- Trois façons d’ajouter une balise hreflang à une page
- Une page sans traduction n’a pas besoin d’une fausse traduction
- Hreflang dans WordPress : ce que WPML et Polylang configurent pour vous
- Comment vérifier les balises hreflang de votre site
- Faire vérifier les bases techniques de votre site
Les balises hreflang indiquent à Google quelle version d’une page afficher dans les résultats de recherche, selon la langue et la région. Pour une entreprise qui vend au Canada et aux États-Unis, cela peut représenter jusqu’à quatre codes : en-CA, en-US, fr-CA, es-US.
Sans balise, ou avec une balise erronée, Google décide seul — une personne qui cherche à Vancouver peut se retrouver avec la page destinée aux États-Unis seulement, une personne hispanophone à Miami avec la page en anglais, même si une version espagnole existe. Les codes sont simples. La difficulté, c’est de faire pointer correctement chaque page vers les autres : c’est là que beaucoup de sites échouent, et que la balise perd sa valeur.
Ce que signifient vraiment en-CA, en-US, fr-CA et es-US
La documentation de Google explique elle-même le format : « Le premier code de l’attribut hreflang est le code de langue (au format ISO 639-1), suivi d’un second code facultatif qui représente le code régional (au format ISO 3166-1 Alpha 2) d’une autre URL alternative. » La langue vient en premier, la région en second, reliées par un trait d’union.
Pour le Canada et les États-Unis, cela donne quatre paires fonctionnelles : en-CA (anglais, Canada), en-US (anglais, États-Unis), fr-CA (français, Canada), es-US (espagnol, États-Unis) — ce que Google Search Central appelle des versions localisées.
La moitié « région » est facultative : si une seule page en anglais dessert les deux pays, le simple en est valide — Google précise que « vous pouvez spécifier un code de langue seul ». Des pages en-CA et en-US distinctes ne se justifient que si elles diffèrent vraiment — prix, livraison, orthographe. L’inverse ne fonctionne pas : « Vous ne pouvez pas spécifier le code de pays seul. » Le premier code est toujours lu comme une langue, donc une balise hreflang="ca" ne désigne pas le Canada.
Hreflang x-default : la page pour tous les autres
Une cinquième valeur couvre les visiteurs qu’aucune des quatre paires ne couvre — quelqu’un qui navigue en allemand, ou dont les réglages de langue ne correspondent à aucune paire déjà construite sur le site. Définition de Google : « La valeur réservée x-default est utilisée quand aucune autre langue ou région ne correspond aux paramètres de navigateur de l’utilisateur. »
Elle est recommandée « pour spécifier la page de substitution pour les utilisateurs dont les paramètres linguistiques ne correspondent à aucune des versions localisées de votre site » — en pratique, un sélecteur de langue ou votre version anglaise principale.
Liens retour : la règle la plus souvent enfreinte
Hreflang n’est pas une étiquette à sens unique — c’est une paire de pointeurs, et la règle de Google est explicite : « Si la page X renvoie vers la page Y, cette dernière doit également renvoyer vers la page X. Si ce n’est pas le cas pour toutes les pages qui utilisent des annotations hreflang, ces annotations peuvent être ignorées ou mal interprétées. »
En pratique, c’est là que les sites modifiés à la main échouent : quelqu’un ajoute une nouvelle page en anglais, met à jour sa liste hreflang, et oublie d’ajouter le lien correspondant sur la page jumelle en français. Google écarte alors cette paire : si deux pages ne pointent pas l’une vers l’autre, leurs balises sont ignorées.
Les paires qui pointent bien l’une vers l’autre continuent de fonctionner — c’est pourquoi l’oubli passe inaperçu : rien ne casse à l’échelle du site, une seule page perd discrètement sa jumelle dans les résultats de recherche.
Trois façons d’ajouter une balise hreflang à une page
Google reconnaît trois implémentations : des balises HTML <link> dans le <head>, un en-tête HTTP, ou une entrée dans le sitemap XML. Les balises HTML sont la méthode par défaut pour une page web ordinaire ; l’en-tête HTTP couvre les fichiers qui n’ont pas du tout d’élément <head> ; la méthode du sitemap garde le balisage hors de la page elle-même, ce qui compte davantage sur un grand catalogue que sur un site de cinq pages.
Sur WordPress, la méthode HTML est ce qu’une extension multilingue génère pour vous. Pour une page donnée, le jeu complet de balises ressemble à ceci :
<link rel="alternate" hreflang="en-CA" href="https://example.com/en-ca/page/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/page/" />
<link rel="alternate" hreflang="fr-CA" href="https://example.com/fr-ca/page/" />
<link rel="alternate" hreflang="es-US" href="https://example.com/es-us/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en-us/page/" />Remarquez que la page se liste aussi elle-même. Ce n’est pas redondant : la règle de Google est formelle : « Chaque version linguistique doit se référencer elle-même et indiquer aussi toutes les autres versions linguistiques de la page. »
Une page sans traduction n’a pas besoin d’une fausse traduction
Toutes les pages n’ont pas à porter les quatre codes. Prenons une page de service qui n’existe qu’en anglais : il n’y a pas de version française vers laquelle pointer, donc son jeu hreflang se limite à en et x-default — ou à aucune balise hreflang, puisqu’il n’y a aucune version alternative vers laquelle pointer. Les deux sont corrects, ce n’est pas un oubli.
L’erreur serait d’afficher une balise hreflang fr-CA qui pointe vers une page qui n’existe pas, ou vers une page française portant sur un tout autre sujet. Une page sans traduction ne doit porter aucune balise pour la langue qu’elle n’a pas — et aucune page portant sur un autre sujet ne doit la lister comme sa version alternative.
Hreflang dans WordPress : ce que WPML et Polylang configurent pour vous
Sur WordPress, c’est habituellement l’extension multilingue qui s’en charge, et non une saisie manuelle. Documentation de WPML : « WPML automatically inserts hreflang tags to your pages, and updates them as you make changes to your website » (WPML insère automatiquement des balises hreflang dans vos pages, et les met à jour à chaque changement sur votre site) — ce qui règle le problème des liens retour vu plus haut, l’extension réécrivant les deux côtés dès qu’une des pages change.
Polylang fait de même : « Polylang automatically uses the hreflang HTML tag attributes on your multilingual site so you don’t need to do anything! » (Polylang utilise automatiquement les attributs de balise HTML hreflang sur votre site multilingue, vous n’avez rien à faire !). Une limite mérite d’être connue avant de s’y fier : « Polylang generates a x-default hreflang only for the homepage, as recommended by Google. » (Polylang ne génère un hreflang x-default que pour la page d’accueil, comme le recommande Google).
Toutes les autres pages d’un site sous Polylang n’ont pas de valeur x-default. Comme x-default est facultatif, ce n’est pas une erreur — seulement une valeur de repli absente sur les pages internes. Le « comme le recommande Google » est la lecture de Polylang : selon Google, la valeur peut servir sur n’importe quelle page, mais « elle a été conçue pour les pages de sélection de langue et c’est donc là qu’elle fonctionnera le mieux ».
3my.org tourne sous WPML, et les balises hreflang de ses pages sont générées par l’extension, pas saisies à la main. La comparaison des quatre principales extensions se trouve dans notre comparatif de WPML, Polylang, TranslatePress et Weglot ; ce que coûte une deuxième langue dans l’ensemble est couvert dans ce que coûte vraiment un site multilingue.
Comment vérifier les balises hreflang de votre site
Faites un clic droit sur n’importe quelle page, choisissez « Afficher le code source de la page », et cherchez hreflang. Vérifiez que chaque version linguistique est listée, que les URL mènent directement à la page, sans chaîne de redirections, et que la page où vous êtes apparaît aussi dans la liste de chacune de ses homologues.
Pendant que vous êtes dans le code source, cherchez aussi rel="canonical". Chaque version linguistique doit se désigner elle-même comme page canonique ; une page française dont l’URL canonique pointe vers la page anglaise envoie à Google deux signaux contradictoires. La consigne de Google, dans son guide des URL canoniques : « Si vous utilisez des éléments hreflang, veillez à spécifier une page canonique dans la même langue, ou dans la langue de substitution la plus pertinente s’il n’existe pas de page canonique pour la même langue. »
Sur WordPress, une URL canonique erronée se corrige dans les réglages de l’extension SEO ou de l’extension multilingue, pas en collant des balises dans le thème. Pour tester une page en ligne au-delà de la lecture du code source, la documentation de Google renvoie à des outils externes, comme l’outil de test des balises hreflang de Merkle SEO.
Une chose à garder en tête pendant cette vérification : « Google n’utilise pas hreflang ni l’attribut HTML lang pour détecter la langue d’une page. » Il s’appuie sur des algorithmes.
La balise oriente les visiteurs entre des versions déjà correctement construites — elle ne corrige pas une page rédigée dans la mauvaise langue, et ne suffit pas, à elle seule, à faire monter une traduction trop mince dans les résultats.
C’est un problème distinct, traité dans pourquoi une page traduite ne se classe pas. Hreflang n’est qu’une vérification parmi d’autres dans un audit technique ; le reste de la liste se trouve dans notre liste de vérification pour l’audit SEO technique.
Faire vérifier les bases techniques de votre site
Notre audit SEO gratuit passe en revue les bases techniques d’un site — vitesse, mise en page mobile, erreurs d’indexation, pages qui se concurrencent entre elles — et se termine par un ordre clair des correctifs à apporter en premier.
