Plus de langues sur votre annuaire : ce qui fait reellement d'une page traduite une page a part entiere

Chaque variante de langue est une promesse que la page ne tient pas toute seule
Activer plus de langues signifiait autrefois embaucher un traducteur et attendre des semaines. Aujourd'hui, la plateforme s'en charge : on choisit dix langues, et du jour au lendemain le site a dix adresses pour la meme page, un menu avec des drapeaux, et toute l'interface reecrite. Ce qui ne se fait pas tout seul, c'est la seule chose qu'un moteur de recherche lit en premier : ce qui est ecrit sur la page.
Une page statique comme la page d'accueil, la page des tarifs ou les pages legales peut vraiment etre traduite mot pour mot, et une fois traduite, c'est honnetement une page differente dans une autre langue. Une annonce est un animal different. Un annonceur ecrit son profil une seule fois, dans la langue qu'il parle, et rien sur la plateforme ne peut lui mettre des mots dans la bouche dans neuf autres langues sans soit les traduire par une machine, ce qui change ce qu'il a reellement ecrit, soit les laisser telles quelles sous une adresse qui pretend etre, disons, la version allemande.
Multipliez cela par chaque annonce du site, et l'expansion a dix langues censee ouvrir neuf nouveaux marches produit a la place neuf copies d'une page qui, pour autant qu'un moteur de recherche puisse le voir, dit exactement la meme chose dans la meme langue sous une adresse differente. Ce n'est pas un risque theorique. C'est le resultat par defaut d'activer la traduction au niveau du gabarit sans toucher a la seule partie de la page que l'annonceur a vraiment ecrite.
Rien de tout cela n'apparait comme une erreur. La compilation reussit, les pages s'affichent, le selecteur de langue fonctionne, et le site a l'air termine. Ce qu'il a vraiment produit ne devient visible que dans la facon dont les moteurs de recherche traitent ces pages des mois plus tard, quand le trafic vers les nouvelles langues n'arrive jamais comme il est arrive pour celles qui valaient vraiment la peine d'etre traduites.
Ce que hreflang fait vraiment, et ce qu'il n'a jamais pu faire
La balise que presque tout le monde evoque des qu'il est question de SEO international est hreflang, et on lui attribue plus qu'elle ne fait reellement. La documentation de Google elle-meme la decrit avec une seule fonction : indiquer a la personne qui cherche l'adresse la plus adaptee a sa langue ou sa region, parmi un ensemble de pages que le moteur considere deja comme des versions equivalentes d'un meme contenu. C'est une instruction de routage, pas une traduction, et pas un coup de pouce au classement.
Deux malentendus en decoulent, et tous deux comptent ici. D'abord, hreflang ne fait pas croire a Google qu'une page est traduite. La documentation de Google precise explicitement qu'elle n'utilise ni hreflang, ni meme l'attribut de langue declare par la page elle-meme, pour determiner dans quelle langue le contenu est reellement ecrit ; elle lit les mots et decide par elle-meme. Une balise qui declare qu'une page est la version francaise ne change rien a ce que Google conclut que la page dit vraiment.
Ensuite, hreflang n'est pas un levier de positionnement. Nulle part dans les directives de Google elle n'est decrite comme quelque chose qui aide une page a mieux se classer. Ce qu'elle affecte, c'est laquelle, parmi plusieurs adresses equivalentes, est montree a un internaute donne, apres que le classement a deja eu lieu. Un site qui s'attend a ce que plus de langues signifient directement plus de visibilite demande au mauvais outil de faire un travail different.
Cet ecart entre ce que les operateurs pensent obtenir de hreflang et ce que Google dit reellement qu'elle fait est la ou se perd la plus grande partie du travail dans un lancement multilingue. La balise coute peu a ajouter et il est facile de la rendre techniquement correcte sans pour autant rien resoudre, parce que le probleme qu'elle existe pour resoudre, choisir quelle variante de langue montrer, n'a jamais ete le probleme qu'a reellement un annuaire avec des annonces non traduites.
La regle qui decide si une page traduite est vraiment une page differente
Google enonce le critere reel sans detour : les versions localisees d'une page ne sont considerees comme des doublons entre elles que si le contenu principal de la page reste non traduit. Tout, dans un lancement multilingue d'annonces, se resume a cette phrase, parce qu'elle trace la ligne entre les pages qui ont vraiment multiplie le contenu du site et celles qui n'ont multiplie que ses adresses.
Une page d'accueil, une page de categorie ou une page de tarifs reussit le test des que le texte visible change de langue, parce que le contenu principal est justement ce qui a ete traduit. Une page d'annonce construite sur le meme gabarit ne le reussit pas de la meme maniere. La navigation, les boutons, le pied de page legal changent de langue. Le seul paragraphe que le visiteur est venu lire, la description ecrite par l'annonceur, reste exactement telle quelle, parce que personne n'a l'autorite de la reecrire a sa place.
C'est le mecanisme, pas une supposition sur l'intention. Un moteur de recherche n'a pas besoin de presumer un motif pour traiter des pages quasi identiques comme des doublons ; il lit la meme phrase dans la meme langue sur les deux adresses et en tire la conclusion evidente. Un probleme de pages quasi identiques se retrouve aussi du cote des villes et des categories d'un annuaire de petites annonces, et la solution y est le meme principe applique a un autre axe : plus d'adresses ne valent la peine que lorsque le contenu derriere elles est reellement different, pas quand un gabarit a genere une nouvelle URL gratuitement.
L'effet pratique s'aggrave avec l'echelle. Dix annonces traduites en dix langues font cent adresses, et si le contenu redige ne varie en realite que par la langue du gabarit environnant, un moteur de recherche qui essaie de decider laquelle montrer se retrouve avec quatre-vingt-dix quasi-copies en concurrence avec la seule page qui fait un travail reel. Cela dilue le signal au lieu de le multiplier, et cela se fait en silence, parce que rien sur le site ne semble casse pendant que ca se produit.
Trois facons dont une build multilingue casse tout ca sans que personne ne le remarque
La balise reciproque est la panne la plus courante, et c'est celle sur laquelle Google est la plus directe : chaque version de langue doit se lister elle-meme et toutes les autres versions, et si deux pages ne pointent pas l'une vers l'autre, les balises sont totalement ignorees pour cette paire. Cela casse generalement apres le lancement, pas au lancement, quand une nouvelle langue est ajoutee au site et que la liste des langues alternatives sur les pages deja existantes n'est jamais mise a jour pour l'inclure.
La valeur x-default est mal utilisee presque aussi souvent, en general dans le sens oppose : ajoutee a chaque page au lieu du seul endroit pour lequel elle a ete concue. Google la decrit comme la version de secours affichee quand aucune des langues declarees ne correspond aux reglages du visiteur, pensee pour une page de selection de langue ou une page d'accueil qui redirige automatiquement, pas pour une annonce qui a deja sa propre langue parfaitement definie. La mettre partout ne cause pas d'erreur, cela dit seulement a Google quelque chose d'inutile sur des pages ou quelque chose d'utile etait deja connaissable.
Les codes de region sont le detail qui coute le moins cher a bien faire et qui est le plus souvent rate. Google ne reconnait que des codes de langue ISO associes a des codes de region ISO, et le reflexe naturel pour un public britannique, ecrire UK, est justement l'un des codes que la documentation de Google elle-meme signale comme n'ayant aucun effet ; le code valide est GB. Un code pays seul ne fonctionne pas non plus. Rien de tout cela ne declenche d'erreur pendant la compilation. Cela ne fait simplement rien, en silence, tant que personne ne verifie.
Une decision qui n'a pas sa place dans cette liste, parce que ce n'est pas vraiment un probleme hreflang, est de savoir s'il faut gerer des marches separes sur des domaines nationaux, des sous-domaines ou des dossiers du site principal. La documentation de Google n'enonce aucune preference de classement entre les trois, et un sous-domaine specifique a une langue ne dit meme pas a lui seul a Google quel est le public vise ; cela doit etre fixe explicitement ailleurs. Quelle que soit la structure deja utilisee par un annuaire, il est tres peu probable que ce soit la raison pour laquelle ses pages traduites ne fonctionnent pas. Les trois erreurs ci-dessus le sont presque toujours.
Ce qu'il faut vraiment verifier avant d'ajouter une onzieme langue
Commencez par les annonces, pas par le gabarit. Pour chaque profil individuel, decidez honnetement si le contenu principal, les mots de l'annonceur lui-meme, existe en plus d'une langue. Si ce n'est pas le cas, cette page a exactement une version linguistique reelle, quoi que dise le gabarit du site, et le geste honnete est de la laisser vivre a une seule adresse plutot que d'en fabriquer neuf autres qui disent la meme chose.
Pour les pages reellement traduites, les pages statiques et de categorie ou quelqu'un a vraiment reecrit le texte, verifiez a la main les liens reciproques sur un echantillon de pages apres chaque modification : ouvrez le code source, confirmez que la liste des langues alternatives de la page A inclut la page B et que la liste de B inclut A, dans les deux sens, pour chaque langue que le site pretend prendre en charge. Une paire cassee ici est invisible tant qu'elle n'est pas verifiee.
Pour les annonces qui ne seront jamais traduites, deux options honnetes existent. Soit servir l'annonce uniquement dans la langue ou elle a reellement ete ecrite, sans aucune declaration de langue alternative associee, soit traduire les parties qui comptent vraiment pour la recherche, le titre et la courte description, tout en precisant clairement que l'annonce complete reste dans sa langue d'origine. Ce qui ne fonctionne pas, c'est une adresse qui declare une traduction que la page ne contient pas.
Verifiez que les codes de region correspondent exactement a la liste ISO, GB plutot que UK etant l'erreur la plus courante au premier essai, et resistez a l'envie de coller x-default sur chaque page au lieu de la seule page concue pour l'utiliser. Rien de tout cela n'est un travail complique. Un apres-midi avec un tableur d'adresses et l'habitude de regarder le code source suffisent, et c'est bien moins cher que de decouvrir six mois plus tard pourquoi le trafic de neuf langues nouvelles n'est jamais arrive. Qu'une page apparaisse ou non dans la recherche depend d'abord d'une serie d'interrupteurs distincts, mais rien de tout cela n'a d'importance si la page traduite en question n'a jamais vraiment ete une page differente.


