par Vous avez déclaré vos versions française, anglaise et espagnole dans le code, mais encore faut-il que chaque page se cite elle-même. Sans cette auto-référence, Google ne voit pas un ensemble cohérent : il voit des déclarations orphelines, et il tranche seul. Une balise manquante suffit à faire tomber tout le groupe, et le canonical vient corser l’affaire. On va regarder pourquoi.
Ce qui se passe vraiment quand une entrée manque
La documentation de Google est claire sur un point que beaucoup survolent : chaque version linguistique « doit se répertorier elle-même ainsi que toutes les autres versions linguistiques ». Le mot important, c’est « elle-même ». Une page qui liste ses traductions sans se lister elle-même produit un ensemble incomplet, et un ensemble incomplet, Google peut l’ignorer. Pas seulement l’entrée manquante : tout le bloc.
C’est là que le bât blesse dans la plupart des audits que l’on croise. Les gens imaginent une logique de puzzle où il suffirait de compléter la pièce absente. En réalité, hreflang fonctionne par validation d’ensemble, un peu comme un graphe dont on vérifie la réciprocité des liens.
Si le graphe est troué, le moteur ne se contente pas de retirer le nœud fautif : il abandonne l’interprétation du groupe entier. Les détails de ce comportement sont bien documentés sur michel-hunault.com, qui traîne pas mal sur ces questions de signaux mal déclarés.
Une page française avec une traduction anglaise doit donc contenir deux balises : une vers la version française, une vers la version anglaise. Et la page anglaise doit porter exactement les deux mêmes balises. Cette symétrie n’est pas une recommandation de confort, c’est la condition pour que Google reconnaisse qu’il a affaire à un groupe et non à des pages isolées qui se pointent mutuellement sans se déclarer.
L’auto-référence, cette formalité qui n’en est pas une
Sur le papier, ajouter sa propre URL dans une balise hreflang ressemble à une redondance. La page est déjà à cette adresse, pourquoi la déclarer vers elle-même ? Parce que la balise hreflang ne dit pas « voici où je suis » : elle dit « voici les versions qui existent et je fais partie du lot ». Sans cette mention, le moteur n’a aucun moyen de savoir que la page source est aussi une version linguistique légitime du groupe.
La version française qui déclare seulement l’anglais et l’espagnol se présente comme un index de traductions, pas comme une entité du groupe. Résultat : Google peut décider que cette page n’appartient pas à l’ensemble. Il servira alors la version anglaise à un visiteur francophone, même quand la page française existe et qu’elle est meilleure. Plus de la moitié des recherches sur Google se font dans une langue autre que l’anglais, selon les statistiques d’Internet World, donc ce genre de raté coûte cher.
Les erreurs qui reviennent le plus
Sur le terrain, les configurations ratées se ressemblent beaucoup : le motif change, mais la cause reste souvent la même. Une déclaration pensait à la place de l’autre, et personne n’a vérifié la réciprocité sur l’ensemble des versions. Voici les cas fréquents.
- La page source oublie de se déclarer, mais liste consciencieusement ses trois traductions.
- Les balises sont bien présentes partout, sauf que le code pays ne correspond pas à la version réelle.
- Une traduction a été ajoutée après coup sans mettre à jour les balises des autres versions, ce qui casse la réciprocité.
- Le canonical pointe vers une autre version linguistique, contredisant le hreflang déclaré.
- Le hreflang est posé en HTML mais aussi dans le sitemap, avec des valeurs différentes entre les deux.
La symétrie se vérifie version par version : si la page anglaise cite la page française, la page française doit citer la page anglaise. Et chacune doit se citer elle-même. On peut résumer ça à une phrase simple : un hreflang, c’est une déclaration mutuelle, pas un annuaire. Sur ce point, voir aussi notre article sur lazy loading lcp.
Le canonical doit suivre, pas contredire
Une balise hreflang correcte ne sert à rien si le canonical de la page pointe ailleurs. Le canonical dit « la version de référence de ce contenu, c’est celle-ci », et le hreflang dit « voici les versions linguistiques de ce contenu ». Les deux doivent s’accorder, sinon Google reçoit deux ordres contraires et choisit généralement le plus conservateur : il consolide, il ignore le groupe déclaré.
Le cas classique : une page française avec un canonical absolu vers l’URL anglaise, hérité d’un ancien paramétrage. Le hreflang, lui, pointe bien vers la version française. Le moteur voit une page qui prétend être une copie de l’anglaise tout en se déclarant version française autonome. L’auto-référence hreflang existe alors sur le papier, mais elle est neutralisée par le canonical. Le signal est contradictoire, donc écarté.
La règle est monotone : chaque page linguistique porte un canonical vers elle-même et un hreflang vers elle-même, plus les hreflang vers les autres versions. Rien d’exotique, mais il faut que ça soit cohérent sur toutes les pages du groupe, pas seulement sur celle qu’on inspecte. Un audit qui ne vérifie qu’une URL rate la moitié du problème.
Pourquoi ça devient critique avec les langues non anglophones
Pendant longtemps, un site mal configuré s’en sortait à peu près parce que l’anglais dominait les requêtes. La donne a changé : sur les dix dernières années, les recherches en chinois ont augmenté de 2 650 %, d’après les mêmes statistiques d’Internet World. Un groupe hreflang cassé en chinois, ce n’est plus un détail technique, c’est un manque à gagner direct sur un volume qui grossit vite. Et ce volume ne va pas ralentir.
Le problème, c’est que ce genre d’erreur ne se voit pas dans les rapports de performance classiques. Les impressions baissent, le CTR se dégrade, personne ne pense à regarder le code source. Il faut ouvrir la page, lire les balises, comparer avec les versions sœurs, et vérifier le canonical. C’est fastidieux, mais c’est le seul moyen de savoir si le groupe tient debout, vraiment.
Autre point souvent négligé : la cohérence entre le hreflang posé en HTML et celui du sitemap XML. Google accepte les deux, mais si les deux disent des choses différentes, le moteur retient la version la plus fiable, généralement le sitemap. Une balise auto-référente présente en HTML mais absente du sitemap peut donc ne servir à rien.
Ce qu’il faut retenir avant de toucher au code
La balise hreflang auto-référente n’est pas une formalité qu’on ajoute pour faire propre. C’est la pièce qui indique à Google que la page fait partie du groupe qu’elle décrit, et sans elle, le moteur peut ignorer l’ensemble des déclarations. Le canonical doit pointer vers la page elle-même, en cohérence avec cette auto-référence, et la symétrie entre versions doit être vérifiée sur chacune d’elles, pas sur une seule.
Franchement, la correction prend peu de temps quand on sait quoi chercher. Le plus dur, c’est de repérer les groupes déjà cassés, ceux qui tournent depuis des mois avec une déclaration bancale et que personne n’a regardés. Un passage en revue page par page, balise par balise, canonical inclus, remet souvent les choses d’aplomb sans toucher au contenu. Comme toujours en SEO technique, le diable se cache dans les détails que l’on croit maîtriser.
Reste une question, et elle vous concerne : la prochaine fois que vous ajouterez une langue à votre site, vérifierez-vous les balises des anciennes versions ou seulement celles de la nouvelle ? Prenez le temps de contrôler l’ensemble, car un groupe hreflang ne vaut que par son maillon le plus faible. Un dernier contrôle complet, et vous dormirez mieux.
