SEO international : la traduction n’est pas la localisation, et hreflang ne pardonne pas

Six langues en ligne. Une balise mal formée sur trois pages. Six versions dégradées.

Le SEO d’un site multilingue avec hreflang souffre rarement d’un problème de traduction. Il souffre d’un problème de contrat : personne n’a écrit qui produit les annotations, qui les contrôle avant mise en ligne et qui les corrige quand elles se contredisent. Chacun a livré son lot, et le lot suivant a défait le précédent.

Cet article traite la question par la responsabilité et non par la technique. Les erreurs qui dégradent toutes les langues, la raison pour laquelle elles se propagent, la différence opérationnelle entre traduire et localiser, une matrice attribuant neuf éléments de configuration à un producteur et à un recetteur, puis une procédure courte à exécuter avant chaque ouverture de langue. Il prolonge notre méthode pour répartir les rôles entre plusieurs prestataires.

Trois prestations achetées séparément, une seule configuration

Le schéma d’achat est presque toujours le même. Un cabinet de traduction fournit des fichiers, une agence technique les intègre, un référenceur audite le résultat trois mois plus tard.

Aucun des trois ne détient la configuration complète. Le traducteur ignore l’arborescence d’URL retenue, l’intégrateur ignore quelles requêtes visent chaque marché, le référenceur découvre les deux au moment où il constate le problème. La configuration est unique, la responsabilité est fragmentée.

Deux détails d’ingénierie aggravent la situation. Google indique que trois méthodes d’annotation existent, balises HTML, entêtes HTTP et plan de site, qu’elles sont équivalentes de son point de vue et qu’il n’y a aucun bénéfice à les cumuler. Beaucoup de sites en utilisent pourtant deux, posées par deux prestataires différents, qui se contredisent.

Un signe permet de repérer le problème sans audit complet : demandez qui détient le document de référence listant les langues ouvertes, leurs adresses et leurs codes. Quand la réponse est « chacun a sa liste », la configuration est déjà divergente.

Second détail : le robot d’exploration part le plus souvent des États-Unis et n’envoie pas d’entête de langue. Un site qui adapte son contenu selon l’adresse IP du visiteur expose donc à Google une seule version. Les interactions entre briques sont détaillées dans notre panorama des couches techniques d’un site et leurs interactions.

Les quatre erreurs qui dégradent toutes les langues à la fois

Quatre familles couvrent la quasi-totalité des incidents constatés. Aucune ne relève de la qualité de la traduction.

• Réciprocité absente. La page allemande cite la page anglaise, l’anglaise ne cite pas l’allemande. Google précise que si deux pages ne se désignent pas mutuellement, l’annotation est ignorée.
• Codes mal formés. Le code de langue relève d’une norme, le code de région d’une autre. Indiquer une région seule ne fonctionne pas : « be » désigne le biélorusse, pas la Belgique.
• Adresses en erreur. Les URL doivent être absolues, protocole compris. Une adresse relative, une redirection ou une page bloquée à l’indexation vide l’annotation de son effet.
• Balise canonique croisée. La version espagnole pointe une canonique vers la version anglaise. Le signal devient contradictoire : une page se déclare à la fois variante linguistique et doublon d’une autre.

Deux précisions techniques valent d’être connues des donneurs d’ordre. Certains codes réservés sont purement et simplement ignorés par Google, dont « EU », « UN » et « UK ». Et des formats répandus dans l’industrie, comme le code régional latino-américain, ne sont pas pris en charge.

Dernière chose sur la détection de langue, contre-intuitive : Google n’utilise ni l’annotation ni l’attribut de langue du code HTML pour déterminer la langue d’une page. Il s’appuie sur le contenu visible. Une page à moitié traduite reste donc ambiguë quelle que soit la propreté du balisage.

Pourquoi l’erreur est systémique et non locale

Une annotation ne décrit pas une page, elle décrit un ensemble. Chaque version doit lister toutes les autres, y compris elle-même, et la liste est identique partout.

Le mécanisme de réciprocité existe pour une raison de sécurité : sans lui, n’importe quel site pourrait se déclarer version alternative d’une de vos pages. La conséquence pratique est brutale. Ajouter une septième langue en modifiant six jeux d’annotations et en oubliant l’un des six produit une erreur systémique, pas une erreur locale.

C’est ce qui explique le symptôme le plus déroutant du dossier : une équipe corrige une page italienne et voit le trafic espagnol bouger. Il n’y a pas de mystère, seulement un graphe dont un nœud a changé.

Traduire n’est pas localiser

Traduire n’est pas localiser : la formule est connue, sa traduction opérationnelle l’est moins. Voici ce qui change réellement d’un marché à l’autre.

Les requêtes, d’abord. Un même produit ne se cherche pas avec les mêmes mots selon le pays, et la traduction fidèle d’un titre optimisé pour la France produit un titre correct qui ne correspond à aucune recherche allemande. C’est le poste le plus coûteux à rattraper.

Les unités et les formats ensuite : devise, taxes affichées, dates, adresses, formats de téléphone, unités de mesure. Puis les preuves : références clients pertinentes localement, certifications reconnues sur place, témoignages dans la langue du lecteur.

Les mentions légales enfin, qui ne se traduisent pas mais se réécrivent selon le droit applicable. Conditions de vente, droit de rétractation, informations sur l’éditeur : le texte français traduit n’a aucune valeur juridique ailleurs.

Un point d’organisation souvent oublié : le service qui répondra dans cette langue. Ouvrir un marché sans capacité de réponse produit des demandes sans traitement, et notre méthode pour organiser un service client sur plusieurs langues montre que ce poste se dimensionne avant l’ouverture, pas après.

Un dernier poste échappe aux trois prestataires : le choix des marchés. Ouvrir six langues parce que le module de traduction les propose revient à multiplier par six la surface de maintenance pour un gain souvent concentré sur deux marchés. Mon avis : deux langues bien localisées valent mieux que six versions correctes et orphelines.

Sur la traduction automatique, une nuance utile : Google considère les versions localisées comme des doublons uniquement si le contenu principal reste non traduit. Une traduction automatique relue ne crée donc pas mécaniquement de duplication. Le risque porte sur la qualité, ce qui est un autre sujet.

SEO d’un site multilingue : la matrice de responsabilité sur neuf éléments

La matrice ci-dessous s’annexe au cahier des charges. Elle nomme, pour chacun des neuf éléments de configuration, qui produit, qui contrôle avant mise en ligne et qui corrige.

Deux lignes méritent d’être discutées en réunion de cadrage. La quatrième, parce que le traducteur est le seul à savoir si un code correspond vraiment à la langue livrée. La neuvième, parce qu’elle sort du périmètre habituel des trois prestataires et se retrouve sans titulaire par défaut. La façon d’ancrer cette matrice figure dans notre modèle pour définir les responsabilités dans le cahier des charges.

La recette linguistique avant chaque mise en ligne

La procédure tient en six contrôles et se déroule en environnement de préproduction, avant chaque mise en ligne. Comptez deux heures par langue ouverte.

• Vérifier la réciprocité sur un échantillon de dix pages par langue : chaque version cite toutes les autres, elle-même comprise.
• Contrôler les codes un par un, langue et région séparées, et refuser toute région employée seule.
• Suivre chaque adresse annoncée : absolue, protocole inclus, sans redirection ni blocage à l’indexation.
• Croiser avec les canoniques : aucune version ne doit se déclarer doublon d’une autre langue.
• Contrôler la page de repli pour les langues non couvertes, en particulier sur l’accueil et les sélecteurs de pays.
• Relire une page complète dans chaque langue, contenu principal et navigation, pour écarter les pages à moitié traduites.

Ces contrôles se documentent dans un procès-verbal signé, au même titre que la recette technique classique. Le modèle applicable figure dans notre article sur la recette avant mise en ligne.

Une limite honnête : cette procédure attrape les erreurs de configuration, pas les erreurs de marché. Si votre traduction est fidèle mais ne correspond à aucune requête locale, aucun contrôle technique ne le signalera. Ce diagnostic-là demande une recherche de mots-clés menée dans la langue cible, par quelqu’un qui la parle.

Une balise mal posée, et vos six langues tombent ensemble

Le coût d’une erreur de configuration ne se répartit pas proportionnellement. Il se multiplie par le nombre de versions concernées.

La décision utile avant la prochaine ouverture de langue tient en une phrase : faire signer la matrice des neuf éléments par les trois prestataires et le donneur d’ordre, puis conditionner la mise en ligne au procès-verbal de recette linguistique. Sans cela, l’arbitrage se fera au moment de la chute, quand plus personne ne saura qui a modifié quoi.

Sources et références

Cet article s’appuie notamment sur la documentation de Google Search expliquant comment signaler à Google les versions localisées d’une page, d’où proviennent la règle de réciprocité, l’obligation d’adresses absolues, les normes de codes de langue et de région et la liste des codes réservés ignorés. Les arbitrages d’arborescence et la détection de la langue par le contenu visible viennent du guide sur la gestion des sites multirégionaux et multilingues. Le comportement du robot face aux contenus adaptés à la localisation est décrit dans la page consacrée à l’exploration des pages adaptatives. Le traitement des doublons suit la documentation sur la consolidation des URL en double, et le statut des extensions géographiques a été vérifié dans la base des domaines de premier niveau tenue par l’IANA. L’ensemble a été recoupé avec la vue d’ensemble des sites internationaux et multilingues.