La balise hreflang indique aux moteurs de recherche qu’une page existe en plusieurs versions linguistiques ou régionales, et laquelle servir à quel utilisateur. Sur un site multilingue, bien posée, elle évite qu’un visiteur belge tombe sur la version canadienne d’une page et empêche vos versions traduites de se cannibaliser entre elles. Mal posée, elle est ignorée en silence. En audit, nous constatons que la plupart des implémentations cassées le sont pour une raison simple et réparable. Trois erreurs concentrent l’essentiel des configs qui échouent en silence, et chacune se corrige une fois qu’on sait où regarder.
Le hreflang n’est qu’un maillon d’une stratégie de référencement international, aux côtés de la structure d’URL et de l’adaptation des contenus par marché.
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.
Un point que beaucoup de guides passent sous silence : hreflang n’est pas un facteur de classement. Google l’a confirmé publiquement à plusieurs reprises par la voix de ses porte-parole. L’annotation ne fait pas remonter une page dans les résultats. Elle agit sur deux plans différents. D’abord le serving : servir la bonne version au bon utilisateur, pour qu’un francophone de Belgique ne voie pas la page destinée à la France. Le mécanisme se joue en deux temps : Google positionne d’abord la version qui porte le signal le plus fort sur une requête, puis substitue à l’affichage la version sœur la plus adaptée à la locale de l’internaute. Ensuite la consolidation : regrouper les signaux entre versions d’une même page, pour que Google comprenne qu’il s’agit de traductions légitimes et non de contenu dupliqué.
Cette distinction change la façon de porter ce chantier en interne. Vous ne promettez pas plus de positions. Vous garantissez que la bonne URL s’affiche au bon endroit et que vos versions arrêtent de se concurrencer. C’est la valeur réelle : sur un site multi-pays, l’annotation décide quelle URL apparaît sur chaque marché.
Un exemple de balise hreflang concret
Pour une page disponible en français (France), en anglais (Royaume-Uni) et en anglais (États-Unis), voici les balises à placer dans le <head> de chacune des trois versions :
<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="x-default" href="https://exemple.com/" />Le code langue seul suffit si vous ne ciblez pas de pays précis (hreflang="fr"). Ajoutez le pays uniquement quand vous distinguez des variantes d’une même langue, par exemple fr-BE pour la Belgique francophone ou en-CA pour le Canada anglophone. Utiliser en-CA plutôt qu’un simple en permet de différencier ce contenu d’une page en-GB, quand langue et pays comptent tous les deux.
Quelle structure d’URL pour vos versions internationales ?
Avant même de poser une seule annotation, une décision structure tout le reste : comment séparer vos versions dans l’URL. Trois modèles existent, et le choix engage l’autorité de votre domaine pour des années.
- Sous-répertoire (
exemple.com/fr/,exemple.com/en/) : notre recommandation par défaut. Toutes les versions héritent de l’autorité du domaine principal, la maintenance reste simple, et l’annotation s’y greffe naturellement. C’est le modèle le plus rentable pour la majorité des sites. - ccTLD (
exemple.fr,exemple.de) : le signal géographique le plus fort pour Google, mais chaque domaine repart de zéro côté autorité. À réserver aux organisations qui ont les moyens de bâtir et suivre plusieurs domaines distincts. - Sous-domaine (
fr.exemple.com) : peu d’avantage concret par rapport au sous-répertoire, tout en fragmentant les signaux. Rarement le meilleur choix quand on part d’une page blanche.
Les erreurs qui font ignorer hreflang par Google
Un jeu de balises de version alternative peut être présent sur toutes vos pages et ne rien produire. Google n’affiche aucune erreur bloquante : il écarte simplement les balises qu’il juge incohérentes. Trois problèmes reviennent dans presque tous les audits internationaux que nous menons.
1. Les liens retour non réciproques
C’est la cause principale des balises hreflang ignorées. La règle de Google est stricte : si la page A déclare la page B comme version alternative, la page B doit déclarer la page A en retour. Sans ce lien retour bidirectionnel, l’annotation entière est écartée. Nous constatons régulièrement des sites où la page d’accueil française pointe vers toutes les langues, mais où les pages traduites ne renvoient pas vers la française, ou renvoient vers une URL avec une légère différence (slash final, http au lieu de https). La réciprocité doit être exacte, URL pour URL.
2. La canonical qui annule tout
L’erreur la plus destructrice, et la moins visible. Chaque page doit porter une balise canonique pointant vers elle-même (self-canonical). Si votre page anglaise déclare une canonical vers la version française, vous envoyez à Google un ordre contradictoire : d’un côté l’attribut dit « ce sont deux versions distinctes à servir séparément », de l’autre la canonical dit « la version anglaise n’existe pas, indexe la française à sa place ». Google tranche en faveur de la canonical et retire la version anglaise de l’index. Résultat : votre marché anglophone disparaît des résultats. En audit technique, cette collision explique une grande part des « hreflang qui ne marchent pas ».
3. Les codes langue et pays inversés ou invalides
Le format est langue-pays, jamais l’inverse. Un code comme en-UK est faux : le code pays du Royaume-Uni est GB dans la norme ISO 3166-1, donc en-GB. Le séparateur est un tiret, pas un underscore : fr_FR est invalide, seul fr-FR est lu. De même, un code langue absent de la norme ISO 639-1 est ignoré. Ces fautes reviennent souvent quand les balises sont générées à la main ou copiées d’un template sans relecture.
Trois autres pièges cassent l’annotation sans le moindre message d’alerte, et ne se voient qu’au crawl : une version alternative en noindex ou bloquée par le robots.txt, une cible qui redirige (301) ou renvoie une 404 au lieu de l’URL finale, et la redirection automatique par adresse IP qui empêche Google d’explorer les autres versions. Le tableau ci-dessous les réunit avec les erreurs de format.
| Erreur observée | Effet | Correction |
|---|---|---|
| Lien retour manquant (A vers B sans B vers A) | Annotation ignorée par Google | Chaque page cite toutes les versions, y compris elle-même, avec des URL identiques |
| Canonical cross-langue (page EN vers canonical FR) | La version alternative sort de l’index | Self-canonical sur chaque version |
Code inversé (en-UK, UK-en) | Balise invalide, ignorée | Format langue-pays ISO : en-GB |
| x-default absent | Aucune page de repli pour les locales non couvertes | Déclarer une version par défaut (souvent le sélecteur de langue) |
| URL relatives ou http/https mélangés | Réciprocité rompue | URL absolues, protocole cohérent partout |
Cible en noindex ou bloquée par le robots.txt | Signal contradictoire, version non servie | Ne jamais poser de hreflang vers une page qu’on désindexe |
| Cible qui redirige (301) ou renvoie une 404 | Annotation rompue, version perdue | Pointer vers l’URL finale et canonique, jamais une URL intermédiaire |
| Redirection automatique par IP / géoloc | Exploration des variantes cassée, risque de cloaking | Servir la bonne version via hreflang, proposer un choix, pas une redirection forcée |
À quoi sert le x-default ?
Le x-default désigne la page à servir quand aucune version déclarée ne correspond à la langue ou au pays de l’internaute. Un visiteur japonais sur un site qui ne parle que français, anglais et espagnol atterrit sur la version x-default. En pratique, cette valeur pointe souvent vers une page de sélection de langue ou vers la version la plus généraliste du site (l’anglais international, par exemple).
Le x-default est souvent mal employé de deux façons. Certains l’oublient, laissant Google choisir seul pour les locales non prévues. D’autres le font pointer vers une version linguistique précise (la française) tout en déclarant aussi fr-FR vers la même URL, ce qui crée une redondance sans valeur. Réservez le x-default à un vrai rôle de repli : la page qui accueille les utilisateurs que vous n’avez pas explicitement ciblés.
Quelle méthode d’implémentation choisir ?
Trois méthodes existent pour déclarer ce signal multirégional. Les guides se contentent souvent de les lister. Comment trancher selon votre contexte, à partir de ce que nous recommandons sur le terrain :
- Balises
<link>dans le<head>: la plus lisible, idéale pour les petits sites (quelques langues, faible volume de pages). Chaque page porte ses annotations. La limite apparaît à l’échelle : sur un catalogue de milliers d’URL, la maintenance devient lourde et le poids ajouté au HTML pèse. - Sitemap XML : notre recommandation par défaut pour les gros sites et les e-commerces. Les balises de version alternative sont centralisées dans un fichier, hors du code des pages, ce qui n’alourdit pas le HTML et simplifie les mises à jour massives. Chaque URL du sitemap liste ses équivalents via
<xhtml:link rel="alternate" hreflang="...">. Plus simple à générer automatiquement et à auditer d’un seul endroit. - En-tête HTTP : la seule option pour les fichiers non-HTML, typiquement les PDF, où l’on ne peut pas insérer de balise
<link>. Elle demande un accès à la configuration serveur et se justifie surtout pour ces cas précis.
Sur WordPress, un piège fréquent : Yoast SEO seul n’émet aucun hreflang. Il faut un plugin multilingue (WPML ou Polylang) qui génère les versions et pose les balises. Beaucoup de sites FR pensent leur config internationale gérée par Yoast alors qu’aucune annotation n’est envoyée à Google.
Une règle non négociable : ne combinez pas les méthodes pour une même page. Déclarer l’attribut à la fois dans le HTML et dans le sitemap crée des signaux qui peuvent diverger. Google additionne les signaux, mais écarte tout jeu contradictoire (même locale renvoyant vers des URL différentes). Choisissez une méthode et tenez-vous-y sur tout le site.
Faut-il encore utiliser hreflang en 2026 ?
Oui, dans les cas où il apporte une information que Google ne devine pas seul. La détection automatique de la langue s’est affinée : sur un site clairement en français, Google identifie la langue sans aide. Là où l’attribut reste indispensable, c’est pour les variantes d’une même langue sur des pays différents. Rien dans le contenu ne dit à un algorithme qu’une page fr-FR vise la France et une page fr-BE la Belgique, ou qu’une page en-US cible les États-Unis et non le Royaume-Uni. C’est exactement ce que l’annotation résout, et c’est le seul signal HTML prévu pour cet usage précis.
Un point 2026 qui muscle l’argument : Google a supprimé le paramètre de ciblage géographique manuel (International Targeting) de Search Console en 2022. Depuis, l’annotation porte seule ce signal de destination pays. Sur un site multilingue ciblant plusieurs marchés, il n’y a plus de réglage manuel de secours, ce qui rend une implémentation propre encore plus décisive.
Il reste utile aussi pour consolider les signaux entre versions et prévenir la cannibalisation entre traductions proches. Restons honnêtes sur les cas où il ne sert à rien : un site mono-langue, mono-pays, sans version alternative, n’a aucun besoin de hreflang. L’ajouter là relève du culte du cargo, pas du référencement naturel. La bonne question n’est jamais « faut-il du hreflang ? » mais « ai-je plusieurs versions d’une même page destinées à des publics différents ? ».
Comment diagnostiquer une implémentation cassée
Puisque Google échoue en silence, le diagnostic ne peut pas attendre un message d’erreur. Il se fait par crawl et validation. Un crawler comme Screaming Frog explore le site, extrait toutes les annotations de version alternative et signale les liens retour manquants, les codes invalides et les URL inaccessibles. C’est le premier réflexe dans tout audit technique international que nous conduisons.
Un point à connaître : Google a supprimé son rapport hreflang dédié (l’onglet « Ciblage international » de Search Console) en septembre 2022. Il n’existe plus de tableau d’anomalies hreflang natif dans Search Console. Google renvoie désormais vers des outils tiers pour la validation site-wide. La méthode fiable en 2026 : un crawl (Screaming Frog) pour la vue d’ensemble des annotations, puis l’inspection d’URL de Search Console page par page pour vérifier comment Google indexe une version précise. Quand une version linguistique disparaît des impressions sans raison de contenu, vérifiez d’abord la self-canonical de cette page. La plupart du temps, dans notre expérience, la collision canonical est là.
Attention si vos annotations sont injectées côté client. Une annotation posée en JavaScript peut ne pas être vue si le rendu échoue ou tarde. Comparez alors le HTML rendu au code source : un problème de SEO JavaScript peut vider vos balises de toute portée sans que le source paraisse fautif.
Différence entre lang et hreflang
Deux attributs proches de nom, deux rôles distincts. L’attribut lang (par exemple <html lang="fr">) déclare la langue du contenu de la page courante. Il sert au navigateur, aux lecteurs d’écran et à l’accessibilité. Il ne dit rien des autres versions de la page.
L’attribut hreflang, lui, ne décrit pas la page où il se trouve : il pointe vers les autres versions linguistiques et régionales existantes. C’est un signal destiné aux moteurs de recherche pour le serving multirégional. Les deux cohabitent : lang pour l’accessibilité de la page, hreflang pour orienter Google entre versions. Confondre les deux est un piège classique.
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. Il sert à servir la bonne version au bon internaute selon sa langue et son pays, et à éviter que vos traductions soient traitées comme du contenu dupliqué. Ce n’est pas un facteur de classement.
Qu’est-ce qu’un exemple de balise hreflang ?
Un exemple pour une page française et sa version anglaise 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 doit lister toutes les autres, la sienne comprise, avec des liens retour réciproques exacts (même URL, même protocole), sinon Google ignore l’ensemble.
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é (lecteurs d’écran). Le hreflang, lui, indique aux moteurs de recherche les autres versions linguistiques et régionales de la page. Le premier décrit la page, le second pointe vers ses alternatives. Ils sont complémentaires, pas interchangeables.
Comment implémenter hreflang correctement ?
Choisissez une seule méthode : balises <link> dans le <head> pour les petits sites, sitemap XML pour les gros. Déclarez toutes les versions sur chaque page, y compris elle-même, avec des liens retour réciproques exacts. Ajoutez un x-default et vérifiez que chaque page porte une self-canonical, jamais une canonical cross-langue.
Faut-il encore utiliser hreflang en 2026 ?
Oui dès que vous ciblez plusieurs pays partageant une même langue (fr-FR contre fr-BE, en-US contre en-GB), car la détection automatique de Google ne distingue pas ces variantes. Il reste utile pour consolider les signaux entre traductions. Inutile en revanche sur un site mono-langue et mono-pays sans version alternative.
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 URL en erreur. Search Console n’a plus de rapport hreflang dédié depuis 2022 : utilisez l’inspection d’URL page par page. Si une version disparaît des impressions, vérifiez en priorité sa balise canonique.
Outils pour poser et vérifier le hreflang
Aucun outil ne remplace une architecture propre, mais quelques catégories fiabilisent le travail. Nous partons des sources qui font autorité avant tout tableau de bord tiers.
- Screaming Frog SEO Spider : crawl complet qui extrait les annotations, repère les liens retour manquants et les codes invalides. C’est l’outil de référence pour la validation site-wide depuis la suppression du rapport hreflang de Search Console.
- Google Search Console (inspection d’URL) : plus de rapport hreflang dédié, mais l’inspection d’URL montre comment Google indexe une version précise, page par page.
- Validateurs hreflang en ligne : contrôle ponctuel d’une page ou d’un petit set d’URL, utile pour un test rapide avant déploiement.
- Générateurs de balises hreflang : gain de temps pour produire un premier jeu de code sans faute de format, à relire ensuite manuellement.
- Documentation officielle Google Search Central : la référence à jour sur les règles de serving multirégional et de format des annotations.
En résumé
Le hreflang n’améliore pas vos positions : il garantit que la bonne version de page atteint le bon marché et protège vos traductions de la cannibalisation. Sa réussite tient à trois exigences : des liens retour réciproques exacts, une self-canonical sur chaque page, et des codes ISO valides. Pour un site multilingue ou multirégional, ces réglages font la différence entre une architecture internationale qui fonctionne et des versions qui s’effacent silencieusement de l’index.
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.