SEO
Corriger les erreurs hreflang : return tags, x-default et many-to-many
Copier pour l'IA
Vos balises hreflang sont en place, mais la Search Console continue de se plaindre ou c’est la mauvaise version linguistique qui se positionne. C’est ce qui rend hreflang si frustrant : une balise qui semble correcte peut malgré tout être totalement ignorée. Cette page est la couche de dépannage qui vient s’ajouter à l’explication. Si vous ne savez pas encore précisément ce que fait hreflang, lisez d’abord notre explication des balises hreflang, ou prenez du recul avec notre guide sur ce qu’est le SEO. Vous savez déjà tout cela et vous voulez seulement comprendre pourquoi votre implémentation est cassée ? Vous êtes au bon endroit. Nous passons en revue les trois erreurs hreflang responsables de neuf problèmes sur dix : les return tags manquants, un x-default erroné et des sets many-to-many cassés.
Diagnostiquer d’abord, bricoler ensuite
La plus grande perte de temps avec hreflang, c’est de modifier des balises à l’aveugle. Avant de changer quoi que ce soit, vous voulez savoir quelle erreur vous avez. Trois sources vous donnent la réponse :
- Google Search Console. Dans le ciblage international et les rapports de pages, vous voyez des messages du type “pas de balises de retour”. C’est votre signal le plus important, car il vient directement de Google.
- Un crawl avec une plateforme d’audit SEO. Un crawler parcourt toutes vos pages et montre, URL par URL, quel set hreflang s’y trouve et si les contreparties renvoient bien en retour. Vous retrouvez cela structuré dans un audit SEO sérieux.
- Inspecter manuellement le code source. Ouvrez le
<head>de deux versions linguistiques côte à côte et comparez. Chronophage, mais cela rend le problème tangible.
Ce n’est qu’une fois que vous savez laquelle des trois erreurs vous concerne que vous commencez à réparer. Sinon, vous ne faites que combattre des symptômes.
Erreur 1 : le return tag manquant
C’est de loin la plainte la plus fréquente. La règle est simple : si la page A pointe vers la page B, B doit pointer en retour vers A. Si ce renvoi manque, Google considère le signal comme peu fiable et ignore souvent tout le bloc hreflang. Pas seulement la ligne erronée, mais le set entier.
Un scénario typique : votre page néerlandophone est proprement configurée et renvoie vers la version francophone. Mais la page francophone a été construite par un autre membre de l’équipe ou avec un autre template, et le renvoi en retour manque. Résultat : Google ne voit pas la relation comme mutuellement confirmée et n’en fait rien.
Voici à quoi ressemble l’erreur. Sur exemple.be/nl/diensten/ on trouve :
<link rel="alternate" hreflang="nl-be" href="https://exemple.be/nl/diensten/" />
<link rel="alternate" hreflang="fr-be" href="https://exemple.be/fr/services/" />Mais sur exemple.be/fr/services/ il n’y a que :
<link rel="alternate" hreflang="fr-be" href="https://exemple.be/fr/services/" />La page francophone ne renvoie pas vers la néerlandophone. La correction consiste à faire porter aux deux pages le set complet et identique :
<link rel="alternate" hreflang="nl-be" href="https://exemple.be/nl/diensten/" />
<link rel="alternate" hreflang="fr-be" href="https://exemple.be/fr/services/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.be/" />Attention au détail que beaucoup négligent : le renvoi vers l’URL sur laquelle vous vous trouvez en fait aussi partie. C’est l’auto-référence. La page nl-be doit donc contenir elle-même un hreflang vers nl-be. Si elle manque, votre set est incomplet et les plaintes de return tags reviennent.
Deux causes fréquentes d’un return tag cassé : une différence de notation d’URL (une balise écrit https://, sa contrepartie http:// ou oublie le slash final) et un renvoi vers une URL redirigée. Hreflang doit toujours pointer vers l’URL définitive et indexable, jamais vers une version qui passe encore par une redirection ou une canonical.
Erreur 2 : le x-default erroné ou dupliqué
Le x-default désigne la version que Google affiche quand aucune version linguistique ou régionale ne correspond. Pour le marché belge, aussi hétérogène, avec des néerlandophones, des francophones et beaucoup de visiteurs internationaux, c’est un filet de sécurité utile. Mais c’est aussi la source de deux erreurs bien précises.
Première erreur : plusieurs pages revendiquent le x-default en même temps. Votre page nl-be porte un x-default qui pointe vers elle-même, et votre page fr-be porte un x-default qui pointe vers elle-même. Google se retrouve avec deux versions par défaut contradictoires et ne sait plus laquelle afficher. Il ne doit y avoir qu’une seule destination x-default au sein d’un cluster hreflang, et toutes les variantes pointent vers cette même URL.
Deuxième erreur : le x-default pointe vers une page qui n’existe pas comme filet neutre. Parfois le x-default se trouve sur une ancienne page d’accueil qui est désormais redirigée, ou sur une page de choix de langue qui ne porte elle-même aucun set hreflang. Choisissez consciemment votre filet de sécurité : une page d’atterrissage neutre qui laisse le visiteur choisir, ou l’une de vos langues principales. Quel que soit votre choix, cette destination doit être une URL vivante et indexable.
Une configuration qui fonctionne ressemble à ceci, identique sur chaque variante :
<link rel="alternate" hreflang="nl-be" href="https://exemple.be/nl/diensten/" />
<link rel="alternate" hreflang="fr-be" href="https://exemple.be/fr/services/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.be/" />Un seul x-default, une seule destination, la même sur chaque page. Aucune page qui se revendique par défaut pendant qu’une autre fait de même.
Erreur 3 : le set many-to-many cassé
Avec deux versions linguistiques, hreflang reste gérable. Cela devient traître dès que vous avez trois versions ou plus, par exemple nl-be, fr-be et une version anglaise internationale. La règle ne change pas, mais le nombre de connexions explose. Chaque page doit pointer vers toutes les versions, y compris elle-même. Avec trois versions, cela signifie trois lignes hreflang sur chaque page, et ces trois sets doivent parfaitement correspondre entre eux.
Voilà où ça dérape : quelqu’un ajoute une troisième langue et configure proprement la nouvelle page, mais oublie de mettre à jour les deux pages existantes. La nouvelle page anglaise pointe vers nl-be et fr-be, mais nl-be et fr-be ne pointent toujours que l’une vers l’autre et pas vers la version anglaise. Le cluster est asymétrique et s’effondre.
Le set many-to-many correct pour trois versions, qui doit figurer à l’identique sur chacune des trois pages :
<link rel="alternate" hreflang="nl-be" href="https://exemple.be/nl/diensten/" />
<link rel="alternate" hreflang="fr-be" href="https://exemple.be/fr/services/" />
<link rel="alternate" hreflang="en" href="https://exemple.be/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.be/" />Le principe directeur : traitez un cluster hreflang comme un tout que vous modifiez en une seule fois, et non comme des pages isolées. Si vous ajoutez ou supprimez une langue, vous mettez à jour chaque page du cluster. Sinon, vous créez exactement l’asymétrie qui déclenche les erreurs de return tags. Pour les sites plus grands, c’est un argument pour gérer hreflang dans votre sitemap XML plutôt que page par page, afin d’entretenir toutes les relations à un seul endroit central. Comment mettre cela en place dans une structure d’URL évolutive, vous le lisez dans notre guide sur le SEO international.
La quatrième erreur cachée : hreflang et canonical qui se disputent
Parfois vos balises hreflang sont parfaites et ça continue de mal tourner. Le problème se situe alors du côté de la canonical. Une canonical dit “indexe cette version”, hreflang dit “voici la variante pour ce public”. Si elles se contredisent, c’est la confusion qui gagne. Si votre page nl-be porte une canonical qui pointe vers la version fr-be, vous dites à Google à la fois “ceci est une version linguistique distincte” et “cette page ne compte pas, prends la française”. Google peut alors ignorer les deux.
La règle : chaque version linguistique reçoit une canonical auto-référente qui pointe vers elle-même, plus le set hreflang complet. Une canonical par page, vers elle-même, jamais vers une autre version linguistique. Cette cohérence entre balises est un point de contrôle fixe dans notre approche du SEO technique, car c’est précisément le type d’erreur qui reste invisible jusqu’à ce que vos positions s’effondrent.
Le processus de correction en quatre étapes
Traitez vos problèmes hreflang de façon systématique, pas au coup par coup :
- Confirmez l’erreur. Lisez le message dans la Search Console ou lancez un crawl. Sachez laquelle des quatre erreurs vous concerne avant de toucher à quoi que ce soit.
- Réparez tout le cluster en même temps. Modifiez chaque variante du cluster avec le même set complet. Des demi-corrections sur une seule page ne résolvent rien.
- Vérifiez la notation des URL et les redirections. Assurez-vous que chaque hreflang pointe vers une URL définitive et indexable, avec une notation cohérente du protocole et du slash.
- Revérifiez après le crawl suivant. Les modifications hreflang ne prennent pas effet immédiatement ; Google doit recrawler toutes les versions avant que la relation soit confirmée. La patience fait partie du processus.
Si vous voulez intégrer cela comme point de contrôle récurrent après chaque modification de contenu, reprenez-le dans votre checklist SEO technique, pour qu’une nouvelle page ne casse jamais un cluster à votre insu.
Questions fréquentes sur les erreurs hreflang
Pourquoi la Search Console dit-elle “pas de balises de retour” alors que mes balises sont là ? Parce que la contrepartie ne renvoie pas en retour, ou renvoie vers une URL très légèrement différente (différence de protocole, de www ou de slash final). Google compare l’URL exacte. Un seul caractère d’écart et le return tag ne compte pas.
Combien de balises x-default puis-je avoir ? Une seule destination par cluster hreflang. Toutes les variantes pointent vers cette même URL x-default. Deux pages qui se revendiquent chacune par défaut, c’est une erreur.
Le hreflang doit-il pointer vers l’URL canonical ou vers la vraie page ? Vers l’URL définitive et indexable, qui est idéalement aussi votre canonical auto-référente. Ne laissez jamais hreflang pointer vers une version redirigée ou non canonique.
Combien de temps faut-il pour qu’une correction hreflang prenne effet ? Jusqu’à ce que Google ait recrawlé toutes les pages concernées. Cela peut prendre des jours voire des semaines, selon votre fréquence de crawl. Une correction mise en ligne aujourd’hui ne sera pas validée ce soir.
Hreflang fonctionne-t-il aussi en dehors de Google ? Google et Yandex l’utilisent ; Bing et Baidu non. Si vous visez ces marchés, il vous faut d’autres signaux.
Vous n’arrivez pas à remettre votre hreflang d’aplomb ?
Hreflang est l’un des endroits où les sites B2B belges se plantent le plus souvent en silence : les balises ont l’air correctes, mais la bonne version linguistique reste introuvable et vos propres pages se concurrencent entre elles. Nous sommes une petite équipe qui regarde honnêtement avec vous et vous dit s’il s’agit d’une correction rapide ou du symptôme d’un problème structurel plus profond. Pour nous, le SEO n’est pas un exercice de balises isolées mais la couche d’acquisition de votre moteur de croissance, pilotée sur le pipeline et pas sur l’exhaustivité technique. Découvrez notre approche pour le spécialiste SEO et laissez-nous passer votre configuration hreflang au crible.
Scan gratuit de votre site
Indiquez votre site et recevez en quelques minutes une analyse automatique avec des points d'amélioration techniques et SEO concrets. Sans discours commercial.
Nous utilisons vos données uniquement pour votre scan. Pas de spam, désinscription à tout moment.