L’attribut hreflang indique à Google quelle version linguistique ou régionale d’une page proposer à un internaute donné. Mal implémenté, il ne provoque presque jamais d’erreur visible : les pages continuent de s’indexer, le site continue de fonctionner, et c’est précisément ce qui rend le problème difficile à repérer. Les symptômes réels, perte de trafic sur une version linguistique, mauvaise page proposée dans les résultats, n’apparaissent souvent que plusieurs semaines après la mise en ligne d’un site multilingue.
Ce que fait réellement hreflang, et ce qu’il ne fait pas
hreflang ne traduit rien et ne redirige personne automatiquement. Il se contente de déclarer des relations entre URL : « cette page en français a un équivalent en anglais à telle adresse, un équivalent en espagnol à telle autre ». Google utilise ensuite cette information pour choisir quelle URL afficher selon la langue et la localisation de recherche de l’internaute. Sans hreflang, un site multilingue reste indexable, mais Google doit deviner la bonne version à proposer, et se trompe plus souvent qu’on ne le pense sur les pages à fort trafic international.
Les erreurs les plus fréquentes
La plupart des problèmes hreflang relevés sur des sites en production tiennent à une poignée de causes récurrentes.
| Erreur | Symptôme observé | Cause typique | Correction |
|---|---|---|---|
| Balises non réciproques | Search Console signale une « erreur de retour » (return tag) | La page B pointe vers A, mais A ne pointe pas vers B | Générer les balises par paire, jamais à la main page par page |
| Code de langue invalide | Google ignore la balise sans erreur explicite | Utilisation d’un code pays seul (« fr-FR » mal formé) ou d’un code fantaisiste | Respecter ISO 639-1 pour la langue, ISO 3166-1 pour la région, dans cet ordre |
| Absence de x-default | Mauvaise version proposée aux internautes hors des langues couvertes | Aucune page de repli déclarée | Ajouter une balise hreflang="x-default" vers la version générique ou la page de sélection de langue |
| URL non canoniques dans hreflang | Conflit entre balise canonical et balise hreflang | Les URL de hreflang pointent vers des versions avec paramètres ou non canoniques | N’utiliser que les URL canoniques exactes, telles qu’indexées |
| Incohérence sitemap / balises HTML | Certaines pages traitées correctement, d’autres non, sans logique apparente | Les deux mécanismes déclarent des relations différentes | Choisir une seule méthode d’implémentation par site, jamais les deux à la fois |
Google ignore silencieusement les balises hreflang mal appariées, sans provoquer d’erreur visible dans Search Console avant plusieurs semaines.
Auditer un site existant
Le rapport « Ciblage international » de Search Console reste le point de départ le plus fiable : il liste les erreurs de retour détectées sur un échantillon de pages. Il ne couvre toutefois pas l’intégralité du site, et son délai de mise à jour peut dépasser une semaine. Pour un audit complet, un crawl technique (Screaming Frog, Sitebulb, ou un script maison) reste nécessaire : il permet de vérifier, URL par URL, que chaque relation hreflang est bien réciproque et que les codes de langue sont valides.
Cette lenteur de détection rejoint un problème plus large de pilotage : sans tableau de bord régulier croisant indexation et performance par langue, une erreur hreflang peut rester invisible des mois. Mettre en place un pilotage GA4 et Search Console segmenté par langue permet de repérer rapidement une chute de trafic localisée sur une seule version du site, signe fréquent d’un souci hreflang plutôt que d’une baisse générale de visibilité.
Implémenter hreflang correctement
Deux méthodes coexistent : les balises <link> dans le <head> de chaque page, ou une déclaration dans le sitemap XML. La seconde est préférable sur les sites volumineux, car elle évite d’alourdir chaque page et centralise les relations dans un seul fichier à maintenir.
<!-- Dans le head de la page française -->
<link rel="alternate" hreflang="fr" href="https://exemple.com/fr/guide-hreflang/" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en/hreflang-guide/" />
<link rel="alternate" hreflang="es" href="https://exemple.com/es/guia-hreflang/" />
<link rel="alternate" hreflang="de" href="https://exemple.com/de/hreflang-leitfaden/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />
<!-- Déclaration équivalente dans le sitemap XML -->
<url>
<loc>https://exemple.com/fr/guide-hreflang/</loc>
<xhtml:link rel="alternate" hreflang="en"
href="https://exemple.com/en/hreflang-guide/" />
<xhtml:link rel="alternate" hreflang="es"
href="https://exemple.com/es/guia-hreflang/" />
<xhtml:link rel="alternate" hreflang="x-default"
href="https://exemple.com/" />
</url>
Outils de contrôle, au-delà de Search Console
Search Console reste insuffisant pour un contrôle régulier, par son périmètre d’échantillonnage et son délai de traitement. En complément, trois types d’outils couvrent l’essentiel des besoins d’une équipe technique :
Un crawler SEO classique (Screaming Frog, Sitebulb) intègre un onglet dédié qui liste automatiquement les balises hreflang non réciproques, les codes de langue invalides et les pages sans auto-référence, sur l’intégralité du site plutôt que sur un échantillon. Pour les sites qui publient plusieurs fois par jour, un script de contrôle exécuté en intégration continue détecte les régressions avant la mise en production, plutôt que plusieurs semaines après via Search Console. Enfin, l’outil de test hreflang de Merkle (technicalseo.com) reste une référence pour vérifier manuellement un petit nombre d’URL sans dépendre d’un crawl complet.
Un scénario fréquent : l’ajout d’une langue après coup
La majorité des erreurs hreflang constatées en audit n’apparaissent pas au lancement d’un site multilingue, mais au moment d’ajouter une langue supplémentaire à un site qui en comptait déjà deux ou trois. Le schéma se répète : une équipe ajoute l’allemand à un site franco-anglo-espagnol, mais le script ou la configuration qui génère les balises hreflang n’a été pensé que pour trois langues. Les nouvelles pages allemandes existent, s’indexent, mais n’apparaissent dans aucune balise hreflang des pages existantes, et leurs propres balises pointent vers des URL qui, elles, ne les référencent pas en retour. Le résultat est une erreur de retour sur l’intégralité des nouvelles pages, invisible tant que personne ne relance un audit complet.
La parade est moins une question d’outillage que de process : traiter toute addition de langue comme un changement de schéma de données plutôt que comme l’ajout d’un contenu isolé, et relancer systématiquement un crawl complet du site après coup, pas seulement sur les nouvelles pages.
Le cas des CMS multilingues
Sur WordPress, les extensions de gestion multilingue (Polylang, WPML) génèrent en général les balises hreflang automatiquement à partir des traductions liées en base, ce qui évite l’essentiel des erreurs manuelles. Le risque se déplace alors vers la configuration : une rubrique ou une catégorie non traduite peut casser la chaîne de liaison, et republier un article dans une langue par défaut sans repasser par le mécanisme de traduction du thème produit souvent une page orpheline, sans aucune balise hreflang pointant vers elle. Le choix du CMS et de son architecture multilingue mérite d’être tranché en amont du projet ; le guide de choix d’un CMS détaille les critères à considérer avant d’ajouter une couche de traduction à un site existant.
Ce qu’il faut retenir
hreflang ne pardonne pas l’approximation : une balise orpheline ou un code de langue mal formé n’empêche rien de fonctionner, mais prive silencieusement une partie de l’audience international de la bonne version du site. Un audit régulier, une implémentation unique par site (HTML ou sitemap, pas les deux) et une auto-référence systématique couvrent l’essentiel des cas rencontrés en production.
Sur la quasi-totalité des audits multilingues qui atterrissent sur mon bureau, le problème ne vient jamais d’un manque de volonté, mais d’un oubli au moment d’ajouter une cinquième langue à un site qui en avait deux au départ. Le script de génération des balises n’a pas été mis à jour, et personne ne s’en aperçoit avant une baisse de trafic sur la nouvelle version. Mon réflexe : traiter hreflang comme du code, avec un test automatisé qui vérifie la réciprocité des balises à chaque déploiement, plutôt que comme une case à cocher dans un plugin. — Simon Janvier
Pour aller plus loin : la documentation officielle de Google sur les versions localisées et hreflang.
