La balise hreflang est un petit élément HTML placé dans la tête d’un document qui change tout pour la création d’un site multilingue. Elle indique aux moteurs de recherche quelle version linguistique (et/ou régionale) d’une page web doit être affichée à tel utilisateur dans tel pays.
Sans ce balisage, vos pages web en français, anglais, allemand ou pour une région géographique donnée (France, Canada, Royaume-Uni, États-Unis…) risquent de se cannibaliser, de sembler dupliquées, de générer une mauvaise expérience utilisateur (prix, devise, contenu non traduit) et, au final, de dégrader la visibilité SEO (hausse du taux de rebond, perte de targeting géographique).
Bien implémentée, une balise hreflang dirige la page vers la bonne langue : ciblage précis, référencement international plus propre, et contenu mieux indexable.
Ce guide propose une définition claire, les méthodes d’implémentation, des exemples de code HTML et de sitemap XML, la syntaxe des codes de langue/code pays (format ISO), la relation avec la balise canonique, puis une checklist de vérification dans Google Search Console pour éviter les erreurs fréquentes (balise manquante, balises incorrectes, liens vers une URL non indexable, etc.).
Vous verrez aussi comment utiliser des outils comme WordPress, Shopify ou Weglot pour implémenter plus simplement, ainsi que des solutions de validation/checker gratuites.
Hreflang : définition et objectifs
Sur un site internet, la balise hreflang est un attribut hreflang placé dans un tag hreflang <link rel="alternate" …> au sein de la tête (head) du document en markup language (HTML). Elle sert à indiquer aux moteurs de recherche que plusieurs versions d’une page existent pour des audiences différentes : par langue (français, anglais, allemand…) et/ou par région (France, Canada, Royaume-Uni).
Concrètement, on ajoutera une liste de liens entre ces variantes ; chaque URL « pointe » vers les autres versions et aide Google à diriger instantanément la bonne page vers le bon internaute.
Objectif principal
Associer la bonne utilisation de la langue et de la région à la bonne page, de façon cohérente et professionnelle : fr-FR pour la France, en-GB pour le Royaume-Uni, etc. La fonction est claire : spécifier via des paramètres normalisés (codes ISO) la version la plus pertinente selon l’origine de la personne qui cherche, son pays, et sa langue. Résultat : une meilleure expérience et un référencement plus propre (moins de contenu perçu comme dupliqué).
Pourquoi c’est important
Sans hreflang, vos pages en plusieurs langues peuvent se faire concurrence : la page en anglais peut s’afficher en France, ou l’inverse. Avec hreflang, le site et les moteurs fonctionnent de concert : ils comprennent qu’il s’agit de versions « sœurs », pas de copies. L’importance est double : d’un côté, on intègre de la clarté pour le robot ; de l’autre, on propose la bonne offre au bon public, au bon moment.
Où et comment c’est situé dans la page
La déclaration se fait dans la partie <head> du site web (ou dans le sitemap). Exemple suivante en HTML :
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit-x" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk-en/product-x" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Ici, chaque lien utilisant rel="alternate" et l’attribut hreflang spécifie l’URL destinée à une audience donnée. La version disponible pour la France renvoie vers la version anglais Royaume-Uni, et inversement ; x-default sert de « page par défaut » si aucune variante ne convient.
Outils et CMS
Sur WordPress, Shopify ou un site headless, vous pouvez créer ces liens à la main, ou passer par un service comme Weglot qui génère les morceaux de code de manière automatique et maintient les correspondances entre pages enfant et pages mères traduites. Dans tous les cas, l’œuvre clé consiste à bien définir les paires et la réciprocité entre chaque version d’une page.
Hreflang est une solution qui aide les moteurs à comprendre vos déclinaisons : vous déclarez des couples langue/région, vous reliez les URL entre elles, et vous laissez Google diriger instantanément la bonne page selon la situation de l’utilisateur. C’est la chose à mettre en place dès que votre site internet cible plusieurs pays ou langues : une petite ligne de code, un grand gain de pertinence.
Pourquoi hreflang est-il important pour le SEO ?
Parce que le SEO international repose sur une promesse : à chaque requête, la bonne page, dans la bonne langue, pour la bonne personne. Dans la pratique, les moteurs de recherche voient souvent plusieurs versions différentes d’un même contenu. Sans balise hreflang, ils hésitent, mélangent les morceaux d’indexation, et peuvent afficher la mauvaise version d’une page.
La balise devient alors l’élément clé : elle indique (et fait cibler) de façon explicite la langue et, si besoin, la région à diriger. Sa fonction est limpide : indiquer que ces URL sont des équivalences et, selon la situation de l’internaute (pays, langue du navigateur, intention de la requête), proposer instantanément la bonne réponse.
Sur le plan professionnel, hreflang évite la cannibalisation, clarifie l’autorité entre pages sœurs et améliore les signaux d’engagement (moins de rebond, meilleure conversion) — bref, il sert votre objectif principal : être pertinent là où on vous cherche. Côté production, vous pouvez ajouter ces annotations à la main ou via un outil utilisé couramment comme Weglot, qui indique et synchronise de façon automatique les paires de variantes.
En coulisses, c’est l’œuvre conjointe du contenu et du balisage : vous fournissez aux moteurs un groupe d’URL cohérent, et eux dirigent la meilleure version d’une page à la bonne personne. Résultat : un SEO international propre, lisible, et des utilisateurs qui trouvent ce qu’ils attendent, là où ils l’attendent.
Les codes : langue, région et format ISO (décryptage rapide)
Deux normes se cachent derrière hreflang :
- ISO 639-1 pour la langue (ex. fr, en, de) ;
- ISO 3166-1 alpha-2 pour le pays/la région (ex. FR, CA, GB, US).
On ajoute la région après la langue, séparée par un tiret et en majuscules pour la partie pays :
- Langue seule → fr, en, de : vous déclarez une version d’une page purement linguistique, sans ciblage territorial. Utile quand le même contenu convient à tout groupe d’utilisateurs parlant cette langue.
- Langue + région → fr-FR, fr-CA, en-GB, en-US : vous précisez une destination géographique. Cette granularité sert à montrer, à chaque internaute, la page destinée à sa personne (monnaie, taxes, livraison, tournures locales).
Règle d’or : le code doit correspondre au contenu réellement servi : tarifs en euros, CGV françaises, vocabulaire “couleur/colour”, etc. Une page anglaise pour le Royaume-Uni sera en-GB (et non en-UK, qui n’existe pas en ISO 3166-1). De même, la Suisse peut accueillir fr-CH, de-CH, it-CH si vos pages sont adaptées à chaque langue et à ce territoire.
Astuce pratique : pas de déclinaison par pays ? Alors la langue seule suffit (fr, en, de). Vous pourrez plus tard ajouter des variantes régionales si le projet évolue (ex. lancer un pricing en-US).
Des solutions comme Weglot aident à gérer ces couples langue/région et à relier les versions entre elles : l’outil forme le groupe de variantes (les “alternates”) pour chaque version d’une page, ce qui simplifie la maintenance et réduit le risque d’erreurs de codage.
Trois manières d’implémenter la balise hreflang
Dans le code HTML (section head)
C’est la méthode « tête de document ». On place des link rel alternate hreflang pointant vers chaque version alternative :
<head>
<link rel="alternate" hreflang="fr-FR" href="https://exemple.org/fr/produit-x" />
<link rel="alternate" hreflang="fr-CA" href="https://exemple.org/ca-fr/produit-x" />
<link rel="alternate" hreflang="en-GB" href="https://exemple.org/uk-en/product-x" />
<link rel="alternate" hreflang="x-default" href="https://exemple.org/" />
</head>
Avantage : visible dans le code de la page, utilisé par la plupart des cms populaires (WordPress, Shopify, etc.).
Attention : sur un gros site web, la liste peut devenir longue ; garder la syntaxe correctement et éviter les morceaux manquants.
Dans les en-têtes HTTP (PDF et fichiers)
Utile quand la page est un PDF ou une ressource non-HTML :
Link: <https://exemple.org/fr/guide.pdf>; rel="alternate"; hreflang="fr-FR"
Link: <https://exemple.org/en/guide.pdf>; rel="alternate"; hreflang="en-US"
Link: <https://exemple.org/>; rel="alternate"; hreflang="x-default"
Avantage : parfait pour les fichiers téléchargeables.
Besoin technique : accès serveur/CDN pour modifier le code d’en-tête.
Dans le sitemap XML (méthode scalable)
On intègre les annotations hreflang avec le namespace xhtml dans le sitemap xml :
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://exemple.org/fr/produit-x</loc>
<xhtml:link rel="alternate" hreflang="fr-FR" href="https://exemple.org/fr/produit-x"/>
<xhtml:link rel="alternate" hreflang="fr-CA" href="https://exemple.org/ca-fr/produit-x"/>
<xhtml:link rel="alternate" hreflang="en-GB" href="https://exemple.org/uk-en/product-x"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://exemple.org/"/>
</url>
</urlset>
Avantage : centralisé, propre pour les sites web volumineux ; les robots utilisent bien cette source.
Rappel : un seul « lieu de vérité » (HTML ou sitemap), pour éviter les divergences.
x-default (ou default) sert la version principale/alternative quand aucune langue/région ne s’impose (page destinée à l’audience internationale, sélecteur pays/langue).
Hreflang, canonique et indexation : la bonne relation
Pensez-le ainsi : hreflang organise vos variantes par zone géographique et langue, tandis que la balise canonique désigne, pour chaque version d’une page, l’URL de référence à indexer. Chaque variante doit donc être auto-canonique (la canonique pointe vers elle-même) afin de conserver sa valeur propre dans l’index.
Le rôle d’hreflang est horizontal : il relie entre elles les pages équivalentes (ex. fr-FR ↔ version anglaise en-GB) pour qu’à une requête donnée l’internaute voie la bonne URL selon sa zone.
Si, par erreur, vous mettez la canonique de toutes les variantes sur une seule URL “globale”, vous annulez le signal hreflang : Google comprendra qu’une seule personne (toutes zones confondues) doit être envoyée vers cette unique page, et les autres versions risquent de ne plus être indexées correctement. Résultat : perte de ciblage par zone géographique, baisse de visibilité locale, et expérience dégradée.
Bon schéma :
- fr-FR → canonique = fr-FR ; hreflang vers en-GB, en-US, etc.
- en-GB → canonique = en-GB ; hreflang vers fr-FR, en-US, etc.
Des solutions comme Weglot aident à respecter ce duo gagnant (auto-canonique + maillage interne hreflang) en synchronisant les liens entre variantes. In fine, gardez la règle d’or : chaque version d’une page est responsable d’elle-même (canonique), et amie avec ses sœurs (hreflang).
C’est ce tandem qui garantit à chaque internaute la bonne page, dans la bonne langue, pour la bonne zone géographique.
Structures d’URL et ciblage géographique avec hreflang
- Sous-répertoires : domaine.com/fr/, domaine.com/en/ → faciles, partagent l’autorité du domaine.
- Sous-domaines : fr.domaine.com, en.domaine.com → propres mais plus de gestion.
- ccTLD : domaine.fr, domaine.de → fort signal régionaux, autorité fragmentée.
La méthode choisie dépend du projet ; l’important est la cohérence : mêmes pages, mêmes variantes, balisage hreflang correctement implémenté partout.
Cas concrets (exemples détaillés de balises hreflang)
France vs Canada francophone : fr-FR ↔ fr-CA
Même langue, zone géographique différente, donc attentes différentes (euros/TVA vs dollars/TVH, conditions de livraison, mentions légales).
Exemple HTML (head) :
<link rel="alternate" hreflang="fr-FR" href="https://exemple.com/fr/chaussures-trail" />
<link rel="alternate" hreflang="fr-CA" href="https://exemple.com/ca-fr/chaussures-trail" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />
À retenir : les deux pages sont des versions d’une même page, adaptées à chaque pays (texte, devises, frais). Chaque URL est auto-canonique, et chacune déclare l’autre en alternate.
Royaume-Uni vs États-Unis : en-GB ↔ en-US
Langue identique (anglais) mais variantes régionales : orthographe (“favourite” vs “favorite”), unités (miles vs miles…), taxes, délais, supports.
Exemple HTML (head) :
<link rel="alternate" hreflang="en-GB" href="https://exemple.com/uk-en/running-shoes" />
<link rel="alternate" hreflang="en-US" href="https://exemple.com/us-en/running-shoes" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />
Astuce contenu : adaptez aussi les meta title/description, la monnaie et les conditions (retours, service client) pour réduire le rebond et renforcer la pertinence locale.
Suisse multilingue : fr-CH, de-CH, it-CH
Un même pays avec plusieurs langues officielles. Trois variantes linguistiques coexistent, toutes ciblant la même zone géographique (CH).
Exemple dans le sitemap XML :
<url>
<loc>https://exemple.com/ch-fr/abonnement</loc>
<xhtml:link rel="alternate" hreflang="fr-CH" href="https://exemple.com/ch-fr/abonnement"/>
<xhtml:link rel="alternate" hreflang="de-CH" href="https://exemple.com/ch-de/abonnement"/>
<xhtml:link rel="alternate" hreflang="it-CH" href="https://exemple.com/ch-it/abonnement"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://exemple.com/"/>
</url>
Bon réflexe : assurez la réciprocité entre toutes les variantes et une auto-canonique par URL.
Ressources non-HTML (PDF, fichiers) : en-têtes HTTP
Quand la page est un PDF (ou autre fichier), on ne peut pas placer de balises dans le head. On déclare hreflang dans les headers HTTP du serveur/CDN.
Exemple d’en-têtes :
Link: <https://exemple.com/fr/guide-produit.pdf>; rel="alternate"; hreflang="fr-FR"
Link: <https://exemple.com/en/product-guide.pdf>; rel="alternate"; hreflang="en-GB"
Link: <https://exemple.com/>; rel="alternate"; hreflang="x-default"
Contrôle qualité : vérifiez que chaque fichier renvoie bien 200 OK (pas de 302/404), et que l’équivalence entre versions est réelle (même guide, langues différentes).
Variante “langue seule” vs “langue + région”
Si vous n’avez qu’une traduction anglaise pour tout le monde, utilisez en sans pays :
<link rel="alternate" hreflang="fr" href="https://exemple.com/fr/abonnement" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en/subscription" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />
Le jour où vous déclinez par pays (ex. US/UK), passez à en-US / en-GB et mettez à jour toutes les déclarations (HTML ou sitemap) pour garder la cohérence.
e-commerce : déclinaisons Prix/Livraison par pays
Boutique avec mêmes fiches produits, mais prix, livraisons et taxes différents :
<link rel="alternate" hreflang="fr-FR" href="https://exemple.com/fr/produit-x" />
<link rel="alternate" hreflang="de-DE" href="https://exemple.com/de/produkt-x" />
<link rel="alternate" hreflang="es-ES" href="https://exemple.com/es/producto-x" />
Plus de clarté : adaptez aussi le schéma produit (currency), et n’oubliez pas d’aligner title/description et FAQ locales.
Page absente dans une langue : utilisez x-default
Si une variante n’est pas encore faite, ne la déclarez pas. Orientez vers une page générique (x-default) ou un sélecteur pays/langue :
<link rel="alternate" hreflang="fr-FR" href="https://exemple.com/fr/support" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en/support" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/support" />
But : éviter les 404 et les redirections en chaîne qui brouillent l’indexation.
Implémentation Hreflang dans les CMS (WordPress, Shopify, Weglot…)
- WordPress : plugins multilingues (Weglot, WPML, Polylang) implémentent les balises hreflang automatiquement. Vérifiez la référence canonique et le sitemap xml.
- Shopify : thèmes récents utilisent des sections
link rel="alternate" hreflang; si besoin, modifier le code du layout. - Weglot : solution gratuite en entrée puis plan au mois ; créée rapidement des versions traduites et gère l’annotation hreflang automatiquement.
- Autres : tout CMS utilisé en pro (Drupal, Magento, etc.) propose une option pour intégrer hreflang via template ou sitemap.
Erreurs fréquentes sur l’utilisation du Hreflang et comment les éviter
- Balise manquante sur une variante : la liste n’est pas complète → ajouter toutes les URL équivalentes, y compris l’auto-référence.
- Codes invalides : en-UK au lieu de en-GB → respecter le format ISO.
- Lien vers une URL non indexable (301/404, noindex) → cibler la destination finale 200 OK.
- Mix incohérent (HTML ≠ sitemap) → choisir une source et la tenir à jour.
- Canonical mal réglé (vers une autre variante) → revenir à l’auto-canonique.
- Géo-redirection dure qui empêche l’accès à une version alternative → afficher un sélecteur ; ne pas bloquer par IP.
Vérification : Google Search Console (search) dispose d’un rapport Internationalisation (quand disponible) et signale certaines erreurs. Des checkers gratuits en ligne testent la validation des balises hreflang. Un crawl pro aide à repérer les problèmes à grande échelle.
Modèles Hreflang prêts à copier (HTML et Sitemap)
HTML / head (version simple)
<link rel="alternate" hreflang="fr-FR" href="https://exemple.org/fr/page-x" />
<link rel="alternate" hreflang="en-GB" href="https://exemple.org/uk-en/page-x" />
<link rel="alternate" hreflang="x-default" href="https://exemple.org/" />
Sitemap XML (avec xhtml)
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://exemple.org/fr/page-x</loc>
<xhtml:link rel="alternate" hreflang="fr-FR" href="https://exemple.org/fr/page-x"/>
<xhtml:link rel="alternate" hreflang="en-GB" href="https://exemple.org/uk-en/page-x"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://exemple.org/"/>
</url>
</urlset>
HTTP header (PDF)
Link: <https://exemple.org/fr/guide.pdf>; rel="alternate"; hreflang="fr-FR"
Link: <https://exemple.org/en/guide.pdf>; rel="alternate"; hreflang="en-GB"
Bonnes pratiques éditoriales (le SEO, ce n’est pas que la balise hreflang)
La balise hreflang ne crée pas la pertinence si la version n’est pas adaptée :
- Traduction réelle (pas juste un mot traduit) ;
- Contenu différent quand la région l’exige (prix, stocks, information légale) ;
- Balise title/meta langue-spécifiques ;
- Schéma produit (monnaie) cohérent.
C’est l’œuvre conjointe du balisage et du contenu qui donne l’optimisation maximale et la visibilité internationale.
FAQ express du Hreflang
Faut-il une entrée x-default ?
Recommandée si vous avez une version principale ou une page destinée à orienter l’audience (sélecteur pays/langue).
Peut-on mixer HTML et sitemap ?
Oui, mais mieux vaut une source principale. Si vous mixez, assurez-vous qu’elles fonctionnent et déclarent la même liste.
Hreflang remplace la canonique ?
Non. Hreflang relie des versions alternatives ; la canonique reste principale pour l’indexation.
Et si une page n’existait pas dans une langue ?
Ne déclarez pas de hreflang vers une URL manquante. Orientez vers x-default ou laisser la variante absente.
Checklist de mise en production de vos balises Hreflang
- Codes ISO valides (langue + région si utile).
- Réciprocité entre toutes les URL ; auto-référence incluse.
- x-default pour la version alternative par défaut.
- Cibles 200 OK (pas de redirection/erreur).
- Canonical auto-référencé.
- Méthode unique préférée (HTML ou sitemap xml ou en-tête).
- Audit et validation via Google Search Console et un checker tiers.
- Mises à jour maintenues (ajout d’une langue → mise à jour du sitemap/head).
Vous êtes maintenant un(e) pro de la balise hreflang !
Bien utiliser la balise hreflang, c’est implémenter une annotation linguistique et régionale claire, compréhensible par le moteur de recherche, et entretenue dans le temps. Entre HTML, sitemap xml et en-têtes, choisir la méthode adaptée à votre projet, définir des codes en format ISO, vérifier la réciprocité, coupler avec une canonique propre, puis contrôler dans Google Search Console : cette stratégie simple améliore le référencement international, évite le contenu dupliqué et propose au public la bonne version au bon endroit.
Que vous soyez sous WordPress, Shopify ou une stack plus technique, il suffit d’une mise en place rigoureuse pour que vos pages fonctionnent correctement et gagnent en visibilité — manière efficace de servir votre audience globale, sans perdre le fil entre les pays.
