Faut-il traduire ses URL ? Quand cela aide et quand cela coûte cher

La traduction des URL est l'une de ces décisions multilingues qui semblent purement techniques, mais qui s'avèrent stratégiques. /fr/summer-dresses ou /fr/robes-ete. C'est une petite différence à l'écran, mais une grande différence en termes de conséquences, car les URL sont la partie d'un site web que les autres personnes copient, vers laquelle elles créent des liens et qu'elles indexent.

La réponse courte est que les traduire est généralement une bonne idée, que le gain est plus faible que ce que prétendent la plupart des guides, et que le coût d'une mauvaise manipulation sur un site en ligne est bien supérieur au bénéfice obtenu.

Ce que vous gagnez réellement

Les mots contenus dans une URL constituent un signal de classement faible. Ils le sont depuis des années, et quiconque vous affirme qu'un slug traduit vous fera monter dans les résultats de recherche essaie de vous vendre quelque chose.

Ce que les URL traduites vous apportent réellement, c'est de la confiance et une meilleure propension au clic. Un acheteur français consultant les résultats voit une adresse en français et la considère comme un site français. Quelqu'un qui colle votre lien dans un message comprend immédiatement de quoi parle la page. Sur les marchés où la langue source n'est pas largement lue, une URL non traduite apparaît comme un sous-dossier généré automatiquement d'un site étranger, et cette impression coûte plus de clics que ce que le signal de classement n'aurait jamais pu apporter.

Il existe aussi un avantage interne que personne ne mentionne : votre propre équipe peut lire les analyses. Un rapport de trafic rempli d'URL traduites est lisible pour la personne qui gère ce marché.

Ce que cela coûte si vous vous trompez

Modifier une URL qui existe déjà signifie que chaque lien vers celle-ci, chaque entrée dans un index et chaque signet pointe désormais vers quelque chose qui doit être redirigé ou qui a disparu.

Sur un site sans historique, cela ne coûte rien. Sur une boutique vieille de cinq ans avec des backlinks, c'est la cause la plus fréquente d'une chute de trafic après un projet multilingue, et c'est pourtant tout à fait évitable.

Deux règles couvrent presque tous les cas.

Décidez avant le lancement, pas après. Traduire un slug au premier jour ne coûte rien. Le traduire deux ans plus tard nécessite un plan de redirection.

Si vous en modifiez une, redirigez-la. Pas un lien "soft" depuis le sitemap. Une vraie redirection 301 de l'ancienne adresse vers la nouvelle, conservée aussi longtemps que quoi que ce soit pointe encore vers l'ancienne, ce qui est plus long que vous ne le pensez.

La plateforme détermine le niveau de danger

C'est la partie que la plupart des guides omettent, et cela change complètement le risque.

PrestaShop vous protège par défaut. Ses routes standards intègrent l'ID de l'objet : /3-vetements, /hommes/1-1-chemise.html. Le contrôleur frontal lit l'ID, constate que la réécriture ne correspond plus et redirige vers l'adresse actuelle. Modifier la réécriture d'un produit ou d'une catégorie ne génère donc pas d'erreur 404.

L'exception concerne les pages statiques, dont les réécritures ne comportent aucun ID. Traduisez /content/1-livraison et l'ancienne adresse devient une véritable 404. Ce sont précisément ces pages qui accumulent les backlinks, elles nécessitent donc une redirection.

WordPress ne vous protège pas du tout. Un permalien est l'adresse. Modifiez un slug et l'ancienne URL est morte, sauf si quelque chose la redirige. WordPress tentera parfois de deviner la nouvelle page, mais ce comportement n'est pas fiable et ne survit pas à un changement de slug dans une autre langue.

La même décision est donc presque gratuite sur une plateforme et nécessite une planification sur l'autre. Tout outil modifiant des URL sur un site en production doit capturer les anciennes adresses et servir des redirections. Vous devez vérifier cela avant de le laisser fonctionner.

Les arguments pour ne pas les traduire

Trois situations où laisser les URL telles quelles est la meilleure solution.

Scripts non latins. Japonais, chinois, coréen, arabe, thaï. La translittération produit des adresses qui ne sont ni lisibles ni utiles. La translittération automatique habituelle est encore pire : les kanjis japonais sont souvent traduits en pinyin chinois, ce qui n'a aucun sens pour un lecteur japonais. Les caractères natifs encodés en pourcentage sont techniquement valides, mais hostiles à lire dans un message ou un e-mail. Gardez le slug latin et consacrez vos efforts au titre et à la méta-description, là où l'internaute japonais regarde réellement.

Sites avec beaucoup de liens entrants par page. Un éditeur avec des milliers d'articles liés en externe assume une vaste surface de redirection pour un bénéfice limité. Traduisez les URL du nouveau contenu, mais laissez les archives tranquilles.

Pages de courte durée. Pages de campagne, collections saisonnières, tout ce que vous supprimerez dans trois mois. Cela n'en vaut pas la peine.

Les erreurs qui transforment une bonne idée en mauvaise

Traduire le préfixe de langue. Le segment /fr/ ou /de/ est un code, pas un mot. Laissez-le tel quel. Certaines configurations se retrouvent avec /francais/ ou un préfixe traduit qui ne correspond plus à la définition de la langue, et la détection de langue cesse de fonctionner.

Laisser les slugs diverger des titres. Si un titre est réécrit plus tard et que le slug suit automatiquement, vous avez modifié une URL sans vous en rendre compte. Les slugs doivent être statiques : générés une fois à partir du premier titre, puis laissés intacts, sauf si vous les modifiez délibérément en ajoutant une redirection.

Slugs en double selon les langues. Deux pages dans des langues différentes avec le même slug traduit peuvent entrer en conflit selon la configuration du routage. La plupart des plateformes le gèrent, d'autres ajoutent un suffixe, et celles qui le font silencieusement produisent des adresses que personne ne souhaitait.

Oublier le sitemap et les balises hreflang. Les deux doivent porter les nouvelles adresses. Si le sitemap annonce toujours les anciens slugs, vous demandez aux moteurs de recherche d'explorer une chaîne de redirection sur chaque page.

Une décision que vous pouvez prendre en cinq minutes

Traduisez vos URL si : le site est nouveau ou les pages sont nouvelles, votre marché cible utilise un script latin, et la plateforme ou l'outil capture les redirections pour tout ce qui change.

Laissez-les tranquilles si : le script n'est pas latin, les pages ont des liens entrants importants sans plan de redirection, ou le contenu est temporaire.

Et peu importe votre choix, soyez cohérent. Une boutique avec la moitié de ses catégories traduites et l'autre non semble moins professionnelle qu'une boutique qui n'en a jamais traduit aucune.

Si vous migrez depuis une autre configuration multilingue et que les anciennes adresses sont déjà dans l'index, la séquence compte plus que la décision elle-même. C'est un sujet en soi, couvert dans comment migrer un site multilingue sans perdre son SEO.