hreflang : cinq erreurs qui annulent tout le balisage

Le balisage hreflang a une propriété que peu de signaux SEO partagent : il ne se dégrade pas, il s’annule. Un title médiocre reste un title. Un ensemble hreflang dont un seul lien est faux est écarté en entier — Google préfère ignorer une annotation incohérente plutôt que d’en deviner l’intention.

Et rien ne prévient. Le site répond 200, les balises sont là, l’outil d’audit les compte et les affiche. Les pages disparaissent quand même de l’index.

Voici les cinq erreurs qui produisent ce silence, dans l’ordre où nous les rencontrons.

1. La page ne se déclare pas elle-même

Un ensemble hreflang doit contenir une entrée pour chaque version, y compris celle de la page qui porte le balisage. C’est contre-intuitif : on croit déclarer « les autres langues », alors qu’on déclare « toutes les langues ».

Une page anglaise qui annonce le français et rien d’autre ne dit pas « voici ma traduction française ». Elle dit « la version de référence est française ». Google obéit.

Nous avons rencontré cette erreur sur notre propre site en août 2026. Search Console signalait cinquante et une pages en « doublon, Google n’a pas choisi la même URL canonique que l’utilisateur ». Deux validations avaient échoué. Le balisage émis par les pages anglaises ressemblait à ceci :

<link rel="canonical"  href="https://exemple.com/en/blog/category/laravel">
<link rel="alternate" hreflang="fr"        href="https://exemple.com/fr/blog/categorie/laravel">
<link rel="alternate" hreflang="x-default" href="https://exemple.com/fr/blog/categorie/laravel">

Pas de hreflang="en". Vingt-deux pages sur vingt-deux dans ce cas. La cause était dans le code qui construisait les alternates : il excluait toute langue dont la rubrique était vide, sans exempter la langue de la page en cours. Un filtre légitime appliqué un cran trop loin.

2. Le balisage annonce une page qui n’existe pas

Google suit les liens hreflang. S’ils répondent 404, il les compte comme des erreurs d’exploration et cesse d’accorder du crédit à l’ensemble.

C’est l’erreur des sites en cours de traduction. On génère mécaniquement les trois langues parce que la route existe, sans vérifier qu’il y a quelque chose au bout. Le réflexe correct est inverse : n’annoncer une langue que si son contenu est publié. Un ensemble de deux langues exact vaut mieux qu’un ensemble de trois dont une est fictive.

3. La réciprocité est rompue

Si A déclare B, B doit déclarer A. Google traite les ensembles comme des confirmations mutuelles : une déclaration unilatérale est une affirmation invérifiable, et il l’écarte.

La rupture arrive rarement d’un oubli. Elle vient des slugs traduits — /fr/realisations/ et /en/portfolio/ — quand deux endroits du code construisent l’URL différemment. Un côté annonce l’adresse traduite, l’autre l’adresse par défaut, et la boucle ne se referme pas.

4. hreflang et canonical se contredisent

C’est la plus coûteuse, parce qu’elle combine deux signaux corrects pris séparément.

La balise canonique dit « la version de référence de cette page, c’est elle-même ». Le balisage hreflang, privé d’auto-référence, dit « la version de référence est ailleurs ». Les deux ne peuvent pas être vrais. Google tranche, et il tranche contre la page — c’est exactement le libellé du rapport que nous avons reçu : Google n’a pas choisi la même URL canonique que l’utilisateur.

Retenez la règle : hreflang ne doit jamais désigner une page dont la canonique pointe ailleurs. Un ensemble hreflang ne relie que des pages canoniques d’elles-mêmes.

5. Le code de langue est faux, ou trop précis

Trois variantes reviennent :

• La région inventée. en-UK n’existe pas, c’est en-GB. Une valeur invalide invalide l’entrée, et l’entrée invalide l’ensemble.
• La région sans langue. hreflang="ma" ne désigne pas le Maroc mais le marathi. Le format est langue d’abord, région ensuite : ar-MA.
• La précision inutile. Déclarer ar-MA quand vous n’avez qu’une seule version arabe restreint sa diffusion sans rien apporter. La variante régionale ne se justifie que si vous servez réellement deux contenus distincts.

Ajoutez-y x-default, qui doit désigner la page servie à un visiteur dont aucune langue ne correspond — pas « la langue principale du site » par habitude.

Vérifier sans attendre Search Console

Search Console confirme, mais avec plusieurs semaines de retard, et son rapport mélange les causes. Le balisage se lit directement dans le HTML servi.

La méthode que nous appliquons : récupérer chaque version d’une même page, extraire les balises <link rel="alternate">, et comparer les ensembles. Ils doivent être identiques d’une version à l’autre, contenir chaque langue une seule fois, et inclure la page elle-même. Trois minutes par gabarit, et l’erreur saute aux yeux — celle qui nous a coûté cinquante et une pages était visible en une commande.

Le reste du diagnostic tient dans une question : est-ce que la page à laquelle mène ce lien répond 200, et est-ce qu’elle renvoie le lien ?

Ce que nous en avons tiré

Sur notre site, la correction n’a pas consisté à réparer le balisage. Elle a consisté à supprimer les pages qui n’auraient jamais dû exister : vingt-quatre pages de rubrique sans un seul article, servies en 200, indexables, et qui ne différaient les unes des autres que par leur titre. Une rubrique n’est désormais exposée que dans les langues où elle a du contenu. L’absence de route la retire d’un coup de la navigation, des sitemaps et des alternates.

C’est le principe qui vaut au-delà de notre cas : le balisage hreflang décrit une réalité, il ne la crée pas. Quand il devient compliqué à écrire, ce n’est presque jamais un problème de balisage. C’est que l’arborescence multilingue promet des pages qui n’existent pas.

C’est la question que nous posons systématiquement aux entreprises françaises qui nous confient un site multilingue, avant d’écrire la moindre balise : combien de langues aurez-vous réellement traduites à la mise en ligne, et lesquelles seront encore vides six mois plus tard ? La réponse décide de l’arborescence, et l’arborescence décide du balisage.

Si vous préparez une refonte multilingue, la même logique s’applique à la conservation du trafic pendant la bascule : ce qui se corrige à la conception ne se rattrape presque jamais après la mise en ligne.