Une balise hreflang mal renseignée ne casse pas seulement un lien. Elle dit à Google que la version française de votre page vit à une adresse qui n’existe plus, et le moteur le croit. Résultat : la page française, parfaitement valide, reste invisible dans les résultats. Le problème est rarement détecté parce que personne ne pense à vérifier les balises déjà en place, seulement celles qu’on ajoute. Voici comment repérer ce faux pas et pourquoi il coûte bien plus cher qu’un simple lien mort.
Une balise hreflang n’est pas un lien, c’est une instruction
La confusion vient de là. On lit une balise hreflang comme on lirait un href classique, en se disant qu’au pire le lien ne mènera nulle part. Sauf qu’une balise hreflang ne sert pas à naviguer : elle déclare à Google quelle URL sert quelle langue, et à quelle adresse le moteur doit aller chercher la variante.
Quand cette adresse renvoie une 404, Google enregistre une information fausse sur votre propre architecture. Vous pouvez poser toutes les balises propres du monde sur vos nouvelles pages, celles qui existent déjà peuvent pointer dans le vide depuis des mois sans que rien ne remonte dans la Search Console. Un audit technique sérieux, comme ceux que détaille mohedaltrad2020.fr, commence justement par relire l’existant avant d’ajouter quoi que ce soit.
Ahrefs classe ce type de problème dans la catégorie « 404 page » de son audit de site, qui regroupe les URL renvoyant un code d’état HTTP 404 – Non trouvé, autrement dit une page morte. Le rapport précise que le « 404 – Non trouvé » figure parmi les erreurs 4XX les plus fréquentes, tout simplement parce que la page visée n’existe pas.
Ce qui rend le cas plus vicieux qu’un lien cassé ordinaire, c’est que la balise, elle, existe bel et bien. Elle est présente dans le code, syntaxiquement correcte, et c’est précisément pour ça qu’elle passe sous le radar.
Pourquoi Google retire la page française de son index
Google n’indexe pas les URL qui renvoient une réponse 404 ou 410, c’est une règle de base. Si une URL déjà indexée se met à répondre 404, elle peut être retirée de l’index au fil du temps.
Dans notre scénario, l’URL visée par la balise n’a jamais été indexée puisqu’elle n’existe pas, mais le dégât se propage à la page valide qui pointe vers elle. Le moteur traite l’ensemble comme une grappe linguistique incohérente : la version anglaise déclare avoir une sœur française, cette sœur est introuvable, et la confiance accordée au groupe entier chute.
L’exemple documenté par LingoWp est limpide. La page anglaise /about/ s’ouvre correctement. L’alternative française indiquée dans la balise hreflang, /fr/about/, renvoie une 404. Et la vraie page française, celle qui fonctionne, vit à /fr/a-propos/.
Autrement dit, la page française existe, elle est en ligne, elle répond, mais personne ne lui a dit qu’elle était la version française de /about/. Google cherche /fr/about/, tombe sur une erreur, et considère la variante française comme non résolue.
Ce qui se passe ensuite est difficile à observer sans outil dédié, parce que rien ne s’effondre d’un coup. La page ne disparaît pas du jour au lendemain des résultats français. Elle perd des signaux, doucement, pendant que sa concurrente correctement déclarée prend la place. Le trafic baisse, on cherche la cause côté contenu ou côté mots-clés, et on passe à côté de la balise, qui n’a pourtant pas bougé depuis la refonte du site.
Les outils qui révèlent le problème
Screaming Frog dispose d’un rapport dédié, « Non-200 Hreflang URLs », qui rassemble exactement ces cas : des URL alternatives déclarées dans une balise mais indisponibles au moment du crawl. L’outil recommande de pointer vers des destinations canoniques et indexables, ce qui paraît évident une fois qu’on le lit, et qui échappe pourtant à la majorité des refontes. L’intérêt de ce rapport, c’est qu’il croise la déclaration et la réponse HTTP réelle, là où un simple audit de liens ne verrait rien puisque la balise, elle, n’est pas un lien cliquable. Sur ce point, voir aussi notre article sur page recule refonte visible.
Ahrefs, de son côté, recommande trois actions sur les pages 404 signalées : examiner tous les liens internes qui pointent vers elles et les supprimer, les remplacer par des liens vers des pages actives, ou poser des redirections 301 appropriées. Appliquez la même logique aux balises hreflang, et vous tenez la méthode.
Si l’ancienne URL /fr/about/ doit rester dans la balise pour une raison ou une autre, une 301 vers /fr/a-propos/ règle le problème proprement. Sinon, corrigez la balise elle-même pour qu’elle pointe directement vers l’adresse vivante.
Les cas de figure qui reviennent le plus
Les erreurs de ce type ne sortent pas de nulle part. Elles arrivent à des moments précis d’un projet, et une fois qu’on les connaît, on les repère en quelques minutes dans un crawl.
- Le site a été refait et les URL françaises ont changé, mais la balise hreflang n’a jamais suivi.
- La version linguistique a été supprimée ou fusionnée avec une autre.
- Une ancienne structure avec préfixe de langue a été abandonnée au profit d’un sous-domaine.
- Qui vérifie réellement les balises sur les pages anciennes lors d’un audit ?
- Un développeur a copié-collé un modèle de balise depuis une autre page sans ajuster l’adresse.
Le quatrième cas est probablement le plus fréquent, et personne ne veut l’entendre. On audite les nouvelles pages, on surveille les performances, on traque le First Input Delay, et l’existant reste en place jusqu’à ce qu’un rapport de crawl le remonte par accident. Ça dépend aussi de la taille du site : sur dix pages, un contrôle manuel suffit, sur trois cents, il faut un outil.
Ce qui se joue vraiment derrière une 404 déclarée
Un hreflang cassé ne coûte pas seulement la page visée, il fausse la lecture que Google fait de tout votre ensemble multilingue. Le moteur s’appuie sur ces balises pour comprendre la relation entre versions, et une relation pointant vers du vide affaiblit la confiance accordée aux autres déclarations. La version anglaise, correcte, se retrouve elle aussi dans un groupe incomplet. Si vous gérez plusieurs marchés, l’effet se cumule, et la perte devient difficile à attribuer à une cause unique.
Le vrai piège, c’est que la page française valide et bien indexée peut très bien continuer à recevoir du trafic tout en étant absente de la grappe linguistique. Elle existe pour Google, mais pas comme équivalent de la version anglaise.
Si quelqu’un tape une requête en français, le moteur peut choisir de servir la page anglaise plutôt que la française, faute de lien fiable entre les deux. La page perd sa raison d’être dans le mécanisme international, alors qu’elle est techniquement irréprochable.
Franchement, c’est ce décalage qui rend le diagnostic si long. On cherche un problème sur la page qui ne marche pas, et la panne est sur une autre page, dans une balise, sur une ligne que personne n’a relue depuis la dernière refonte.
Reprendre la main sur l’existant avant d’ajouter quoi que ce soit
La marche à suivre tient en peu de choses. Lancez un crawl complet, ouvrez le rapport des URL hreflang non-200, et traitez chaque ligne une par une. Pour chacune, deux questions : la page cible existe-t-elle ailleurs dans le site ? Si oui, corrigez la balise ou posez une 301. Si non, la version linguistique a-t-elle vraiment été abandonnée ? Dans ce cas, retirez la balise pour ne pas laisser une déclaration orpheline.
Entretenez ensuite ce contrôle à chaque refonte, parce que le problème revient toujours au même moment. Une page française valide mais privée de sa sœur par une balise morte finit par sortir de l’index, et la retrouver demande bien plus de travail que de corriger une ligne de code aujourd’hui. Combien de balises de votre site déclarent une adresse que vous n’avez jamais ouverte vous-même ?