Sept versions de langue en moyenne pour un site multilingue. Voilà le chiffre que cite SEMrush dans une recherche publiée le 15 février 2017 par Elena Terenteva, et il dit beaucoup sur l’ampleur du chantier. Chaque version doit pointer vers les six autres, chaque retour doit être réciproque, chaque canonical doit raconter la même histoire. Une seule erreur de hreflang paraît anodine sur le papier. Dans les faits, elle fragilise souvent tout l’édifice : Google cesse de comprendre le groupe, et les versions locales perdent leur chance d’apparaître dans les bons résultats de recherche.
Pourquoi le hreflang n’est pas qu’un simple attribut technique
Le hreflang ressemble à une formalité : on ajoute une balise, on indique la langue, on passe à autre chose. Pourtant, Google précise que les versions localisées d’une page ne sont considérées comme des doublons que si le contenu principal n’est pas traduit.
Autrement dit, le hreflang n’est pas un signal secondaire qui viendrait décorer une page : c’est lui qui permet au moteur de distinguer une vraie version locale d’un simple duplicata oublié sur un sous-dossier. Quand l’annotation manque ou se contredit, Google retombe sur une lecture par défaut, souvent défavorable au site qui pensait avoir tout bien fait.
Le vrai sujet n’est donc pas la syntaxe d’une balise, mais la cohérence d’un réseau de pages qui se répondent. Jérémy Chomel, cofondateur de Dawap, le formule avec une netteté qui mérite qu’on s’y arrête : une seule relation non réciproque ou une canonical contradictoire peut rendre tout un groupe international incohérent. Cette idée change la manière d’auditer un site multilingue. On ne corrige plus une erreur isolée, on vérifie que l’ensemble raconte la même structure, version après version, langue après langue.
La relation non réciproque, le poison silencieux des groupes multilingues
Imaginons une page en français qui annonce une version anglaise avec un hreflang vers example.com/en/. La version anglaise, elle, renvoie vers example.com/ sans préciser la langue, ou pire, vers une autre URL que celle attendue. Le lien est rompu.
Google reçoit une déclaration à sens unique, et son traitement est sans pitié : il ignore l’annotation, parfois sur tout le groupe de pages concerné. Cette non-réciprocité est d’autant plus pernicieuse qu’elle survient souvent après une refonte, quand une ancienne URL reste indiquée dans certaines versions et pas dans d’autres.
Le problème, c’est que rien ne clignote dans la Search Console. Aucune alerte ne vient dire « votre hreflang est cassé sur trois versions ». Il faut ouvrir les pages une à une, comparer les balises, tracer chaque relation. Et c’est là que la plupart des audits s’arrêtent trop tôt : on vérifie la présence des balises, pas leur symétrie. Or une moitié de relation est exactement aussi utile qu’une moitié de pont.
Quand la canonical contredit le hreflang
La balise canonical indique la page de référence d’un contenu. Le hreflang indique les variantes linguistiques de ce contenu. Quand les deux se contredisent, Google tranche, et rarement en faveur du site. Prenons un cas concret : la page allemande example.com/de/produkt porte une canonical vers example.com/de/, tandis que son hreflang pointe vers example.com/fr/produit comme équivalent français. La canonical dit « cette page n’est pas la version canonique du produit », le hreflang dit « cette page est la version allemande du produit ». Ces deux affirmations ne peuvent pas être vraies en même temps.
Google recommande d’utiliser des URL absolues, des canonical auto-référentes et des liens bidirectionnels entre versions pour que les annotations hreflang puissent être utilisées correctement. La canonical auto-référente est un point souvent négligé : chaque version locale doit se désigner elle-même comme sa propre page de référence. Dès qu’une page en désigne une autre, elle se retire du jeu, et c’est tout son réseau hreflang qui perd un maillon. La contradiction n’a même pas besoin d’être massive pour produire cet effet.
Ce que les listes d’erreurs classiques ne disent pas
La plupart des contenus sur le hreflang recensent les mêmes fautes : balise mal placée, code langue invalide, URL relative au lieu d’absolue, oubli du x-default. Ces listes sont utiles, mais elles traitent le symptôme. L’erreur la plus coûteuse n’est pas celle qu’on voit en relisant le code source : c’est l’incohérence invisible qui naît d’une interaction entre deux signaux que l’on croyait indépendants.
Google indique que trois méthodes permettent d’indiquer des variantes de pages : le HTML, les en-têtes HTTP et le sitemap. Et il précise que ces trois méthodes sont équivalentes de son point de vue, sans avantage à les utiliser toutes simultanément.
Cette précision devrait suffire à calmer bien des réflexes. Combien d’équipes ajoutent le hreflang dans le HTML, puis dans le sitemap XML, puis dans les en-têtes HTTP, en pensant renforcer le signal ? En réalité, cette triple déclaration ne renforce rien du tout.
Pire, elle multiplie les surfaces où une incohérence peut apparaître : on met à jour le sitemap mais pas les balises HTML, on modifie une règle serveur sans toucher au XML. Le résultat n’est pas une meilleure indexation, c’est un terrain plus vaste pour les contradictions.
Franchement, la meilleure approche consiste à choisir une seule méthode et à s’y tenir, en documentant clairement où vivent les annotations. Une vérification de cohérence ne prend que quelques minutes quand on sait où chercher : il suffit de remonter chaque relation déclarée et de vérifier son retour. C’est un travail de comptable, pas de développeur. Mais c’est ce travail-là qui fait la différence entre un site multilingue visible et un site multilingue fantôme.
Les points de contrôle qui révèlent une incohérence globale
Pour vérifier qu’un groupe international tient debout, quelques points de contrôle suffisent. Ils ne demandent pas d’outil particulier, juste de la méthode. Voici ce qu’il faut examiner :
- Chaque URL déclarée en hreflang existe-t-elle vraiment et répond-elle avec un code 200 ? Une URL qui redirige ou renvoie une erreur casse la relation avant même qu’elle soit lue.
- Pour chaque paire de langues, la relation est-elle bien réciproque dans les deux sens ? C’est le test le plus révélateur d’un groupe cohérent.
- La canonical de chaque version locale pointe-t-elle vers elle-même, ou vers une autre page ?
- Le sitemap ou les en-têtes HTTP ne racontent-ils pas une version différente de celle du HTML ? Une seule source devrait faire autorité.
- Que se passe-t-il pour la page d’accueil, souvent la plus chargée de variantes et la plus sujette aux oublis ?
Ce type de vérification s’apparente à une lecture croisée de documents comptables : on cherche la pièce manquante, le montant qui ne correspond pas, la ligne qui contredit le total. L’œil finit par repérer rapidement les endroits où les choses ne s’emboîtent pas. Et c’est exactement le regard que Google pose sur un site international, à une échelle que l’on a parfois du mal à imaginer.
Le hreflang est un système, pas une collection de balises
Le passage par les travaux de consultants comme philippe-larroche.fr le confirme : les erreurs de hreflang qui coûtent le plus cher ne se voient pas à l’œil nu. Elles se logent dans les relations entre les pages, dans la manière dont un groupe multilingue tient ou ne tient pas ensemble.
Vérifier la présence des balises ne suffit pas et n’a jamais suffi. Ce qui compte, c’est la cohérence du système, cette toile invisible qui relie chaque version locale aux autres et qui, dès qu’un fil casse, laisse Google face à un site illisible. Comment votre propre site multilingue se comporterait-il si l’on tirait sur un seul de ses fils ?
