Un hreflang bien écrit qui pointe vers une page supprimée, c’est une adresse postale impeccable sur une maison démolie. Le code passe tous les validateurs, la syntaxe est propre, et pourtant Google envoie ses robots dans le mur. Sur les sites multilingues, cette panne silencieuse est partout : on change une URL, on refait une arborescence, on oublie de mettre à jour les balises. Résultat, des versions étrangères qui disparaissent des résultats, sans qu’aucun outil de validation ne signale quoi que ce soit.
Ce qu’une balise hreflang morte fait vraiment à votre site
Une balise hreflang sert à dire aux moteurs : « cette page existe aussi dans telle langue, à telle adresse ». Quand l’adresse en question renvoie un code 404, le moteur ne trouve rien à associer. Il ne va pas chercher plus loin, il abandonne simplement la correspondance. Vous perdez l’indexation de la version concernée, et parfois celle des autres versions qui s’appuyaient sur cette grappe de balises pour exister dans les bons pays.
Le problème, c’est que rien ne vous alerte. Les outils de vérification de balises analysent la structure du code, pas la disponibilité des cibles. Une URL pointée peut très bien renvoyer une erreur « Page introuvable » depuis des mois sans que personne ne s’en aperçoive. Pour comprendre comment le référencement international se joue sur ces détails techniques, le blog werankbox.fr couvre régulièrement ce genre d’audit.
Concrètement, ça donne quoi ? Vous avez un site en français, anglais, espagnol. La version espagnole a été refaite : les URL ont changé. Les balises hreflang des versions française et anglaise continuent de pointer vers les anciennes adresses. Pendant ce temps, la version espagnole indexe normalement. C’est le reste de la grappe qui boite, et vous ne le voyez pas.
Pourquoi les 404 apparaissent après une refonte
La cause numéro un, c’est la modification d’URL sans mise à jour des balises. Un slug change, une catégorie est renommée, un article est fusionné avec un autre : l’ancienne adresse meurt, le hreflang reste branché dessus. Personne ne pense à repasser sur les balises parce qu’elles sont dans le code, pas dans l’interface d’édition.
Il y a aussi la suppression pure et simple. Un article traduit en cinq langues est retiré en anglais uniquement. Les quatre autres versions gardent la balise hreflang qui cible la version anglaise disparue. Du coup, la grappe hreflang est incomplète, et Google n’aime pas les grappes incomplètes.
Un troisième cas, plus sournois : le changement de structure entre sous-répertoire et sous-domaine. Vous passez de www.example.com/en/ à en.example.com sans toucher aux balises. Le code fonctionne, la cible renvoie 404. Ce genre de migration se fait souvent avec l’ajout d’un plugin de traduction qui réécrit les URL à sa façon, sans coordination avec ce qui existe déjà.
Weglot, par exemple, propose une adresse de contact (support@weglot.com) pour désactiver les balises hreflang automatiques. C’est justement le signe que ces balises peuvent entrer en conflit avec celles déjà présentes, et créer des redirections mortes sans que personne ne s’en rende compte.
La méthode d’audit : crawler les cibles, pas la syntaxe
Les validateurs classiques vérifient une chose : la balise hreflang est-elle bien formée ? La langue est-elle valide ? Les codes de pays correspondent-ils à la norme ? C’est utile, mais insuffisant. Un hreflang valide syntaxiquement peut pointer vers une page morte depuis huit mois.
Il faut inverser l’angle : au lieu de contrôler le code, on contrôle la destination. Un crawler qui suit chaque URL cible de chaque balise, sur chaque page, et qui remonte les codes de réponse HTTP. C’est la seule façon de voir les 404.
Côté implémentation, plusieurs chemins possibles selon votre stack : un script qui parse le HTML de chaque page, extrait les <link rel="alternate"> et teste le statut de chaque href ; un export Screaming Frog configuré pour crawler le site en multilingue et croiser les hreflang sortants ; ou un crawler maison si vous gérez beaucoup de langues. Sur ce point, voir aussi notre article sur kub3.fr.
Le point important, c’est la périodicité. Un audit ponctuel ne sert à rien si vous publiez ou refondez régulièrement. Il faut le lancer après chaque migration, chaque refonte, chaque changement de plugin de traduction.
Ce que le crawl doit sortir à chaque passage
Voici les vérifications à automatiser dans votre rapport d’audit. Elles se croisent toutes avec le statut HTTP des cibles.
- Chaque URL listée dans une balise hreflang renvoie bien un code 200, pas une redirection et encore moins un 404.
- Réciprocité entre versions : la page A pointe vers B avec hreflang, la page B doit pointer retour vers A avec le même code langue. Quand ce n’est pas le cas, la balise est ignorée.
- Y a-t-il une balise x-default quelque part dans la grappe ? Sans elle, les visiteurs non localisés n’ont aucune version de repli vers laquelle atterrir proprement.
- Le même ensemble de balises doit figurer sur toutes les versions, avec les mêmes URL et les mêmes codes. Une asymétrie suffit à casser l’ensemble du groupe.
- Vos hreflang sont-ils générés automatiquement par un plugin ? Si oui, ce plugin est-il synchronisé avec votre arborescence réelle ?
Ces cinq contrôles couvrent l’essentiel. Le premier est celui qui détecte les 404, les autres éliminent les faux positifs et les grappes mal formées.
La question x-default : rattraper ceux qu’on oublie
Le x-default désigne la version de repli pour les visiteurs dont la langue ne correspond à aucune balise hreflang déclarée. Un Japonais qui arrive sur votre site depuis un pays sans version dédiée doit tomber sur quelque chose, pas sur une page vide ni sur un 404.
Cette balise est aussi votre filet de secours quand une version ciblée est cassée. Si votre hreflang espagnol pointe vers une URL morte, le x-default peut encore capter le visiteur et le rediriger vers la version par défaut. Ça ne répare pas l’erreur, mais ça limite la casse en attendant.
Sans x-default, chaque visiteur non ciblé devient un utilisateur perdu. Google ne sait pas quelle version servir, il en choisit une au hasard, et il se trompe souvent. Ajouter cette balise prend cinq minutes et règle un paquet de cas limites.
Ce que 404 veut dire, et pourquoi ça piège tout le monde
Le code 404 signifie « Page introuvable », en français comme partout ailleurs. Quand un robot tombe dessus, il comprend que l’URL a existé ou aurait dû exister, mais qu’elle ne renvoie rien. Dans un contexte hreflang, ça veut dire que la correspondance de langue est morte.
Un utilisateur anglophone qui clique sur votre lien vers la version anglaise tombée en 404 repart aussitôt. Un robot qui suit la balise hreflang vers cette même URL enregistre l’échec et perd confiance dans la grappe. Les deux effets se cumulent : vous perdez du trafic et vous perdez de la crédibilité technique auprès du moteur.
La solution courante est la redirection 301 vers la nouvelle URL si la page a juste déménagé. Si la page a bel et bien disparu, il faut retirer la balise hreflang qui la cible, et éventuellement mettre à jour la grappe entière. Le pire, c’est de laisser une 404 traîner en pensant qu’elle n’affecte que cette langue : c’est faux, l’ensemble du groupe peut en pâtir.
Tester avant de publier, puis surveiller
Un dernier réflexe, simple et souvent négligé : avant de pousser une refonte en production, testez chaque URL des balises hreflang sur un environnement de préproduction. Un curl sur chaque href, un œil sur les codes retour, et vous savez tout de suite ce qui va casser. Ça prend vingt minutes et ça évite des semaines de perte d’indexation.
Ensuite, programmez un crawl périodique, mensuel ou trimestriel selon votre rythme de publication. Gardez une trace des résultats pour comparer d’un audit à l’autre : un hreflang qui passe de 200 à 404 entre deux passages, c’est une régression que vous pouvez corriger dans la journée.
Combien de balises hreflang de votre site pointez-vous vers des URL que vous n’avez pas ouvertes depuis six mois ?
