Langues

Guide : Hreflang

Les hreflang, les trois façons de les implémenter, les règles de réciprocité et d’auto-référence, les codes de langue et de région valides, ainsi que l’audit des clusters à grande échelle.

Première publication : 25 juin 2026 · Dernière mise à jour : 8 août 2026 · Advanced
Langues
AIRédigé parAI v2
1 indice probant sur cette page

Hreflang indique aux moteurs de recherche quelle version linguistique ou régionale d’une page montrer à un utilisateur. Déclarez-le de l’une des trois façons — balises dans le head HTML, en-têtes HTTP ou sitemap XML — avec un code de langue ISO 639-1 et, éventuellement, un code de région ISO 3166-1 alpha-2. Il ne fonctionne que comme un cluster réciproque : chaque page doit pointer vers elle-même et vers tous ses alternates ; si un lien retour manque, Google peut ignorer la paire. C’est un indice, pas une directive : un hreflang incorrect est ignoré, pas pénalisé. Le système est aussi fragile : dans mon étude de 374 756 domaines utilisant hreflang, plus de 67 % avaient au moins un problème. Bing l’utilise beaucoup moins (content-language est un signal plus fort chez lui). Ce hub présente l’ensemble du sujet et renvoie vers les approfondissements.

TL;DR — Hreflang est un signal de cluster réciproque : chaque page se liste elle-même et liste tous ses alternates, et un lien retour manquant annule la paire. Déclarez-le d’une seule façon — balises HTML head, en-têtes HTTP Link (PDF) ou sitemap XML (meilleur à grande échelle). Les codes combinent une langue ISO 639-1 et une région ISO 3166-1 alpha-2 ; en-UK est incorrect, il faut en-GB. C’est un indice, pas une directive (Mueller) : un hreflang incorrect est ignoré, pas pénalisé, et Google peut le remplacer pour des raisons de consolidation dans une même langue ou d’indexation. Les erreurs sont fréquentes : dans mon étude Ahrefs de 374 756 domaines, plus de 67 % avaient au moins un problème. Bing considère le signal comme beaucoup plus faible que content-language. Auditez visuellement les clusters plutôt que dans un tableur.

Hreflang est un cluster, pas une simple balise

Hreflang sits between one piece of content and the right version showing up for each market's search. Source : /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

A hreflang cluster is a bidirectional graph — one missing return link breaks just that pair. Source : /international-seo/hreflang/

© Patrick Stox LLC · CC BY 4.0 ·

Le modèle mental qui résout la plupart des confusions sur hreflang est le suivant : ce n’est pas une balise par page, mais un graphe bidirectionnel. L’exigence de Google est directe — « Each language version must list itself as well as all other language versions » (traduction) : chaque version linguistique doit se lister elle-même ainsi que toutes les autres versions linguistiques, et « If two pages don’t both point to each other, the tags will be ignored » (traduction) : si deux pages ne pointent pas toutes les deux l’une vers l’autre, les balises seront ignorées. Si la page X pointe vers Y mais que Y ne pointe pas vers X, cette arête est silencieusement supprimée. Une balise retour manquante peut faire ignorer ou mal interpréter les annotations concernées — mais Google indique qu’il peut encore traiter les paires qui sont correctement réciproques ; une relation cassée ne fait donc pas nécessairement tomber toutes les annotations d’un cluster plus grand.

Evidence for this claim Each hreflang set should include the page itself, use fully qualified URLs, and include return links; without reciprocity, the affected annotations may be ignored or misinterpreted. Scope: Google Search hreflang guidelines; the documentation does not say one missing return link invalidates every annotation in a cluster. Confidence: high · Verified: Google: Localized versions guidelines

Deux exigences non négociables en découlent :

  • Réciprocité. Chaque référence doit être renvoyée. C’est là que les implémentations cassent à grande échelle : dès qu’un template, un champ de CMS ou les pages d’une région se désynchronisent, les liens retour manquent.
  • Auto-référence. Chaque page se liste elle-même. Mueller la qualifie d’« optional—but good practice » (traduction) : facultative, mais recommandée. En pratique, une définition auto-référente est la façon la plus propre de garder des clusters cohérents et elle est signalée comme problème lorsqu’elle manque.

Les URL absolues et entièrement qualifiées sont également obligatoires : https://example.com/foo, jamais //example.com/foo ni /foo.

Trois méthodes — et leurs compromis

Google traite les balises HTML, les en-têtes HTTP et les sitemaps XML comme équivalents : il n’y a aucun bénéfice dans Search à en implémenter plusieurs. Choisissez une méthode par site selon ce que votre stack peut maintenir de façon fiable ; les mélanger invite les conflits.

  • Balises HTML <head>. C’est la méthode la plus simple et la plus visible. Son inconvénient : sur un site comportant des dizaines de locales, chaque page porte un gros bloc de balises <link>, ce qui alourdit le markup ; toute balise dans le <body> (HTML mal formé ou injection JavaScript) est invalide — hreflang ne compte que dans le <head> d’une page lorsque Google la rend et l’analyse.
  • En-têtes HTTP Link. C’est la seule option pour des ressources non HTML comme les PDF. Ils sont envoyés dans la réponse et n’alourdissent donc pas le document.
  • Sitemaps XML. C’est le bon choix à grande échelle. Les annotations vivent au même endroit (xhtml:link comme enfants de chaque <url>, avec l’espace de noms xmlns:xhtml="http://www.w3.org/1999/xhtml"), ce qui permet de régénérer tout le cluster depuis une base de données sans redéployer les pages. Il n’existe pas de méthode « plus rapide » : HTML et sitemaps sont résolus lors de l’exploration ; les sitemaps sont simplement bien plus faciles à contrôler, car le graphe entier peut être validé dans un fichier plutôt que d’explorer chaque page.
Evidence for this claim Google accepts hreflang in HTML, HTTP headers, or XML sitemaps and says the methods are equivalent from its perspective. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions

Liens réciproques à grande échelle — où ça casse

Sur un site de cinq locales, chaque page définit une matrice de références 5×5, régénérée chaque fois que vous ajoutez ou supprimez une locale, corrigez un slug ou migrez une URL. Les modes d’échec sont prévisibles :

  • Formats d’URL incohérents. Avec ou sans slash final, http contre https, www contre le domaine racine, chemins en majuscules contre minuscules : tout décalage entre l’URL du hreflang et celle que Google indexe réellement casse la correspondance du lien retour.
  • Cibles redirigées ou cassées. Une URL locale change, la redirection est mise en place, mais le hreflang pointe encore vers l’ancienne URL. Le cluster référence alors une 301 ou une 404.
  • Dérive des codes. jp au lieu de ja pour le japonais, des codes à trois lettres là où deux lettres sont requises, en-UK au lieu de en-GB. Les codes invalides sont ignorés.

Exemple de déploiement : le lien retour pointe vers l’URL d’hier

Supposons que la page produit britannique soit passée de /gb/shoes/ à /uk/shoes/. La page américaine n’a pas été régénérée et publie encore :

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/gb/shoes/" />

L’ancienne URL britannique redirige vers /uk/shoes/, tandis que la nouvelle page britannique renvoie vers la page américaine depuis son URL canonique finale. Cela laisse deux problèmes distincts : l’annotation américaine cible une redirection, et l’URL britannique finale n’est pas celle déclarée par la page américaine. Corrigez le générateur pour que les deux pages publient la définition complète avec les URL finales et indexables :

<link rel="alternate" hreflang="en-US" href="https://shop.example/us/shoes/" />
<link rel="alternate" hreflang="en-GB" href="https://shop.example/uk/shoes/" />

Validez les deux directions après le déploiement ; vérifier seulement la balise source américaine ferait manquer l’échec du lien retour. Il s’agit d’un cluster .example illustratif.

La leçon de mes présentations reste valable : automatisez la génération de hreflang depuis une source de vérité unique. À grande échelle, maintenir les balises à la main garantit la dégradation des liens retour.

Conflits de canonicalisation

Hreflang dépend de ce qui est indexé, pas de ce qui est canonicalisé — mais les deux interagissent, et une erreur casse les clusters :

  • Les canoniques auto-référentes sont le choix par défaut le plus sûr. Chaque version linguistique devrait se déclarer canonique. Si votre page espagnole déclare la page anglaise comme canonique, vous indiquez à Google que l’URL espagnole n’est pas celle à indexer ; pointer le hreflang vers une URL non canonique est une des erreurs les plus courantes.
  • Le cas limite de plusieurs pays dans une même langue. Lorsque, par exemple, les pages en-us et en-gb sont presque identiques, Google peut les regrouper et n’en indexer qu’une — tout en pouvant encore remplacer l’URL affichée dans le SERP par la version du bon pays grâce aux liens hreflang. Une URL « canonicalisée » peut donc encore apparaître pour le bon utilisateur. C’est une fonctionnalité, pas un bug, mais cela surprend lors d’un audit de couverture d’index.
  • noindex et robots.txt. Une page bloquée à l’indexation ne peut pas participer à un cluster : son hreflang ne peut pas être pris en compte, et pointer vers une URL bloquée ou en noindex casse le lien retour. Ne bloquez pas et ne mettez pas en noindex les variantes linguistiques que vous voulez diffuser.

C’est un indice, pas une directive

C’est le point essentiel. En mai 2025 sur Bluesky, John Mueller a répondu au cas de pages fr-be apparaissant dans les résultats fr malgré un hreflang correct : « hreflang doesn’t guarantee indexing, so it can also just be that not all variations are indexed » (traduction) : le hreflang ne garantit pas l’indexation ; il se peut simplement que toutes les variantes ne soient pas indexées, et « I suspect this is a ‘same language’ case where our systems just try to simplify things for sites » (traduction) : je soupçonne un cas de “même langue”, où nos systèmes essaient simplement de simplifier les choses pour les sites. Google se réserve le droit de remplacer le hreflang en cas de consolidation dans une même langue, de lacunes d’indexation ou selon ses propres choix de canonicalisation.

La recommandation de Google sur la canonicalisation est le revers de cette médaille : elle conseille de choisir une canonique dans la même langue que la page (ou le meilleur substitut disponible) et indique préférer les URL qui font partie d’un cluster hreflang réciproque complet aux URL similaires situées en dehors. C’est une préférence, pas une promesse : appartenir à un cluster correctement construit améliore les chances de voir la bonne URL sélectionnée, sans garantir l’indexation ni l’URL affichée.

Conséquence pratique : un hreflang incorrect est ignoré, pas pénalisé. Si votre cluster est cassé, Google revient à sa propre détection de langue et de région. Le coût est une occasion manquée (la mauvaise URL peut s’afficher pour certains utilisateurs), pas une baisse de classement. « Mon hreflang est incorrect » est donc rarement une urgence — mais il est aussi rarement utile.

Bing et les autres moteurs utilisent une pile différente

Hreflang est un signal Google (et Yandex). La pile de signaux de Bing est complètement différente. Fabrice Canel, Principal Program Manager chez Microsoft Bing, a déclaré clairement que « hreflang is indeed a far weaker signal than content-language at Bing » (traduction) : chez Bing, hreflang est effectivement un signal bien plus faible que content-language. Bing s’appuie sur l’en-tête HTTP ou la balise meta content-language, l’attribut <html lang="">, les liens entrants, la géographie des visiteurs et l’emplacement du serveur ou du ccTLD. Canel a conseillé de ne pas « duplicating URLs simply to have them tagged with these language-markets » (traduction) : dupliquer les URL uniquement pour les marquer avec ces marchés linguistiques dans la plupart des cas. Baidu ne prend pas du tout en charge hreflang : il s’appuie sur l’emplacement d’hébergement, l’enregistrement du domaine chinois, la licence ICP et la langue du contenu. Une configuration internationale robuste associe donc hreflang pour Google à un content-language et à html lang corrects pour les autres.

Le taux d’erreur raconte l’histoire

Over 67% of domains using hreflang have at least one issue — missing x-default is the top offender. Source : Data: Ahrefs

Lorsque j’ai mené la plus grande étude hreflang à ce jour chez Ahrefs — 374 756 domaines, près de 10 fois plus que toute étude précédente — plus de 67 % des domaines utilisant hreflang avaient au moins un problème. Répartition :

Problème% des domaines
x-default manquant56,3 %
Balises auto-référentes manquantes18,0 %
Pages cassées ou redirigées référencées16,9 %
Balises réciproques manquantes15,3 %
Cibles non canoniques8,0 %
Codes de langue ou de pays incorrects4,6 %
Attributs de langue incohérents3,2 %
Plusieurs pages pour une même langue2,5 %
Même page pour plusieurs langues2,5 %

Le résumé de mon étude reste valable : hreflang est complexe et difficile à mettre en œuvre correctement ; il peut casser de nombreuses façons différentes.

Auditer à grande échelle — visualisez le cluster, ne lisez pas un tableur

Visualisez votre propre cluster avec returntag :

  1. Collez dans l’outil l’URL d’une page, l’URL d’un sitemap ou une liste d’URL.
  2. Cliquez sur Validate cluster.
  3. Lisez la vue GRAPH — les liens retour cassés ou manquants ressortent par couleur de gravité — ou passez à MATRIX pour une vue ligne par ligne, puis exportez un CSV de corrections si vous devez le transmettre.

Les erreurs hreflang sont difficiles à voir parce qu’un problème de lien retour est une relation entre des pages, et qu’il est presque impossible de lire des relations dans les lignes d’un tableur. Ahrefs Site Audit a été le premier outil à rendre le cluster hreflang sous forme de graphe : ouvrez les détails d’URL d’une page et l’onglet Hreflangs dessine le cluster entier comme un réseau, avec les pages cassées et les liens manquants ou incorrects en rouge. Vous voyez ainsi d’un coup d’œil quel lien retour manque ou quel lien a été ajouté par erreur ; c’est bien plus facile à montrer à un responsable qu’un CSV. Site Audit effectue aussi les contrôles sous-jacents (annotation invalide, auto-référence manquante, plusieurs pages pour une langue, discordance hreflang/html lang, lien réciproque manquant, cible non canonique, cible cassée) qui correspondent directement à la liste d’erreurs de l’étude.

Au-delà :

  • Inspection d’URL dans GSC confirme comment une URL donnée a été explorée et indexée. Notez que l’ancien rapport de ciblage international a été supprimé le 22 septembre 2022 ; Google a dit qu’il « had little value for the ecosystem. » (traduction) : il avait peu de valeur pour l’écosystème. Les balises hreflang continuent de fonctionner ; seul le rapport a disparu.
  • Test manuel des SERP avec les paramètres &hl= (langue de l’hôte) et &gl= (géolocalisation) d’une URL de recherche Google permet de prévisualiser l’apparence des résultats pour une locale donnée.

Hreflang concerne aussi l’audit SEO technique

Même si le hreflang relève de l’International SEO, il apparaît dans presque tout audit SEO technique d’un site multilingue ou multirégional. Il se place aux côtés de la canonicalisation, de l’indexation et de l’accessibilité au crawl, et fait partie des éléments les plus susceptibles d’être cassés silencieusement. Si vous réalisez un audit technique sur un site qui possède plusieurs locales, le cluster hreflang doit figurer dans la checklist.

Où aller ensuite

Ce hub est la carte du sous-cluster hreflang. Le premier approfondissement :

  • x-default — la valeur de repli pour les utilisateurs dont la locale ne correspond à aucune balise explicite (sélecteur de pays ou page d’accueil mondiale). Ce n’est pas obligatoire, mais c’était l’omission la plus fréquente de mon étude (56,3 % des sites). Le sujet dédié explique quand l’utiliser, quand s’en passer et comment il interagit avec le reste du cluster.

Pour la stratégie plus large qu’il met en œuvre, consultez le pilier International SEO : hreflang est la couche technique d’une stratégie internationale et ne remplace pas une véritable localisation (intention, contenu et autorité locaux).

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.