Un client m'appelle il y a deux mois, paniqué. Sa boutique en ligne venait de perdre 40 % de son trafic depuis l'Allemagne. Pas une pénalité, pas un bug serveur. Juste une mauvaise configuration hreflang qui envoyait les visiteurs germanophones vers la version autrichienne de son site. Trois lignes de code. Trois lignes qui lui coûtaient des ventes chaque jour.
Ce genre d'histoire, je l'entends régulièrement. Les balises hreflang ont la réputation d'être techniques, obscures, réservées aux grands sites e-commerce internationaux. En réalité, dès que vous gérez deux versions linguistiques d'un même contenu, vous êtes concerné. Et la plupart des sites que j'audite les implémentent mal, ou pas du tout.
Points clés à retenir
- hreflang sert à indiquer à Google quelle version linguistique ou régionale montrer à quel utilisateur
- La règle de réciprocité est obligatoire : chaque page doit pointer vers toutes les autres, y compris vers elle-même
- Un hreflang mal configuré est pire que pas de hreflang du tout
- Trois méthodes d'implémentation existent : balise HTML, en-tête HTTP, sitemap XML
- x-default couvre les utilisateurs dont la langue ne correspond à aucune version
- Le multirégional sans différence de langue nécessite aussi hreflang
Quand la balise hreflang devient vraiment nécessaire (et quand elle ne l'est pas)
La question qu'on me pose le plus souvent n'est pas "comment" mais "est-ce que j'en ai besoin". Franchement, la réponse tient en une phrase : si vous avez plusieurs URL qui affichent le même contenu dans des langues différentes, oui. Sinon, non.
Les trois situations qui déclenchent le besoin
Première situation : vous proposez votre site en français et en anglais sur deux URL distinctes. C'est le cas classique du site multilingue. Google doit comprendre que monsite.fr/services et monsite.com/en/services sont la même page dans deux langues.
Deuxième situation : vous ciblez plusieurs pays qui partagent la même langue. Le français de France, du Québec et de Belgique. Le contenu est quasi identique, mais les prix, les unités ou les mentions légales diffèrent. Hreflang permet d'envoyer chaque visiteur vers la bonne version.
Troisième situation, plus subtile : vous avez un site en anglais britannique et un autre en anglais américain. Même langue, orthographes différentes, références culturelles distinctes. Sans hreflang, Google choisit à votre place. Et il choisit souvent mal.
Quand hreflang ne sert à rien
Si vos versions linguistiques sont déjà séparées par une structure que Google comprend sans ambiguïté, hreflang apporte peu. Je pense aux ccTLD comme .fr ou .de quand il n'existe aucune version concurrente dans une autre langue sur le même marché. Google s'en sort seul.
Autre cas : un site monolingue. Aucun intérêt. J'ai vu des agences facturer l'ajout de hreflang sur des sites en une seule langue. C'est du remplissage de devis, rien d'autre.
Et le troisième cas, celui qui fâche : quand vous dupliquez volontairement du contenu pour capter du trafic sur des requêtes quasi identiques. Hreflang n'est pas un outil de cloaking. Il ne vous sauvera pas d'une mauvaise stratégie éditoriale.
Comment implémenter hreflang correctement
Trois méthodes existent. Aucune n'est meilleure dans l'absolu. Le choix dépend de votre infrastructure et de votre capacité à maintenir le bazar.
La balise link dans le code HTML
C'est la méthode la plus courante. Vous ajoutez dans le <head> de chaque page une série de balises qui pointent vers toutes les versions, y compris elle-même :
<link rel="alternate" hreflang="fr-fr" href="https://monsite.fr/services" />
<link rel="alternate" hreflang="fr-ca" href="https://monsite.fr/ca/services" />
<link rel="alternate" hreflang="en" href="https://monsite.com/en/services" />
<link rel="alternate" hreflang="x-default" href="https://monsite.com/services" />
La règle de réciprocité saute aux yeux : chaque page doit lister toutes les autres, et elle-même. J'ai audité un site l'an dernier où la version allemande pointait vers la française, mais l'inverse n'était pas vrai. Résultat : Google ignorait tout le bloc. Une seule balise manquante et l'ensemble du groupe tombe.
L'en-tête HTTP
Utile pour les fichiers PDF, les documents non-HTML, ou quand vous ne pouvez pas toucher au template. L'en-tête Link fonctionne comme la balise HTML, mais passe par le protocole HTTP. Je l'utilise rarement, franchement. La maintenance est pénible et le débogage infernal.
Le sitemap XML
Pour les gros sites, c'est la méthode la plus propre. Vous déclarez toutes les correspondances dans un fichier unique :
<url>
<loc>https://monsite.fr/services</loc>
<xhtml:link rel="alternate" hreflang="fr-fr" href="https://monsite.fr/services" />
<xhtml:link rel="alternate" hreflang="en" href="https://monsite.com/en/services" />
</url>
Avantage : vous gérez tout au même endroit. Inconvénient : une erreur dans le sitemap affecte des milliers d'URL d'un coup. Sur un projet e-commerce à 12 000 références, j'ai mis deux jours à corriger une inversion de codes pays. Deux jours.
Comparaison des trois méthodes d'implémentation
| Critère | Balise HTML | En-tête HTTP | Sitemap XML |
|---|---|---|---|
| Maintenance | Manuelle, page par page | Complexe, souvent oubliée | Centralisée |
| Débogage | Simple avec les outils du navigateur | Difficile, nécessite curl | Moyen, validation XML requise |
| Idéal pour | Sites de 10 à 500 pages | Fichiers non-HTML (PDF) | Sites de plus de 500 pages |
| Risque d'erreur | Élevé si fait à la main | Très élevé | Faible si généré automatiquement |
Les codes langue et région : la source d'erreurs numéro un
ISO 639-1 pour la langue, ISO 3166-1 Alpha 2 pour la région. En théorie, c'est simple. En pratique, c'est là que tout le monde se plante.
Quelques règles que je répète à chaque audit :
- La langue se met toujours en minuscules :
fr,en,de - La région se met toujours en majuscules :
FR,GB,US - Un code langue seul (
en) cible tous les anglophones du monde - Un code langue-région (
en-GB) cible spécifiquement les utilisateurs britanniques - Le code
x-defaultsert de version de secours quand aucune autre ne correspond - Ne jamais utiliser de code pays seul :
hreflang="FR"ne veut rien dire
J'ai vu un développeur écrire hreflang="fr-FR" avec un underscore. Google ne bronche pas, il ignore simplement la balise. Et vous ne le savez jamais, parce qu'aucune erreur n'apparaît nulle part. C'est ce qui rend hreflang si traitre.
Les erreurs qui plombent le plus de sites
Oublier la réciprocité
La page A pointe vers B, mais B ne pointe pas vers A. Google considère le signal comme non fiable et l'écarte. La réciprocité n'est pas une recommandation, c'est une obligation technique.
Utiliser des URL relatives
/en/services au lieu de https://monsite.com/en/services. Les balises hreflang exigent des URL absolues. Relatives, elles sont ignorées silencieusement.
Entrer en conflit avec la balise canonical
Si votre canonical pointe vers une autre URL que celle déclarée dans hreflang, Google reçoit deux messages contradictoires. Il tranche et souvent pas en votre faveur. Les deux balises doivent désigner la même URL pour chaque version.
Déclarer hreflang entre des pages au contenu trop différent
Deux pages qui partagent le même hreflang doivent avoir un contenu équivalent, juste traduit. Si la version française parle de vos services à Paris et la version anglaise d'autre chose, hreflang n'a rien à faire là. Google risque de considérer la manipulation.
Comment vérifier que vos balises fonctionnent
Search Console remonte les erreurs hreflang dans le rapport "International Targeting". C'est le point de départ, pas la solution. Il détecte les manques de réciprocité, les codes invalides, les conflits avec canonical.
Pour aller plus loin, j'utilise systématiquement deux vérifications manuelles :
- J'ouvre chaque version linguistique dans un onglet séparé et je compare les blocs hreflang ligne par ligne
- Je simule un crawl avec l'user-agent Googlebot sur une URL par groupe, pour vérifier que les balises sont bien servies et non injectées en JavaScript côté client
Ce dernier point est crucial. Les balises hreflang injectées dynamiquement en JavaScript après le chargement de la page sont souvent invisibles pour Google. Si votre CMS les ajoute en client-side, vous perdez vos signaux. C'est une erreur que j'ai commise sur un projet Shopify il y a quelques années, et j'ai mis un mois à comprendre pourquoi le trafic allemand plafonnait.
Ce qu'il faut vraiment garder en tête
Hreflang n'est pas une option. C'est un signal que vous envoyez à Google, et ce signal est soit cohérent, soit contre-productif. Il n'y a pas de demi-mesure.
La vraie question n'est pas "comment écrire la balise" mais "qui va la maintenir dans six mois". Sur les projets où j'interviens, la majorité des erreurs ne viennent pas d'une mauvaise compréhension technique. Elles viennent de l'oubli. Un nouveau produit lancé, une nouvelle langue ajoutée, et personne ne pense à mettre à jour les correspondances.
La solution que je recommande systématiquement : automatiser la génération hreflang à partir d'une source unique de vérité, que ce soit un sitemap généré ou un fichier de configuration centralisé. Écrire les balises à la main sur 200 pages, c'est garantir une erreur sur 20.
Et si vous ne devez retenir qu'une chose de cet article : testez. Pas dans un an. Maintenant. Parce que pendant que vous lisez ces lignes, un utilisateur germanophone cherche peut-être votre service en français.
