Vous avez beau avoir tout vérifié dans Search Console — balises présentes, codes pays corrects, x-default en place —, vos versions espagnoles s'obstinent à sortir en français dans les résultats de recherche. Pas de message d'erreur. Pas d'avertissement. Juste un balisage hreflang qui a l'air parfait et qui ne sert à rien.
C'est la blague la plus courante du SEO international : hreflang échoue en silence. Contrairement à un canonical mal formé ou à un robots.txt qui bloque tout, une erreur hreflang ne casse rien de visible. Google choisit simplement d'ignorer votre cluster, et vous ne le découvrez que trois mois plus tard, quand le trafic allemand ne décolle toujours pas.
Dans cet article, je vous donne l'ordre exact dans lequel corriger les erreurs de balisage hreflang — pas une liste en vrac, mais une séquence qui fonctionne. Je l'ai construite après avoir perdu des semaines sur un site à huit langues où je corrigeais les problèmes dans le mauvais ordre.
Points clés à retenir
- Une erreur hreflang ne génère presque jamais d'alerte : le cluster entier est ignoré sans bruit
- Corrigez toujours les return tags (réciprocité) avant tout le reste
- Chaque URL doit se référencer elle-même — l'oubli le plus fréquent sur les gros sites
- Un canonical qui pointe vers une autre version linguistique annule votre hreflang
- Comptez plusieurs semaines avant que Google reflète une correction
Pourquoi vos balises hreflang ne marchent pas (même quand elles semblent correctes)
hreflang est un signal, pas une directive. Vous dites à Google : « voici les versions de cette page pour telle langue et telle région, choisissez la bonne ». Le moteur recoupe ce que vous déclarez avec des dizaines d'autres indices — la langue détectée dans le contenu, la position des liens, les redirections, le canonical. Dès qu'un signal contredit les autres, il tranche contre vous.
Le problème vient de là. La plupart des « erreurs de balisage hreflang » qu'on cherche dans le code ne sont pas dans le code. Elles sont dans les relations entre les pages.
Le silence comme symptôme
Sur un projet e-commerce, j'avais déclaré un cluster propre : six langues, x-default, tout en <link> dans le <head>. Résultat au bout de deux mois : zéro amélioration. En inspectant les URLs une par une, je me suis rendu compte qu'une seule page — la version italienne, ajoutée en dernier — pointait vers les cinq autres sans que les cinq autres pointent vers elle. Un return tag manquant, une seule page sur six, et Google a écarté la totalité du cluster.
Voilà la règle à retenir : hreflang fonctionne en tout ou rien. Une relation incomplète, et l'ensemble est ignoré.
Dans quel ordre corriger les erreurs hreflang
Corrigez dans cet ordre. Sauter une étape revient à repeindre un mur humide.
- Réciprocité (return tags) — vérifier que chaque page référence toutes les autres du cluster et elle-même.
- Auto-référence — chaque URL doit figurer dans sa propre liste hreflang.
- Codes langue et région — format ISO 639-1 + ISO 3166-1, dans cet ordre (
fr-BE, jamaisBE-fr). - x-default — une seule valeur par cluster, une seule URL désignée.
- Conflits avec canonical et redirections — le nettoyage qui règle la moitié des cas restants.
Étape 1 et 2 : return tags et auto-référence
Concrètement, un cluster sain ressemble à ça pour une page française :
<link rel="alternate" hreflang="fr" href="https://exemple.com/fr/" />
<link rel="alternate" hreflang="fr-BE" href="https://exemple.com/fr-be/" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en/" />
<link rel="alternate" hreflang="de" href="https://exemple.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/" />La version belge doit contenir exactement les mêmes lignes — à ceci près que sa propre URL apparaît dans fr-BE. Si elle n'y est pas, vous avez trouvé le problème. Un script qui extrait les balises de chaque URL du cluster et vérifie que la matrice est symétrique règle ça en une heure. Faites-le une fois, gardez-le.
Étape 3 et 4 : les codes ISO et x-default
Deux pièges reviennent sans arrêt. Le premier, l'inversion : us-en au lieu de en-US. Google ne reconnaît pas la valeur et l'ignore, ce qui casse la réciprocité de tout le cluster. Le second, un x-default dupliqué ou absent. Il ne doit y avoir qu'un seul x-default par groupe de pages, pointant vers la version par défaut (souvent la page globale ou la version anglaise).
Un x-default qui pointe vers une URL absente du cluster est une erreur fréquente et particulièrement silencieuse.
Astuce : un code en sans région et un code en-US ne sont pas interchangeables. Si vous ciblez tous les anglophones, utilisez en. Si vous visez les États-Unis uniquement, utilisez en-US. Mélanger les deux dans un même cluster crée des conflits de priorité.
Étape 5 : les conflits avec canonical et les redirections
C'est le nettoyage que personne ne fait et qui explique une bonne partie des cas désespérés. Une URL déclarée en hreflang ne peut pas avoir un canonical pointant ailleurs. Si votre page /de/ déclare un hreflang de mais que son canonical pointe vers /, Google considère qu'elle n'existe pas comme version distincte. Le hreflang devient une déclaration sans objet.
Même logique pour les redirections : une URL cible hreflang qui redirige (301 ou, pire, 302) casse la relation. Vérifiez chaque URL du cluster avec un simple crawl. Sur un site que j'ai audité, quatre des onze URLs cibles redirigeaient en 302 vers une page de sélection de langue — le cluster entier était mort et personne ne l'avait vu.
Quelle méthode d'implémentation choisir pour éviter les erreurs
Les trois méthodes d'implémentation n'ont pas les mêmes pièges de correction. Le tableau ci-dessous résume ce que vous risquez selon votre choix.
| Méthode | Où ça se corrige | Piège principal |
|---|---|---|
Balises <link> en HTML | Template <head> | Corrections non propagées à toutes les pages si le template diverge |
En-têtes HTTP Link | Configuration serveur ou CDN | Invisible dans le code source, donc oublié lors des tests |
| Sitemap XML | Génération du sitemap | Décalage entre sitemap et pages réelles, versions obsolètes listées |
Mon avis, et je l'assume : pour un site qui publie régulièrement, le sitemap XML est le plus sûr en correction, parce qu'il centralise les déclarations dans un fichier unique que vous régénérez. Le piège du sitemap ? Il peut lister des URLs qui n'existent plus. Un cluster dans le sitemap avec une URL morte casse l'ensemble, exactement comme dans le HTML.
Pour les grosses structures, les en-têtes HTTP sont élégants — mais je les déconseille aux équipes qui ne maîtrisent pas leur CDN. Une correction oubliée côté serveur est un cauchemar à retrouver. Ceux qui utilisent les trois méthodes simultanément avec des valeurs incohérentes créent leur propre désastre : ne mélangez jamais les méthodes sur un même cluster.
Combien de temps faut-il pour que Google prenne en compte la correction
Le recrawl n'est pas instantané. Sur mes projets, une correction hreflang met en général deux à six semaines avant que le changement se reflète dans les résultats, selon l'autorité du site et la fréquence des visites du robot. Ne vous attendez pas à un effet le lendemain.
Comment vérifier que la correction est prise en compte
- Inspection d'URL dans Search Console — vérifiez le rendu de la page et les balises detectées.
- Logs serveur — regardez si Googlebot revient sur les URLs du cluster après votre correction.
- Requêtes ciblées — testez avec des recherches en langue cible et un paramètre de région, pas depuis votre navigateur français.
Un indicateur utile, souvent négligé : si les impressions en langue cible commencent à bouger dans la Search Console avant même que le trafic ne change, la correction a été prise en compte. C'est le premier signal à surveiller.
Faut-il supprimer hreflang quand les corrections ne suffisent pas
Une question que j'entends de plus en plus de la part de clients exaspérés. La réponse honnête : parfois, oui.
Si votre site traduit ses contenus de façon automatique et que la version allemande est du français passé au traducteur, aucun hreflang ne fera grimper cette page. Le signal de langue détecté par Google contredit votre déclaration, et le moteur privilégie ce qu'il lit. Corriger le balisage sur du contenu mal traduit, c'est soigner la forme d'une page qui n'a pas de fond. J'ai vu une fois une équipe passer un mois à corriger des hreflang sur des pages dont la moitié du texte était identique en deux langues — le contenu dupliqué écrasait tout.
Le vrai test : ouvrez la page cible. Si vous ne comprenez pas un mot de la langue qu'elle prétend cibler, l'erreur hreflang n'est pas votre priorité.
Ce qui reste quand tout est corrigé
Une fois la réciprocité vérifiée, les codes ISO validés, les canonicals alignés et les redirections nettoyées, il reste un signal que vous ne contrôlez pas : la confiance que Google accorde à votre déclaration linguistique. Elle se gagne avec du contenu réellement dans la langue, des liens internes cohérents et du temps. Le balisage ne fait que rendre votre intention lisible — il ne la rend pas vraie.
Et si après toutes ces corrections le cluster reste ignoré, posez-vous la question à l'envers : êtes-vous certain que ces pages méritent leur propre version régionale ? Parfois, la bonne correction n'est pas dans le balisage. Elle est dans la décision de fusionner deux versions qui n'auraient jamais dû être séparées.
