Hreflang : la non-réciprocité, clé de la bonne langue dans Google

Google affiche parfois la mauvaise langue dans ses résultats, alors que le site propose bien trois versions. Le réflexe consiste à accuser l’algorithme, mais le coupable se trouve le plus souvent dans les balises hreflang : une non-réciprocité, une URL de retour non canonique ou un code de langue invalide suffisent à brouiller le signal. L’erreur ne se corrige pas en ajoutant des balises au hasard. Elle se traite par un audit ordonné, en commençant par le défaut le plus fréquent. Voici la méthode qui a sorti un site industriel trilingue de ce piège en six semaines.

Le mauvais affichage vient d’un signal cassé, pas d’un caprice de Google

Quand Google affiche la version anglaise à un utilisateur qui cherche en français, le premier réflexe est d’incriminer l’algorithme. Pourtant, les résultats localisés s’appuient sur des signaux que le site envoie lui-même, et les balises hreflang en font partie.

Une balise hreflang mal construite ne dit pas « cette page existe en allemand », elle dit plutôt une information contradictoire que Google préfère ignorer. Le moteur retombe alors sur une URL qui n’a pas la bonne langue, et l’erreur devient visible dans les SERP. Ce n’est pas un problème de confiance, c’est un problème de propreté du jeu de données.

Sur un site international qui s’étend sur trois langues, les audits font ressortir la même accumulation : des balises qui pointent vers des pages non canoniques, des codes de langue qui n’existent pas dans la norme ISO, et des déclarations croisées incomplètes. La correction ne passe pas par l’ajout de nouvelles balises, mais par la suppression des signaux contradictoires. C’est là que l’ordre d’audit change tout, car traiter un code invalide avant une non-réciprocité ne résout pas le brouillage initial.

La réciprocité se vérifie avant toute autre chose

La non-réciprocité est l’erreur numéro un que Screaming Frog remonte sur les sites internationaux. Concrètement, si la page française déclare une équivalente anglaise, la page anglaise doit déclarer en retour la page française, avec exactement la même URL, et toute variation même mineure dans le chemin, les paramètres ou la casse suffit à casser la correspondance.

Dès qu’une des deux directions manque, Google considère la paire comme fragile et peut choisir une autre page à afficher. Ce défaut ne se voit pas à l’œil nu sur le site, mais il se détecte très vite avec un crawler.

Un cas fréquent : la version anglaise renvoie vers une URL française qui redirige vers autre chose, ou qui contient un paramètre de suivi. La réciprocité est alors techniquement présente, mais inutile, car le retour ne pointe pas vers la page déclarante.

On croit avoir corrigé, et le problème persiste. C’est pour ça que l’audit commence par vérifier, pour chaque paire, que la balise de retour pointe bien vers l’URL d’origine, sans variation de casse ni slash final manquant.

Les profils d’erreurs que l’audit fait remonter

Un crawler configuré pour les hreflang passe en revue chaque paire de pages et classe les défauts rencontrés. Il en ressort des répétitions assez typiques, qui ne se limitent jamais à une page isolée et qui touchent souvent des modèles entiers.

• Une balise de retour pointe vers une autre URL que celle qui a émis le signal.
• Des versions linguistiques entières sans aucune réciprocité croisée.
• Pourquoi la balise auto-référente manque-t-elle sur les pages d’accueil des trois langues ?
• Un groupe de pages qui renvoie vers une combinaison langue-pays inexistante.
• Des paramètres d’URL non canoniques utilisés comme cible de retour.

Ces schémas ne demandent pas tous le même traitement. Certains se corrigent en quelques clics dans le header, d’autres imposent de reprendre les modèles de pages. L’important est de ne pas noyer l’équipe dans une liste de centaines d’alertes sans hiérarchie.

Car la priorité reste la réciprocité sur les pages qui génèrent du trafic organique. Sur ce point, voir aussi notre article sur combien de temps faut-il pour constater les premiers résultats d’un référencement naturel à Lyon ?.

Canoniques et codes se règlent une fois la réciprocité stabilisée

Une balise hreflang doit pointer vers la cible canonique indexable finale, celle qui renvoie un code HTTP 200. Si elle vise une URL qui redirige, qui renvoie une 404 ou qui porte un attribut canonical vers une autre adresse, le signal devient incohérent. Google ne suit pas une piste qui change de destination en cours de route. On vérifie donc chaque cible avec un simple test de statut HTTP, avant de valider la correction.

Les codes de langue et de pays utilisés dans les balises hreflang doivent être des codes officiels à deux lettres. Un code régional inventé, une inversion entre langue et pays, ou un format sur trois lettres empêche Google d’associer la page à la bonne version. La norme ISO ne laisse aucune place à l’approximation, et c’est souvent sur ce point que les fiches produit se multiplient avec des valeurs incohérentes. Un contrôle systématique des valeurs autorisées évite des corrections inutiles.

Deux publications récentes vont dans le même sens sans donner le même degré de détail opérationnel. Julien Larzillière a publié l’article « Hreflang : les 8 erreurs qui sabotent un site multilingue » le 7 août 2026, pour 10 minutes de lecture.

Elizabeth Pokorny a mis à jour le guide « Un guide complet pour résoudre le problème « Votre site n’a pas de balises Hreflang » » le 10 août 2026. Ces deux textes listent les pièges, mais ne hiérarchisent pas les corrections par impact comme le fait un audit de terrain.

Ce qu’un site trilingue a corrigé en six semaines

L’exemple le plus parlant vient d’une ETI industrielle dont le cas est cité dans un article de Semsew. Le site comptait environ 900 URL par langue, réparties entre le français, l’anglais et l’allemand. La mauvaise langue s’affichait sur des requêtes commerciales à fort volume, et les équipes pensaient à un mauvais paramétrage de la Search Console. Après un premier audit, la cause principale est apparue : des balises hreflang croisées sur un tiers du maillage, avec des retours non canoniques.

La correction a suivi l’ordre exact dont on a parlé. D’abord, la réciprocité a été rétablie sur toutes les paires de pages, en supprimant les URL avec paramètres. Ensuite, chaque cible hreflang a été comparée à la canonique réelle de la page.

Enfin, les codes de langue ont été remis au format officiel sur deux lettres. La disparition de la mauvaise langue dans les résultats Google a pris six semaines, pas moins. Pour reproduire ce type de contrôle, un outil comme mystpi.com regroupe les vérifications nécessaires sur l’ensemble d’un site.

La durée de six semaines ne tient pas à la complexité des balises, mais au temps de recrawl des pages corrigées. Google ne redécouvre pas instantanément les nouveaux signaux, surtout quand le site a un maillage étendu. C’est une raison de plus pour ne pas laisser traîner une non-réciprocité détectée : plus on attend, plus la fenêtre de mauvaise langue reste visible dans les résultats.

L’ordre de vérification n’est pas un détail

Corriger une erreur hreflang ne suffit pas si l’on ne traite pas d’abord la non-réciprocité, puis les canoniques, puis les codes de langue. Ce classement par impact évite de gaspiller des jours sur des détails qui ne lèveront pas le brouillage principal.

Un site international peut continuer à afficher la mauvaise langue tant qu’une seule paire critique reste incohérente. La méthode décrite ici a fait ses preuves sur un site trilingue, mais elle s’applique à tout projet multilingue. Est-ce que votre prochain audit commencera par la réciprocité ?