Hreflang : le guide sans erreurs

La balise hreflang indique à Google qu’une page existe en plusieurs versions linguistiques ou régionales, et laquelle afficher à quel internaute. Sur un site multilingue, elle aide Google à montrer à un visiteur belge la version belge d’une page plutôt que la canadienne. Mal posée, elle peut être ignorée sans que la Search Console le signale.

Nous avons travaillé les attributs hreflang et les balises canoniques pour Hager, soit 50 à 60 sites dans une vingtaine de pays (cas client Hager). Pour ce guide, nous avons aussi relevé en octobre 2026 les annotations des sites de 25 groupes du CAC 40 : leurs écarts illustrent les erreurs décrites plus bas.

Le hreflang n’est qu’un maillon d’une stratégie de référencement international, avec le choix des marchés, la structure d’URL et l’adaptation des contenus.

Hreflang, c’est quoi exactement ?

Le hreflang est un attribut HTML qui déclare les versions linguistiques et régionales d’une page. Basé sur deux normes ISO (code langue 639-1, code pays 3166-1 en option) au format langue-pays, il indique à Google quelle version servir selon la langue et le pays de l’internaute.

Google s’en sert pour afficher dans ses résultats la version linguistique ou régionale la plus adaptée. Il ne s’en sert pas pour deviner la langue d’une page : il la lit dans le contenu visible. Et il ne traite pas vos traductions comme des doublons, tant que le contenu principal de la page est traduit.

Un exemple de balise hreflang concret

Pour une page disponible en français (France), en anglais (Royaume-Uni) et en anglais (États-Unis), placez ces balises dans le <head> des trois versions et de la page désignée par x-default :

<link rel="alternate" hreflang="fr-FR" href="https://exemple.com/fr/" />
<link rel="alternate" hreflang="en-GB" href="https://exemple.com/en-gb/" />
<link rel="alternate" hreflang="en-US" href="https://exemple.com/en-us/" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en-us/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />

Chaque version porte le même jeu de balises, elle-même comprise, avec des adresses complètes. Le code langue seul suffit si vous ne visez pas un pays précis (hreflang="fr"). Ajoutez le pays pour distinguer des variantes d’une même langue, comme fr-BE pour la Belgique francophone ou en-CA pour le Canada anglophone.

La ligne en sert de page générique pour les autres anglophones, comme Google le conseille dès qu’une langue a des variantes régionales. Elle peut pointer, comme ici, vers une version régionale existante.

Quelle structure d’URL pour vos versions internationales ?

Google compare quatre structures et déconseille les paramètres d’URL. Restent le sous-répertoire, le domaine national (ccTLD) et le sous-domaine. Nous recommandons le sous-répertoire par défaut : il est simple à mettre en place et demande peu de maintenance, avec un seul hébergeur. Tranchez avant toute annotation, car changer ensuite impose une migration.

• Sous-répertoire (exemple.com/fr/) : notre choix par défaut. Google y voit une mise en œuvre facile et peu de maintenance sur un même hébergeur. En contrepartie, l’URL seule ne dit pas quel pays la page vise.
• Domaine national (exemple.fr, exemple.de) : un ciblage géographique clair selon Google, quel que soit l’emplacement du serveur. Il coûte plus cher, demande plus d’infrastructure et ne vise qu’un pays par domaine.
• Sous-domaine (fr.exemple.com) : simple à mettre en place, avec des serveurs possibles dans plusieurs pays. L’URL reste ambiguë : Google cite l’exemple de « de », qui peut désigner une langue ou un pays.

Quelle que soit la structure, Google donne trois consignes. Une URL distincte par langue, plutôt qu’un choix par cookie ou par les réglages du navigateur. Une seule langue par page, contenu et navigation compris. Et aucune redirection automatique selon la langue supposée de l’internaute : proposez plutôt des liens vers chaque version.

Google précise aussi qu’il ne tire pas l’audience visée d’un sous-domaine comme en-gb ou de : c’est à vous de la déclarer, par les annotations.

Que révèle notre relevé sur 25 groupes du CAC 40 ?

Sur les 22 sites de groupe lus en octobre 2026, 18 portent des annotations dans le code de l’accueil et s’y citent eux-mêmes, comme le demande Google. Quatre d’entre eux présentent au moins un écart : liens retour absents, canonique vers une autre adresse ou une autre langue, code « jp » et balises sorties du <head>.

Méthode. Nous avons pris les 25 sociétés que liste, par poids décroissant, la vue publique de la composition du CAC 40 publiée par Euronext (au 30 juin 2026), puis le site de groupe de chacune. Chrome, réglé en français, a suivi les redirections comme un internaute en France, avec au moins 6 secondes entre deux pages d’un même site.

Sur chaque accueil, nous avons lu les annotations du HTML servi, de l’en-tête HTTP et du DOM rendu, puis chaque version déclarée : lien retour, canonique et noindex. Une page refusée à notre outil, ou remplacée par un contrôle anti-robot, compte comme non mesurable et jamais comme une erreur du site.

Pour les quatre sites sans annotation à l’accueil, nous avons aussi lu les sitemaps que déclare leur robots.txt : tous pour trois groupes, deux sur 523 pour le quatrième.

Limites. Nous avons lu l’accueil et ses versions sur une seule journée d’octobre 2026, sans nous faire passer pour Googlebot : ce que reçoit Google peut différer. Sur 25 sites, ces chiffres décrivent des cas réels et ne mesurent pas une fréquence.

• Trois accueils sont restés non mesurables (refus ou contrôle anti-robot) ; 22 ont été lus.
• 18 accueils sur 22 portent leurs annotations dans le HTML servi. Aucun ne les ajoute seulement en JavaScript. Un seul y ajoute l’en-tête HTTP, qui ne déclare que son x-default.
• Les 4 autres n’en ont aucune dans leur code. Trois passent par leur sitemap XML. Deux y déclarent leurs versions, l’un sans y inscrire son accueil et l’autre accueil compris. Dans celui du troisième, chaque entrée ne désigne que sa propre adresse.
• Le quatrième redirige son accueil vers une page d’introduction, et les fichiers que listent ses sitemaps ont répondu en erreur à notre lecture.
• Les 18 accueils annotés se citent eux-mêmes à l’adresse exacte, et 10 déclarent un x-default.
• Un de ces 18 accueils ne déclare que lui-même, et sa canonique désigne une autre adresse, qui redirige vers lui.
• Sur 43 versions déclarées, 37 ont pu être lues : 35 renvoient à l’accueil à l’adresse exacte. Les deux autres sont des versions chinoises hébergées sur un domaine à part.
• Un site désigne la page anglaise comme canonique de son accueil français et de quatre autres versions.
• Un site écrit jp au lieu de ja pour sa version japonaise.
• Dans le sitemap d’un groupe, l’accueil se déclare en en-WW et cite me-ME et sq-KS. Ni WW ni KS ne figurent dans la norme ISO 3166-1, et « me » n’est pas un code de langue ISO 639-1 : Google n’accepte pas ces codes.
• Sur deux sites, Chrome range les annotations dans <body> : l’un à cause d’un <div> placé dans le <head>, l’autre parce que son framework envoie les métadonnées après </head>.
• Bilan des 18 accueils annotés : 12 sans écart sur ce que nous avons pu lire, 4 avec au moins un écart et 2 lus en partie seulement.

Notre lecture. Trois erreurs que nous cherchions n’apparaissent pas dans cet échantillon : adresses relatives, codes inversés comme us-en et séparateur « _ ». Les écarts relevés sont ailleurs : codes invalides (jp, en-WW), version hébergée sur un autre domaine, canonique qui désigne une autre URL et balises sorties du <head>. C’est là que nous regardons d’abord en audit.

Quelles erreurs font ignorer hreflang par Google ?

Google ignore les annotations entre deux pages qui ne se citent pas mutuellement, et range les codes de langue ou de région incorrects parmi les erreurs fréquentes. Deux réglages brouillent aussi le signal : une canonique qui désigne une autre langue et des balises placées hors du <head>. Notre relevé les illustre toutes.

1. Les liens retour non réciproques

Si la page A déclare la page B, la page B doit déclarer la page A. Sans ce lien retour, Google écrit que les annotations « peuvent être ignorées ou mal interprétées ». La règle protège votre site : un tiers ne peut pas se déclarer variante de vos pages sans que vous le confirmiez.

Google accepte un jeu partiel : si vous omettez certaines langues, il traite quand même les pages qui se citent entre elles. Nous contrôlons la réciprocité à l’adresse exacte, protocole, sous-domaine et barre oblique finale compris.

Dans notre relevé, les deux liens retour manquants concernent des versions chinoises hébergées hors du domaine principal. L’une ne porte aucune annotation. L’autre n’est atteinte qu’après une redirection vers un autre domaine, et ses annotations visent d’autres adresses que celles de l’accueil. Une version hébergée ailleurs mérite d’être contrôlée en premier.

2. La canonique qui désigne une autre langue

La balise canonique indique à Google l’URL à retenir parmi des pages similaires. Si votre page française désigne la version anglaise comme canonique, les deux signaux se contredisent : l’annotation présente la page comme la version à servir aux francophones, la canonique demande de retenir l’anglaise.

Google demande donc une canonique dans la même langue que la page ; en pratique, la canonique de chaque version pointe vers elle-même.

Un site du relevé fait l’inverse : son accueil français et quatre de ses versions désignent la page anglaise. Un autre accueil se déclare lui-même mais désigne comme canonique une adresse qui redirige vers lui.

Trois accueils et trois versions, enfin, n’indiquent aucune canonique ou laissent son adresse vide. Google recommande d’en indiquer une sans l’exiger : il choisit alors l’URL canonique.

3. Les codes de langue et de région invalides

Le format est langue-pays : un code de langue ISO 639-1, suivi en option d’un code de pays ISO 3166-1 alpha-2, séparés par un tiret. La casse ne compte pas. Un code de pays seul ne suffit pas : be désigne le biélorusse et non la Belgique. Pour le chinois, Google accepte les codes d’écriture zh-Hans et zh-Hant.

Deux cas méritent attention. es-419 (espagnol d’Amérique latine) n’est pas accepté. Avec un code de région réservé à un autre usage, comme UK, EU ou UN, Google ignore cette partie de l’annotation. Une version en-UK ne cible donc pas le Royaume-Uni, dont le code est GB.

Dans notre relevé, un site déclare jp pour sa version japonaise. C’est le code du Japon comme pays ; le japonais s’écrit ja, et Google classe ce cas parmi les « codes de langue incorrects ».

4. Les balises sorties du <head>

Google demande des balises <link> placées dans un <head> bien formé, et conseille un validateur HTML en cas de doute. Le piège vient de l’analyse du HTML : une balise interdite dans le <head>, comme un <div>, le ferme aussitôt, et tout ce qui suit bascule dans <body>. Le code source paraît correct ; seul le DOM rendu le montre.

Deux sites du relevé sont dans ce cas. Sur le premier, un <div> vide placé dans le <head> fait passer dans <body> ses annotations, son titre et plusieurs scripts. Le second utilise Next.js : depuis sa version 15.2, ce framework peut envoyer les métadonnées dans <body> (« streaming metadata »).

Next.js affirme avoir vérifié que les robots qui exécutent JavaScript, comme Googlebot, interprètent correctement ces balises. La documentation de Google demande pourtant un <head> bien formé, et nous n’avons de preuve dans aucun sens. Dans le doute, gardez les annotations dans le <head> (réglage htmlLimitedBots de Next.js) ou passez par le sitemap XML.

Les autres réglages qui cassent l’annotation

• Une version en noindex : exclue de l’index, elle ne peut pas être servie.
• Une version bloquée par le robots.txt : Google ne peut pas lire son lien retour.
• Une adresse déclarée qui redirige : déclarez l’adresse finale, celle que la page désigne comme canonique.
• Un contenu qui change selon la langue du navigateur ou l’adresse IP : Googlebot explore surtout depuis les États-Unis, sans en-tête Accept-Language, et peut ne jamais voir certaines versions.

Erreurs hreflang et correction

Erreur observée	Effet	Correction
Lien retour manquant (A cite B, B ne cite pas A)	Google ignore les annotations entre ces deux pages	Chaque version cite toutes les autres et elle-même, aux mêmes adresses
Canonique vers une autre langue	La canonique contredit l’annotation	Canonique dans la même langue, en pratique la page elle-même
Code de région réservé (en-UK)	Google ignore la partie région	en-GB pour le Royaume-Uni
Code de langue inexistant (jp)	Code de langue incorrect selon Google	ja pour le japonais
Balises sorties du <head>	Hors des conditions posées par Google	Retirer l’élément qui ferme le <head>, ou passer au sitemap
Adresses relatives ou sans protocole	Hors des conditions posées par Google	Adresses complètes, protocole compris
Cible en noindex ou bloquée par le robots.txt	Version non servie ou lien retour illisible	Ne déclarer que des pages indexables et explorables
Cible qui redirige	Adresse déclarée différente de la page servie	Déclarer l’adresse finale
x-default absent	Aucune page de repli désignée (recommandée, non obligatoire)	Désigner le sélecteur de langue ou la version la plus internationale

À quoi sert le x-default ?

La valeur x-default désigne la page à servir quand aucune version déclarée ne correspond à la langue de l’internaute. Google la recommande sans l’imposer : elle vaut pour n’importe quelle page, mais elle a été conçue pour les sélecteurs de langue. Dans notre relevé, 10 accueils sur 18 en déclarent une.

Ces 10 accueils la font pointer vers une version déjà déclarée avec un code de langue : l’anglaise dans 8 cas, la française dans 2. Google l’admet, puisqu’il accepte la valeur sur n’importe quelle page.

Notre conseil : désignez une page utile à un public que vous n’avez pas ciblé. Un sélecteur de langue convient le mieux ; à défaut, prenez la version la plus internationale du site. Sous WordPress, Polylang ne pose le x-default que sur une page d’accueil qui redirige automatiquement.

Quelle méthode d’implémentation choisir ?

Google accepte trois méthodes, équivalentes à ses yeux : les balises <link> dans le <head> des pages, le sitemap XML et l’en-tête HTTP. Notre règle de terrain : les balises pour un petit site, le sitemap pour un catalogue de milliers d’URL, et l’en-tête HTTP pour les fichiers PDF.

• Balises <link> dans le <head> : lisibles page par page, chaque version portant le jeu complet. Sur des milliers d’URL en plusieurs langues, chaque page ajoutée oblige à mettre à jour toutes ses versions.
• Sitemap XML : notre choix pour un catalogue. Les annotations sortent du code des pages et se contrôlent d’un seul endroit. Chaque <url> liste toutes les versions, elle-même comprise, par des éléments <xhtml:link rel="alternate" hreflang="…">.
• En-tête HTTP : utile, selon Google, pour un fichier non HTML comme un PDF, où l’on ne peut pas insérer de balise <link>.

Dans un sitemap, chacune des quatre adresses de l’exemple a son entrée <url>, avec les cinq mêmes liens. La première :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://exemple.com/fr/</loc>
    <xhtml:link rel="alternate" hreflang="fr-FR" href="https://exemple.com/fr/" />
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://exemple.com/en-gb/" />
    <xhtml:link rel="alternate" hreflang="en-US" href="https://exemple.com/en-us/" />
    <xhtml:link rel="alternate" hreflang="en" href="https://exemple.com/en-us/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://exemple.com/" />
  </url>
</urlset>

L’en-tête HTTP d’un PDF disponible en deux langues, identique sur les deux versions :

Link: <https://exemple.com/fr/guide.pdf>; rel="alternate"; hreflang="fr", <https://exemple.com/en/guide.pdf>; rel="alternate"; hreflang="en"

Combiner les méthodes n’apporte rien : selon Google, les utiliser ensemble ne présente aucun avantage et complique la gestion. Sur les accueils lus, un seul site combine deux méthodes, avec un x-default dans l’en-tête HTTP et le jeu complet dans le HTML. Nous n’avons pas lu les sitemaps des sites annotés.

Sur WordPress, une extension multilingue pose les annotations. Polylang les ajoute automatiquement ; WPML les insère et les met à jour à chaque modification. Vérifiez quand même le rendu : un composant ajouté au <head> peut le fermer avant elles.

Faut-il encore utiliser hreflang ?

Oui, dès qu’une page existe en plusieurs versions linguistiques ou régionales. Google reconnaît seul la langue d’un texte, mais il recommande de lui signaler ces variantes pour orienter chaque internaute vers la bonne. Le cas typique : deux pages en français destinées l’une à la France, l’autre à la Belgique.

Google cite trois situations où ces déclarations aident : un gabarit traduit autour d’un contenu resté dans sa langue, un contenu identique à quelques détails régionaux près, ou un site traduit en entier.

Le rapport « Ciblage international » de la Search Console est en revanche obsolète. Le 24 août 2022, le journal des mises à jour de la documentation consigne le retrait des références au rapport et indique que les recommandations sur les versions localisées restent pertinentes. Selon l’aide Search Console, Google « continuera à prendre en charge et à utiliser les balises hreflang ».

Pour situer le pays visé, Google s’appuie aussi sur d’autres signaux : domaine national, adresses et numéros de téléphone locaux, langue et devise du pays, liens venus de sites locaux ou fiche d’établissement. Il ignore les balises meta de localisation comme geo.position.

Un site publié dans une seule langue, sans variante régionale, n’a pas besoin de hreflang : l’annotation n’apporte rien à son référencement naturel. Dans notre relevé, le sitemap d’un groupe annote ses 860 entrées sans déclarer de variante : chacune ne renvoie qu’à elle-même, en en-US ou, pour 20 d’entre elles, avec un code vide.

Comment diagnostiquer une implémentation cassée ?

Commencez par un crawl qui extrait toutes les annotations et signale les liens retour manquants, les codes invalides et les cibles en erreur. Contrôlez ensuite quelques pages clés dans le DOM rendu, puis dans l’inspection d’URL de la Search Console, qui montre quelle version Google a retenue comme canonique.

Un crawler comme Screaming Frog, celui que nous utilisons en audit technique, extrait les annotations de toutes les pages et repère les incohérences d’un site entier. Sans rapport dédié dans la Search Console, le crawl donne cette vue d’ensemble.

Pour savoir quelle version Google retient, inspectez la version indexée : le champ « URL canonique sélectionnée par Google » le dit. Le test en ligne ne peut pas prédire quelle version sera retenue comme canonique.

Vérifiez le DOM rendu, et pas seulement le code source. Une annotation ajoutée en JavaScript n’existe que si le rendu aboutit, et une balise qu’un élément interdit fait sortir du <head> ne paraît déplacée que là. Un problème de SEO JavaScript peut vider vos annotations de leur portée sans que le code source paraisse fautif.

Quand une version linguistique disparaît des impressions sans raison de contenu, contrôlez d’abord sa canonique : c’est notre premier réflexe.

Lang et hreflang : deux rôles distincts

L’attribut lang (<html lang="fr">) déclare la langue de la page courante pour le navigateur et les lecteurs d’écran. Il ne dit rien des autres versions. L’attribut hreflang déclare aux moteurs de recherche chaque version de la page, elle-même comprise, avec sa langue et, s’il y a lieu, sa région.

Google n’utilise ni l’un ni l’autre pour détecter la langue d’une page : il lit le contenu visible. Gardez les deux justes, lang pour l’accessibilité et hreflang pour orienter Google entre vos versions. Dans notre relevé, une version chinoise déclare lang="cn" : « cn » est un code de pays et ne désigne aucune langue.

FAQ hreflang

C’est quoi hreflang et à quoi ça sert ?

Le hreflang est un attribut HTML qui déclare aux moteurs de recherche les versions linguistiques et régionales d’une page. Google s’en sert pour afficher à chaque internaute la version de sa langue et de son pays. Vos traductions ne sont pas des doublons pour Google tant que leur contenu principal est traduit.

Qu’est-ce qu’un exemple de balise hreflang ?

Pour une page française et sa version britannique : <link rel="alternate" hreflang="fr-FR" href="https://exemple.com/fr/" /> et <link rel="alternate" hreflang="en-GB" href="https://exemple.com/en-gb/" />. Chaque version liste toutes les autres et elle-même, à l’adresse exacte. Sans lien retour, Google ignore les annotations entre les deux pages.

Quelle est la différence entre lang et hreflang ?

L’attribut lang déclare la langue de la page courante pour le navigateur et l’accessibilité. Le hreflang déclare aux moteurs de recherche toutes les versions de la page, elle-même comprise, avec leur langue et, s’il y a lieu, leur région. Google n’utilise ni l’un ni l’autre pour détecter la langue d’un texte.

Comment implémenter hreflang correctement ?

Choisissez une méthode : balises <link> dans le <head>, sitemap XML, ou en-tête HTTP pour les PDF. Déclarez sur chaque version toutes les versions, elle-même comprise, avec des liens retour exacts. Ajoutez un x-default si possible, et gardez la canonique de chaque version dans sa langue.

Comment déclarer hreflang dans un sitemap XML ?

Déclarez l’espace de noms xmlns:xhtml="http://www.w3.org/1999/xhtml", puis créez un élément <url> par version. Chacun liste toutes les versions, lui compris, par des éléments <xhtml:link rel="alternate" hreflang="…">. Trois versions donnent trois entrées <url>, chacune avec les trois mêmes liens.

Comment savoir si mon hreflang fonctionne ?

Crawlez le site avec un outil comme Screaming Frog pour repérer les liens retour manquants, les codes invalides et les adresses en erreur. La Search Console n’a plus de rapport hreflang dédié : inspectez la version indexée des pages clés. Si une version disparaît des impressions, vérifiez d’abord sa canonique.

Outils pour poser et vérifier le hreflang

Aucun outil ne remplace une architecture propre. Ceux que nous utilisons, ou que Google cite :

• Screaming Frog SEO Spider : crawl complet qui extrait les annotations, repère les liens retour manquants et les codes invalides. C’est notre outil de contrôle à l’échelle d’un site.
• Inspection d’URL de la Search Console : la version indexée montre l’URL canonique retenue par Google, page par page.
• Outils de développement du navigateur : l’onglet Éléments montre si les annotations sont restées dans le <head>.
• Outils cités par Google : le générateur de balises hreflang d’Aleyda Solis, et le testeur de Merkle (TechnicalSEO.com), qui valide une page à la fois. Google précise qu’il ne les gère ni ne les vérifie.
• Documentation de Google Search Central : le guide des versions localisées, révisé en septembre 2026, fait foi pour la syntaxe.

En résumé

Le hreflang aide Google à montrer la bonne version de chaque page sur chaque marché. Il tient à quatre conditions : des liens retour exacts, aucune canonique vers une autre langue, des codes ISO valides et des annotations lisibles dans le <head>, le sitemap ou l’en-tête HTTP.

Sur les 18 accueils annotés, les adresses sont absolues et chaque accueil se cite lui-même. Les écarts du relevé viennent de codes invalides, de versions hébergées ailleurs, de balises sorties du <head> et de canoniques qui pointent vers une autre URL.

Sources

• Google Search Central : Versions localisées de vos pages (révision de septembre 2026), Gérer les sites multirégionaux et multilingues (décembre 2025) et Spécifier une URL canonique (juillet 2026).
• Aide Search Console : Le rapport sur le ciblage international est obsolète et Outil d’inspection d’URL ; journal des mises à jour de la documentation, entrée du 24 août 2022.
• Euronext : composition du CAC 40, vue publique au 30 juin 2026.
• Documentation de Next.js (streaming metadata) et de WPML ; article de Polylang sur hreflang (février 2023, mis à jour en avril 2026).
• Relevé Getknown d’octobre 2026 : accueils et versions déclarées des sites de 25 groupes, lus dans Chrome, et sitemaps des quatre groupes sans annotation à l’accueil.

Vous préparez un déploiement international ou vous soupçonnez que vos balises hreflang sont ignorées ? Parlons de votre projet international et de son diagnostic technique.

Article rédigé par Yonel Sasson, Getknown, agence SEO et GEO.