La balise hreflang indique à Google quelle URL présente la même page dans une autre langue ou pour un autre pays. Chaque version cite toutes les versions, elle-même comprise, avec des URL complètes. La valeur est un code de langue, parfois suivi d'un code de pays : fr, fr-BE ou fr-CA. La valeur x-default désigne la page prévue pour tous les autres internautes, et la balise canonical de chaque version pointe vers une page dans la même langue, en général vers elle-même. Voici comment nous appliquons ces règles sur polytested.com, publié en quatre langues.

Ce que montre notre propre site

Voici l'en-tête de notre page « Notre méthode de test », tel que notre serveur l'envoie :

Code source de l'en-tête de polytested.com/fr/notre-methode : html lang fr, une balise canonical vers la page elle-même et cinq liens hreflang pour en, de, fr, es et x-default, avec les lignes fr et x-default surlignées
Notre propre page « Notre méthode de test », relevée le 17 octobre 2026.
  • La balise canonical de la page française pointe vers la page française elle-même, jamais vers la version anglaise.
  • Chaque langue publiée a son lien hreflang, y compris la page elle-même : en, de, fr et es.
  • x-default renvoie vers la page anglaise, notre version par défaut pour les lecteurs dont nous ne couvrons pas la langue.
  • Toutes les URL sont complètes, avec https:// et le domaine. Les slugs changent d'une langue à l'autre : /how-we-test, /de/so-testen-wir, /fr/notre-methode, /es/como-probamos. Hreflang relie des pages, pas des URL qui se ressemblent.

Next.js, le framework de notre site, écrit l'attribut sous la forme hrefLang, avec une majuscule. Ce n'est pas un problème : les noms d'attributs HTML ne tiennent pas compte de la casse, et Google n'en tient pas compte non plus dans les valeurs hreflang.

Hreflang, canonical et x-default : qui répond à quelle question ?

  • Canonical : parmi des pages en double dans une même langue, quelle URL est la principale ?
  • Hreflang : quelle URL présente cette page dans une autre langue ou pour une autre région ?
  • x-default : quelle URL montrer à un internaute dont la langue ne correspond à aucune version ?

En SEO, hreflang a un rôle précis : aider Google à montrer à chaque internaute la version dans sa langue ou pour son pays. Google peut parfois repérer seul les versions linguistiques d'une page, mais il préfère qu'on les lui indique, par exemple quand un même contenu en français vise la France, la Belgique et la Suisse avec quelques variantes régionales, ou quand le site est entièrement traduit.

Ces trois balises restent des indications. Google peut choisir une autre page canonique que la vôtre, et il détermine la langue d'une page à partir de son contenu visible, pas à partir de hreflang ni de l'attribut lang.

La page française doit-elle désigner la page anglaise comme canonique ?

Non. Quand vous utilisez hreflang, Google demande d'indiquer une page canonique dans la même langue, ou dans la langue de substitution la plus proche seulement s'il n'en existe pas dans la même langue. Une traduction n'est pas un doublon : selon Google, les versions localisées d'une page ne sont considérées comme des doublons que si le contenu principal n'est pas traduit. Si la page française désigne la page anglaise comme canonique, vous demandez à Google d'écarter la page française, et le lien hreflang vers elle ne relie plus rien.

Le conseil inverse circule encore. Il remonte à une recommandation de Google de 2010 pour les sites qui ne traduisaient que le modèle de leurs pages, et Google l'a retirée en 2011.

Deux autres points comptent :

  • Une balise par rôle. Pour choisir l'URL canonique, Google n'utilise pas une balise rel="canonical" qui porte aussi un attribut hreflang, lang, media ou type. Écrivez la balise canonical et les liens hreflang séparément, comme dans notre exemple.
  • Des versions régionales presque identiques. Si vos pages fr-FR et fr-BE ne diffèrent que par quelques mots, Google peut les regrouper sous une seule URL canonique. Hreflang ne garantit pas que chaque version soit indexée, et la Search Console présente ses données pour l'URL canonique. C'est la même chose si vous ne traduisez que les menus et laissez le contenu en anglais : ces pages sont des doublons. Traduisez le contenu ou ne publiez pas la version.

Les règles que Google vérifie

  1. Chaque version cite toutes les autres et elle-même. L'ensemble de liens est identique sur chaque version de la page.
  2. Les liens vont dans les deux sens. Si deux pages ne pointent pas l'une vers l'autre, Google ignore les balises de cette paire, mais il utilise les paires qui se répondent. Google explique cette règle : sans elle, le propriétaire d'un autre site pourrait présenter ses pages comme des versions des vôtres.
  3. Des URL complètes, protocole compris : https://polytested.com/fr/notre-methode, pas /fr/notre-methode. Les versions peuvent se trouver sur des domaines différents, par exemple un .fr et un .ch.
  4. Une seule méthode suffit. Balises dans l'en-tête HTML, en-têtes HTTP Link ou sitemap : les trois sont équivalentes pour Google, et les combiner n'apporte aucun avantage dans la recherche. L'en-tête HTTP sert surtout aux fichiers qui ne sont pas du HTML, comme les PDF.
  5. Uniquement des URL indexables et canoniques. Une page en noindex ne peut pas entrer dans le groupe. Visez les URL finales, pas des redirections ni des pages introuvables ; les outils d'exploration signalent ces cas comme des erreurs.
  6. Un en-tête propre. Les liens doivent se trouver dans un élément head bien formé. Google arrête de lire l'en-tête dès qu'il y trouve un élément qui n'y a pas sa place, comme une iframe ou une image : placez vos balises avant. Ne mélangez pas non plus hreflang et un autre attribut, comme media, dans une même balise link.

Sur un grand site, Google accepte d'omettre certaines langues sur certaines pages et traite quand même les pages qui se répondent. L'essentiel est de relier chaque nouvelle langue dans les deux sens à la langue d'origine. Son exemple : un site lancé en .fr qui ajoute des versions pour le Mexique (.mx) et l'Espagne (.es) doit d'abord relier chacune d'elles au site .fr, avant de relier les deux versions espagnoles entre elles.

fr, fr-FR, fr-BE, fr-CH ou fr-CA ?

La valeur se compose d'un code de langue de la norme ISO 639-1, puis, si besoin, d'un tiret et d'un code de pays de la norme ISO 3166-1 alpha-2. Google n'accepte que les codes de ces deux normes, et il ne déduit jamais la langue d'un code de pays.

Si vous avez une seule version française pour tous les francophones, fr suffit. C'est notre choix. Des versions par pays n'ont de sens que si le contenu change vraiment, comme l'explique la section suivante. Dans ce cas, chaque version reçoit son code :

Codes hreflang pour une page en français, selon le public visé
Public viséValeur hreflang
Tous les francophonesfr
Francefr-FR
Belgiquefr-BE
Suissefr-CH
Canada, Québec comprisfr-CA
Luxembourgfr-LU
Monacofr-MC

Si vous créez des versions par pays, gardez aussi une version générique fr. Quand plusieurs URL visent la même langue dans des pays différents, Google recommande une URL collectrice pour les internautes situés ailleurs, et cette URL peut être l'une de vos pages par pays. Elle porte alors deux liens, par exemple fr-FR et fr. Sans cette version, un francophone d'un pays que vous n'avez pas listé ne correspond à aucune de vos valeurs.

Dans un pays multilingue, la langue change et le pays reste. Google prend lui-même l'exemple de la Belgique : fr-BE, nl-BE et de-BE sont valides. La même logique donne fr-CH, de-CH et it-CH pour la Suisse, fr-CA et en-CA pour le Canada.

Il n'existe pas de code pour le Québec seul. Le registre IANA des sous-étiquettes de langue ne contient pas de région QC, et Google n'accepte que des codes de pays. Une page pour le Québec prend donc fr-CA.

Quand une version par pays vaut la peine

Nous l'avons vu, une page fr-BE qui ne diffère de la page fr-FR que par son étiquette n'apporte rien. Des versions séparées se justifient quand le contenu change vraiment :

  • Monnaie et prix. Selon la liste ISO 4217 publiée par SIX, on paie en euros en France, en Belgique, au Luxembourg et à Monaco, en francs suisses (CHF) en Suisse et en dollars canadiens (CAD) au Canada.
  • Vocabulaire. Selon le Dictionnaire de l'Académie française, « septante » s'emploie pour soixante-dix en Belgique et en Suisse romande. Les mots que les internautes tapent dans la recherche changent eux aussi d'un pays à l'autre ; nous expliquons comment choisir vos mots-clés SEO pour chaque marché.
  • Formats. Les logiciels n'écrivent pas une date ni une heure de la même façon à Paris, à Genève ou à Montréal, comme le montre le tableau ci-dessous.
  • Règles locales. Mentions légales, conditions de vente, livraison et retours dépendent du pays. Ce n'est pas un conseil juridique : vérifiez pour chaque pays ce que vous devez indiquer.
Monnaie et formats par défaut de Unicode CLDR 46 pour le 17 octobre 2026 à 15 h 30, relevés le 17 octobre 2026
CodeMonnaie du paysDate courteHeure
fr-FREUR17/10/202615:30
fr-BEEUR17/10/2615:30
fr-CHCHF17.10.2615:30
fr-CACAD2026-10-1715 h 30

Ce sont des réglages par défaut de logiciels, pas des règles officielles, mais ils montrent vite qu'une page pensée pour la France peut paraître étrangère à Montréal.

Le nom de domaine envoie aussi un signal. Google traite un domaine national comme .fr, .be, .ch ou .ca comme l'indice qu'un site vise un pays précis ; seule une courte liste d'extensions, comme .co ou .tv, est considérée comme générique. Si vous utilisez un .fr pour une version fr destinée à tous les francophones, hreflang dit « tous » et le domaine dit « France ». Nous comparons domaines nationaux, sous-domaines et sous-répertoires dans notre guide du SEO international.

Les erreurs de code les plus fréquentes

Beaucoup de valeurs fausses ont l'air plausibles, parce que plusieurs codes de pays francophones sont aussi des codes de langue, et le premier code est toujours une langue. La colonne du milieu reprend les noms qu'affichent les logiciels d'après Unicode CLDR 46, complétés par le registre IANA et la documentation de Google.

Valeurs hreflang fréquentes et ce qu'elles désignent vraiment, relevé le 17 octobre 2026
Valeur écriteCe qu'elle désigneÀ écrire
bele biélorussefr-BE
cale catalanfr-CA
chle chamorrofr-CH
lule luba-katangafr-LU
ca-FRle catalan pour la Francefr-CA pour viser le Canada
fr-QCQC n'est pas un code de paysfr-CA
fr_FRun format de locale logiciel, pas une étiquette de languefr-FR
fr-EUEU est un code réservé, sans effet chez Googlefr
en-UKUK n'est pas le code du Royaume-Unien-GB
es-419l'espagnol d'Amérique latine, non accepté par Googlees ou un code de pays comme es-MX
  • Le tiret bas vient des locales logicielles. Notre site écrit og:locale sous la forme fr_FR pour Open Graph, où ce format est le bon. Dans hreflang, il faut un tiret.
  • Les codes réservés comme EU, UN ou UK n'ont aucun effet dans la recherche Google : Google ignore cette partie de l'annotation.
  • La casse ne compte pas, l'ordre si. fr-be et fr-BE sont identiques pour Google, mais la langue vient toujours en premier, et un pays seul n'est jamais valide.

x-default : où le faire pointer

La valeur réservée x-default sert quand aucune langue ni région de votre liste ne correspond aux paramètres du navigateur de l'internaute. Google la recommande pour désigner cette page de secours. Lancée en 2013 pour les sélecteurs de langue et les pages d'accueil qui redirigent selon la localisation, elle fonctionne le mieux, selon Google, sur une page de choix de la langue. Elle peut aussi désigner simplement la version que vous considérez comme celle par défaut. Inutile d'ajouter un code de langue à x-default : selon Google, la langue de cette page importe peu, puisqu'elle vise justement les internautes dont la langue ne figure pas dans votre liste.

Google fait lui-même ce choix pour sa documentation : le 17 octobre 2026, la version française de sa page sur les versions localisées renvoyait x-default vers la page anglaise. Nous faisons pareil, la page anglaise sert aussi de x-default. Notre code n'ajoute x-default que si une version anglaise existe ; une page publiée seulement en allemand n'en a pas. Hreflang n'a pas non plus à couvrir tout le site : selon Google, annoter seulement une partie des pages ne pose pas de problème.

La ligne x-default figure sur chaque version, comme les autres liens, et sa cible doit répondre 200. Surtout, x-default ne remplace pas fr : il vise les internautes dont vous ne parlez pas la langue, alors qu'un francophone d'un pays non listé relève de votre version générique fr.

Pages pas encore traduites, pagination et filtres

Quand une traduction n'est pas publiée, son lien hreflang n'apparaît pas et son URL renvoie une erreur 404. Nous n'affichons jamais le texte anglais sous une adresse française : cette page serait un doublon de la page anglaise, et un lien hreflang vers elle viserait la mauvaise langue. Le lien apparaît dès que la traduction est publiée. En attendant, les visiteurs peuvent utiliser la traduction de leur navigateur, qui ne crée pas de version linguistique aux yeux de Google.

Ce guide en est un exemple. Le 17 octobre 2026, avant la publication de cette version française, l'en-tête de la version anglaise ne citait que l'anglais, l'allemand et x-default :

polytested.com/blog/hreflang-canonical-tags-x-default
<link rel="canonical" href="https://polytested.com/blog/hreflang-canonical-tags-x-default"/>
<link rel="alternate" hrefLang="en" href="https://polytested.com/blog/hreflang-canonical-tags-x-default"/>
<link rel="alternate" hrefLang="de" href="https://polytested.com/de/blog/hreflang-x-default-canonical-dach"/>
<link rel="alternate" hrefLang="x-default" href="https://polytested.com/blog/hreflang-canonical-tags-x-default"/>

La deuxième page d'une liste d'articles ne contient pas les mêmes articles que la deuxième page dans une autre langue. Nos pages de liste paginées ont donc une balise canonical vers elles-mêmes et aucun lien hreflang. Les vues filtrées d'une liste sont en noindex, follow : elles n'ajoutent pas de pages à l'index, mais les liens qu'elles contiennent sont suivis.

La balise hreflang dans le sitemap

Chaque langue a son propre sitemap, et chaque entrée répète les liens de l'en-tête de la page. Voici l'entrée de notre page « Notre méthode de test » dans le sitemap français, relevée le 17 octobre 2026. Nous avons seulement ajouté des retours à la ligne :

sitemap-fr.xml
<url>
  <loc>https://polytested.com/fr/notre-methode</loc>
  <lastmod>2026-10-13</lastmod>
  <xhtml:link rel="alternate" hreflang="en" href="https://polytested.com/how-we-test"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://polytested.com/de/so-testen-wir"/>
  <xhtml:link rel="alternate" hreflang="fr" href="https://polytested.com/fr/notre-methode"/>
  <xhtml:link rel="alternate" hreflang="es" href="https://polytested.com/es/como-probamos"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://polytested.com/how-we-test"/>
</url>

Comme Google le demande, le fichier déclare l'espace de noms xhtml, et chaque URL a son propre élément url avec la liste complète, page elle-même comprise. L'ordre des liens n'a pas d'importance, et ces liens ne comptent pas dans la limite d'URL d'un sitemap.

Chez nous, l'en-tête et le sitemap sont produits par la même fonction, à partir de la même liste de traductions publiées : ils ne peuvent pas se contredire. Si vous utilisez les deux méthodes, gardez une seule source pour les deux.

Vérifier ses balises hreflang

Le rapport sur le ciblage international de la Search Console n'existe plus, mais Google indique qu'il continue à prendre en charge et à utiliser les balises hreflang. Pour vérifier votre configuration :

  • L'outil d'inspection d'URL de la Search Console affiche l'« URL canonique déclarée par l'utilisateur » et l'« URL canonique sélectionnée par Google ». Si elles diffèrent pour une page traduite, regardez d'abord sa balise canonical.
  • Un outil d'exploration contrôle les liens de retour, les codes et les cibles qui redirigent, renvoient une erreur 404 ou sont en noindex. Site Audit de Semrush propose un rapport consacré au SEO international, et Screaming Frog signale les liens hreflang vers des URL qui ne répondent pas 200.
  • Les générateurs conviennent pour quelques pages statiques. Google cite le générateur de balises hreflang d'Aleyda Solis et l'outil de test de Merkle, en précisant qu'il ne les gère ni ne les vérifie. Avec un CMS, générez plutôt les balises à partir de vos données.
  • Le code source de chaque version, avec Ctrl+U dans la plupart des navigateurs, et pas seulement celui de la page par laquelle vous avez commencé. La plupart des groupes cassés ont un lien de retour manquant sur la page que personne n'a regardée.

Et Bing ? Bing a déjà qualifié hreflang de signal bien plus faible que la langue déclarée par content-language, mais ses conseils publiés en décembre 2025 recommandent hreflang pour cibler une langue ou une région. Déclarez donc aussi la langue de chaque page avec l'attribut lang de l'élément html et, si vous le pouvez, avec un en-tête HTTP Content-Language. Le W3C déconseille d'utiliser une balise meta http-equiv pour déclarer la langue.

Liste de contrôle

  1. Chaque version se désigne elle-même comme canonique.
  2. Chaque version cite toutes les autres et elle-même, avec des URL complètes.
  3. Tous les liens vont dans les deux sens.
  4. Les codes suivent l'ordre langue-pays : fr, fr-BE, fr-CH, fr-CA. Jamais be, ch, fr-QC ni fr_FR.
  5. Avec des versions par pays, une version générique fr existe en plus.
  6. x-default pointe vers votre version par défaut ou vers une page de choix de la langue.
  7. Hreflang ne vise que des pages indexables qui répondent 200.
  8. Pas de redirection automatique selon la langue supposée du visiteur. Google la déconseille : Googlebot explore surtout depuis les États-Unis et n'envoie pas d'en-tête Accept-Language.
  9. L'attribut lang de l'élément html correspond à la langue du texte.
  10. Après chaque changement de langue, de domaine ou d'extension, le code source a été revérifié.

Hreflang relie les versions, rien de plus. Chaque version doit encore répondre à ce que l'on cherche dans son propre marché.