Hreflang : le guide pratique pour votre SEO international

L’attribut hreflang indique à Google qu’une page existe en plusieurs versions linguistiques ou régionales, et lui précise laquelle servir à quel internaute. Il ne donne aucun bonus de positionnement : il sert à éviter qu’un utilisateur belge tombe sur la page prévue pour la France, ou qu’un visiteur espagnol reçoive la version anglaise. Ce guide couvre la syntaxe exacte, les erreurs que l’on retrouve le plus souvent en audit, les conflits avec la balise canonical et la façon de contrôler votre implémentation depuis que Search Console ne propose plus de rapport dédié.

Hreflang n’est qu’une brique d’un projet international. Le choix de l’architecture (ccTLD, sous-domaine, sous-répertoire) et la différence entre traduction et localisation sont traités dans notre guide SEO international : la stratégie pour cibler plusieurs pays, qui couvre aussi les sites multilingues. Ici, on se concentre sur la mise en œuvre technique.

01Hreflang : définition et rôle réel dans Google

Hreflang est une annotation qui relie entre elles les URL équivalentes d’un même contenu, publiées dans plusieurs langues ou pour plusieurs pays. La documentation Google Search Central « Versions localisées de vos pages » la présente comme le moyen de signaler ces variantes pour que Google affiche la plus pertinente dans ses résultats. On parle de « cluster hreflang » pour désigner l’ensemble des URL qui se déclarent mutuellement.

Ce que hreflang fait

• Il aide Google à choisir quelle URL afficher selon la langue et la localisation de l’utilisateur.
• Il distingue des variantes régionales d’une même langue : français de France, de Belgique, de Suisse ou du Canada.
• Il limite le risque de voir des pages régionales très proches traitées comme des doublons, dont une seule serait visible sur tous les marchés.
• Il fournit, avec la valeur x-default, une page de repli pour les internautes qui ne correspondent à aucune version.

Ce que hreflang ne fait pas

Trois idées reçues coûtent cher dans un projet international. D’abord, hreflang ne détecte pas la langue : Google précise qu’il n’utilise ni hreflang ni l’attribut HTML lang pour identifier la langue d’une page, il s’appuie sur ses propres algorithmes. Une page déclarée « fr » mais rédigée à moitié en anglais reste une page ambiguë. Ensuite, hreflang ne remplace pas la traduction : selon la même documentation, des versions localisées ne sont considérées comme des doublons que si le contenu principal n’est pas traduit. Enfin, hreflang ne crée pas de visibilité dans un pays où le site n’a ni contenu adapté ni popularité : il aiguille une demande existante, il ne la génère pas.

La question se pose aussi pour les réponses générées. Les AI Overviews et AI Mode sont disponibles en France depuis le 22 juillet 2026, et Google indique dans sa documentation « AI features and your website » qu’aucune optimisation spéciale n’est requise pour y apparaître : les pages mobilisées viennent de l’index de recherche classique. Une version pays mal canonisée ou absente de l’index a donc peu de chances d’y être reprise. Pour les moteurs conversationnels tiers, la documentation publique des robots de recherche d’OpenAI, dont OAI-SearchBot qui alimente la recherche de ChatGPT, et de Perplexity, avec PerplexityBot, porte sur l’identification des robots et le robots.txt, sans rien dire de hreflang. La précaution utile consiste donc à laisser ces robots accéder à chaque version locale et à rédiger chaque version sans ambiguïté dans la langue de son marché.

02Syntaxe hreflang : codes, x-default et méthodes d’implémentation

La syntaxe tient en une ligne, mais chaque élément obéit à des règles strictes. Voici la forme de base, placée dans le <head> de chaque version d’une page produit disponible en France, en Belgique et au Royaume-Uni :

<link rel="alternate" hreflang="fr-FR" href="https://[domaine]/fr-fr/chaussures-randonnee/" />
<link rel="alternate" hreflang="fr-BE" href="https://[domaine]/fr-be/chaussures-randonnee/" />
<link rel="alternate" hreflang="en-GB" href="https://[domaine]/en-gb/hiking-shoes/" />
<link rel="alternate" hreflang="x-default" href="https://[domaine]/" />

Ce bloc doit apparaître à l’identique sur les trois pages. Les URL alternatives doivent être absolues, protocole compris, et peuvent appartenir à des domaines différents, par exemple un .fr et un .be.

Les codes langue et pays

La valeur hreflang combine un code de langue au format ISO 639-1 (deux lettres : fr, en, de, es) et, en option, un code de région au format ISO 3166-1 Alpha 2 (FR, BE, CH, GB). Google n’accepte que ces référentiels, complétés par ISO 15924 pour distinguer une écriture, par exemple zh-Hant pour le chinois traditionnel et zh-Hans pour le chinois simplifié.

• fr : tous les francophones, quel que soit leur pays.
• fr-BE : les francophones situés en Belgique.
• en-GB et non en-UK : le code du Royaume-Uni dans ISO 3166-1 est GB.
• BE seul : invalide, un code pays ne s’utilise jamais sans code langue.

Adoptez une convention d’écriture unique, par exemple la langue en minuscules et le pays en majuscules : elle ne change rien pour Google, mais elle simplifie les contrôles automatisés et la lecture des exports.

La valeur x-default

x-default est une valeur réservée qui désigne la page à afficher quand aucune version ne correspond à la langue ou au pays du navigateur. On l’attribue généralement à une page de sélection de langue ou à la version internationale du site. Elle est facultative, mais sans elle, c’est Google qui décide seul de la version montrée aux internautes des marchés non couverts.

Balise HTML, en-tête HTTP ou sitemap XML

Google accepte trois méthodes et les considère comme équivalentes. Le choix dépend de votre stack technique, pas d’un avantage SEO.

• Balises link dans le head : la méthode la plus lisible, courante sur WordPress avec une extension multilingue. Elle alourdit le code source quand le nombre de versions devient important.
• En-tête HTTP Link : utile surtout pour les fichiers non HTML, comme les PDF, qui n’ont pas de head.
• Sitemap XML : chaque entrée <url> liste toutes ses variantes via des éléments xhtml:link, avec la déclaration de l’espace de noms xhtml. C’est souvent la méthode la plus simple à maintenir sur un gros catalogue, car elle se génère directement depuis la base de données.

N’empilez pas deux méthodes sans nécessité. Si la balise HTML et le sitemap divergent, vous créez vous-même les signaux contradictoires que hreflang est censé éviter.

03Les erreurs hreflang les plus fréquentes

La plupart des implémentations défaillantes le sont pour des raisons simples. Voici les erreurs que l’on rencontre le plus souvent, classées de la plus bloquante à la plus insidieuse.

1. Liens de retour manquants. Si la page A déclare la page B mais que B ne déclare pas A, Google ignore les annotations. La réciprocité est la règle numéro un.
2. Absence d’autoréférence. Chaque version doit se citer elle-même en plus des autres. Un cluster de quatre langues implique quatre lignes identiques sur les quatre pages.
3. URL relatives ou incomplètes. Une URL sans protocole ou un chemin relatif ne sont pas exploitables.
4. URL qui ne répondent pas en 200. Une annotation qui pointe vers une redirection, une erreur 404 ou une page en noindex envoie un signal inutilisable. Le cas est fréquent après une refonte ou un changement de structure d’URL.
5. Codes invalides. en-UK, fr-FRA, un code pays seul, ou un tiret bas à la place du tiret (fr_FR).
6. Pointage vers une page non équivalente. Relier une fiche produit à la page d’accueil de la version étrangère parce que le produit n’y existe pas. Mieux vaut ne rien déclarer pour cette langue.
7. Hreflang sur des URL paramétrées. Filtres, tris ou identifiants de session entrent dans le cluster et multiplient les combinaisons à explorer.
8. Désynchronisation entre versions. Une page supprimée dans une langue reste déclarée dans les autres, faute de processus de mise à jour.

Les erreurs 1, 2 et 8 ont la même cause : hreflang est traité comme une saisie manuelle page par page. Dès que le site dépasse quelques dizaines de pages par langue, la seule approche durable consiste à générer les annotations depuis une table de correspondance unique, alimentée par le CMS ou le PIM.

04Hreflang et canonical : éviter les conflits

La balise canonical et hreflang répondent à deux questions différentes. La canonical dit : « parmi ces URL au contenu identique, laquelle indexer ? ». Hreflang dit : « parmi ces versions équivalentes, laquelle montrer à cet internaute ? ». Les conflits apparaissent quand on utilise la première pour faire le travail de la seconde.

Google le formule clairement dans sa documentation sur la canonicalisation des URL en double : si vous utilisez hreflang, indiquez une page canonique dans la même langue, ou dans la meilleure langue de substitution si elle n’existe pas. En pratique, chaque version linguistique porte une canonical vers elle-même, et le cluster hreflang ne contient que des URL canoniques.

• Erreur classique : toutes les versions ont une canonical vers la version anglaise. Vous demandez à Google de n’indexer que l’anglais tout en lui demandant de servir le français aux francophones. Les deux consignes se contredisent et les versions locales risquent de sortir des résultats.
• Variantes très proches : fr-FR et fr-BE avec des textes quasi identiques. Google peut les regrouper et retenir une seule canonique. Sa documentation précise qu’il privilégie comme canoniques les URL qui font partie de clusters hreflang réciproques. Différencier réellement le contenu (prix, devise, délais de livraison, mentions légales, exemples locaux) reste la meilleure protection.
• Facettes et paramètres : si une page filtrée a une canonical vers la version sans filtre, c’est l’URL canonique qui doit figurer dans le cluster hreflang, jamais la variante filtrée.

Pour savoir quelle URL Google a retenue, l’outil d’inspection d’URL de Search Console affiche la canonique déclarée par l’utilisateur et la canonique sélectionnée par Google. Un écart répété entre les deux sur un répertoire pays est le premier symptôme d’un conflit.

05Vérifier hreflang sans le rapport Ciblage international

Une mise au point s’impose sur la vérification en Search Console : le rapport Ciblage international, qui listait les erreurs hreflang, a été retiré en 2022. Google a précisé, dans la page d’aide Search Console consacrée à l’abandon de ce rapport, qu’il continuait de prendre en charge et d’utiliser les balises hreflang, et que le ciblage par pays de Search Console était abandonné. Le contrôle passe donc par une combinaison d’outils.

Ce que Search Console montre encore

• Inspection d’URL : canonique déclarée et canonique sélectionnée par Google, statut d’indexation, date de dernière exploration. À réaliser sur un échantillon de chaque version.
• Rapport Performances filtré par pays et par page : vérifiez quelles URL reçoivent les impressions dans chaque pays. Si la version fr-FR capte l’essentiel des impressions en Belgique alors qu’une version fr-BE existe, le cluster ne joue pas son rôle.
• Rapport Pages (indexation) : surveillez le motif « Page en double : Google n’a pas choisi la même URL canonique que l’utilisateur » sur les répertoires pays.

Crawlers et scripts de contrôle

Un crawler reste l’outil le plus fiable pour auditer un cluster complet. Screaming Frog SEO Spider, Ahrefs Site Audit, Oncrawl ou Sitebulb signalent les liens de retour manquants, les codes invalides et les URL non canoniques ou non indexables présentes dans les annotations. Si vos hreflang sont déclarés dans le sitemap, configurez le crawl pour l’explorer et en extraire les annotations, sinon l’outil ne les verra pas.

Croisez ensuite le résultat du crawl avec les données de performance par pays : une implémentation techniquement propre qui ne modifie pas la répartition des impressions signale souvent un problème de contenu trop similaire plutôt qu’un problème de balises.

Automatiser l’audit avec n8n

Sur un site qui publie chaque semaine dans plusieurs langues, un contrôle ponctuel ne suffit pas. Un workflow n8n simple assure un suivi continu :

1. Un déclencheur planifié (Schedule Trigger), par exemple chaque lundi matin.
2. Un nœud HTTP Request qui récupère le sitemap XML, suivi d’un nœud XML qui le convertit en JSON.
3. Un nœud Code qui reconstruit chaque cluster et vérifie l’autoréférence, la réciprocité et la validité des codes.
4. Un second nœud HTTP Request qui contrôle le code de réponse de chaque URL alternative.
5. Un envoi des anomalies vers Google Sheets ou Slack, avec l’URL source, l’URL cible et le type d’erreur.

Ce garde-fou repère une version supprimée ou redirigée dans la semaine, au lieu de la découvrir au prochain audit trimestriel.

06Checklist de déploiement hreflang

Avant de mettre en ligne une nouvelle langue ou un nouveau pays, passez cette liste point par point :

• Chaque page déclare toutes ses versions, elle-même comprise.
• Toutes les URL sont absolues, en https, et répondent en 200.
• Toutes les URL du cluster sont canoniques et indexables.
• Les codes respectent ISO 639-1 et ISO 3166-1 Alpha 2.
• Une valeur x-default est définie pour les marchés non couverts.
• Une seule méthode de déclaration est utilisée, ou toutes sont générées depuis la même source.
• Le contenu principal est réellement traduit et adapté : devise, unités, conditions de livraison, service client.
• Aucune redirection automatique fondée sur l’IP ou la langue du navigateur n’empêche Googlebot d’accéder à toutes les versions.
• Un contrôle automatisé est planifié après chaque mise en production.

Hreflang corrige un problème d’aiguillage, il ne remplace pas une stratégie de marché. Avant de multiplier les versions, validez la demande réelle dans chaque pays et les moyens de produire un contenu localisé : c’est l’objet du guide SEO international cité en introduction. Pour replacer ce chantier parmi les autres priorités techniques et éditoriales, retrouvez l’ensemble des ressources et méthodes SEO de Digital Signal Studio.