Vous publiez une fiche produit en français et sa jumelle en anglais. Un internaute espagnol tombe dessus, Google lui sert la version anglaise, et vous ne comprenez pas pourquoi. Le réflexe habituel consiste à rouvrir la traduction, à traquer une phrase bancale ou un terme mal rendu. C’est presque toujours une fausse piste.
Le hreflang ne traduit rien, il relie des pages
Une balise hreflang indique aux moteurs de recherche qu’une page possède des versions équivalentes dans d’autres langues ou pour d’autres régions, et précise quelle version correspond à quel public. Rien de plus. Elle ne traduit pas un mot, ne corrige pas un contresens, ne remplace jamais un travail rédactionnel : elle établit des relations entre des pages qui existent déjà. Si votre traduction est soignée mais que les annotations sont bancales, les moteurs continueront de proposer la mauvaise version à la mauvaise personne.
Autrement dit, un travail rédactionnel irréprochable peut rester invisible pour le public visé, uniquement parce qu’une ligne mal écrite oriente le moteur ailleurs. Pour comprendre le mécanisme complet avant de toucher au code, mieux vaut consulter des ressources spécialisées comme scoma-consulting.com, qui détaille l’indexation et les balises dans ses comparatifs.
Ces annotations vivent dans l’en-tête du document, sous forme d’attributs HTML pointant vers les autres versions linguistiques. Elles fonctionnent par paires. Chaque page déclare l’existence de ses sœurs, et chaque sœur doit, en retour, déclarer la première. C’est cette réciprocité qui fait tenir l’ensemble, et c’est précisément là que les choses cassent.
Le retour croisé, ce contrôle que personne ne fait
Voilà le point que les guides de survol oublient systématiquement. Une seule référence de retour manquante suffit à rompre tout un ensemble. Concrètement, votre page française peut parfaitement lister l’anglaise, l’allemande et l’espagnole, alors que l’allemande a été publiée un vendredi soir sans ses annotations de retour.
Résultat : le moteur voit une déclaration qui ne trouve pas de réponse. Il ne sait plus à qui attribuer la version allemande, il la traite comme une page isolée, et parfois il cesse d’utiliser tout le groupe.
Le symptôme que vous observez, cette page unique qui revient à chaque requête, découle presque toujours de là. La traduction est correcte, les versions existent bien, mais le maillage déclaratif est asymétrique. D’un côté la flèche part, de l’autre elle n’arrive jamais.
Ce déséquilibre silencieux explique aussi pourquoi deux pages peuvent répondre à la même intention de recherche sans que vous l’ayez voulu, chacune tirant la couverture de son côté. Le moteur, lui, ne choisit pas : il prend celle qu’il juge la plus fiable, et ce n’est pas forcément celle que vous préférez.
Ce qu’il faut vérifier, version par version
Le contrôle n’a rien de sorcier, il demande juste de la rigueur et un tableur ouvert à côté du navigateur. Prenez chaque URL publiée, ouvrez son code source, et notez ce qu’elle déclare. Puis comparez, ligne par ligne, ce que chaque version promet aux autres. C’est ce face-à-face qui révèle les ruptures que l’œil nu laisse passer.
- La page française cite-t-elle bien l’anglaise, l’allemande et l’espagnole, sans en oublier une seule ?
- Ouvrez ensuite la version anglaise et vérifiez qu’elle vous renvoie la pareille.
- Chaque annotation utilise un code langue correct, sans mélange entre code pays et code langue.
- Une autréférence est-elle présente, cette ligne où la page se cite elle-même ?
- Les URL pointées répondent-elles sans redirection ni version de test oubliée ?
Ce dernier point piège beaucoup de monde, et il coûte cher en silence. Une annotation qui pointe vers une URL redirigée, ou vers une page en préproduction restée ouverte, ne sera pas suivie. La déclaration existe pourtant, elle est simplement inutilisable. Le moteur, lui, ne prévient personne : il abandonne la piste et sert ce qu’il peut. Sur ce point, voir aussi notre article sur comment bien sécuriser votre site web ?.
Pourquoi ça casse même quand le code semble propre
Il arrive que tout soit rédigé correctement et que le problème persiste. La construction du site entre alors en jeu, notamment quand un outil de traduction se superpose à une structure déjà en place. Weglot configure et ajoute automatiquement les balises hreflang au site web de ses utilisateurs, ce qui règle le cas général. Reste que si des annotations manuelles traînent déjà dans le thème, vous vous retrouvez avec des déclarations en double.
Deux jeux de balises concurrents, c’est pire que pas de balise du tout. Le moteur reçoit des instructions contradictoires, tranche comme il peut, et souvent ignore l’ensemble. Avant de publier, un simple comptage dans le code source vous dira si vous avez une série d’annotations ou deux.
Même logique du côté des régions : deux pages quasi identiques visant la France et la Belgique se concurrencent si rien ne les distingue. Sans hreflang, un moteur peut proposer une page en anglais à un internaute espagnol, ou considérer des pages régionales presque identiques comme des doublons qui se nuisent mutuellement.
Franchement, la plupart des audits que je vois passer s’arrêtent à la vérification de la langue déclarée. Personne ne remonte la chaîne complète pour vérifier que chaque maillon répond. C’est fastidieux, ça se fait à la main sur un petit site, et c’est exactement là que se cachent les ruptures.
Les erreurs qui font rater la publication
Quelques schémas reviennent sans cesse dans les projets multilingues, et ils suffisent à faire échouer une mise en ligne pourtant soignée par ailleurs. Les voici regroupés, pour que vous puissiez les chercher directement, sans perdre de temps sur des hypothèses linguistiques qui n’aboutissent à rien.
- Une version traduite est publiée après coup, sans que ses annotations de retour soient ajoutées.
- Le code langue est inversé : on écrit la région là où le moteur attend la langue.
- Une page supprimée laisse derrière elle des annotations orphelines qui pointent dans le vide.
- La version par défaut n’est jamais déclarée, et le moteur doit deviner son rôle.
- Des balises ajoutées par un plugin cohabitent avec des balises écrites à la main dans le thème.
Chacune de ces erreurs produit le même effet visible : une seule version remonte dans les résultats, quelle que soit la langue de l’internaute. Le diagnostic est rapide dès lors qu’on sait quoi regarder. Le plus long, c’est de corriger proprement, page par page, sans en oublier une au passage.
La symétrie avant la linguistique
Avant de rouvrir un dictionnaire ou de renégocier un tarif de traduction, ouvrez le code source. Comptez les annotations sortantes, puis vérifiez qu’elles trouvent une réponse en face. C’est ce contrôle de symétrie qui débloque la situation dans la grande majorité des cas, bien plus souvent qu’une relecture linguistique.
Une page qui renvoie une seule version n’a pas forcément un problème de langue : elle a un problème de relations déclarées, et ça se répare. Gardez donc ce réflexe simple : vérifier la réciprocité avant de vérifier la grammaire.
La prochaine fois que vous publierez une version traduite, poserez-vous la question de la traduction ou celle des retours croisés ? Ce réflexe change tout : il oriente votre audit vers le code plutôt que vers le texte, et il vous évite de renégocier une prestation linguistique alors que le vrai problème tient à quelques lignes d’annotations asymétriques.
