« Pourquoi mon article en anglais s’appelle /en/nos-services/ ? » C’est la question qu’a posée un client en relisant son site tout juste traduit. Le contenu était en anglais, mais l’URL restait en français, héritée du contenu source. Rien de cassé techniquement, mais un signal étrange envoyé à la fois aux visiteurs et à Google : une page en anglais dont l’adresse parle français ne donne pas une image très sérieuse d’un site international.
Traduire le texte visible d’un site multilingue est la partie facile. Traduire les slugs — c’est-à-dire la portion de l’URL qui identifie chaque page, chaque article, chaque catégorie — demande une méthode, sous peine de casser des liens déjà partagés ou de créer des doublons entre langues. Voici comment procéder proprement avec Polylang et avec WPML, deux logiques différentes pour un même objectif.
Pourquoi le slug mérite sa propre traduction
Un slug traduit apporte trois bénéfices concrets. D’abord un gain SEO : Google associe la présence de mots-clés dans l’URL à une pertinence renforcée pour la langue ciblée, même si l’effet reste modeste comparé au contenu lui-même. Ensuite, une meilleure lisibilité pour le visiteur, qui reconnaît immédiatement de quoi parle la page rien qu’en survolant le lien. Enfin, une cohérence perçue par le client final, qui remarque très vite les incohérences de ce genre sur son propre site.
À l’inverse, un slug non traduit n’est jamais bloquant techniquement. Beaucoup de sites multilingues sérieux gardent d’ailleurs des slugs identiques par choix, notamment quand la marque ou le nom du produit reste inchangé d’une langue à l’autre. La traduction du slug est donc un choix éditorial autant que technique, à valider avec le client avant de s’y lancer.
La méthode avec Polylang
Polylang traite chaque traduction d’un contenu comme un post à part entière, relié à l’original par une table de correspondance. Le slug de chaque traduction est donc un champ de post classique, modifiable directement dans l’encart « Permalien » de l’écran d’édition, sans réglage global à activer.
- Ouvrez la traduction anglaise de la page concernée depuis le sélecteur de langues en haut de l’écran d’édition.
- Modifiez le champ du permalien pour y saisir le slug en anglais, sans accent ni caractère spécial.
- Enregistrez, puis vérifiez que l’URL affichée en façade correspond bien à la nouvelle valeur.
- Répétez l’opération pour la taxonomie parente (catégorie ou étiquette) si celle-ci est elle-même traduite.
Le point de vigilance concerne les taxonomies : si une catégorie n’est pas traduite mais que ses articles le sont, l’URL de la catégorie restera dans la langue source pour toutes les langues, ce qui casse la cohérence. Il faut donc traduire systématiquement les taxonomies avant de s’attaquer aux slugs d’articles qui en dépendent.
La méthode avec WPML
WPML stocke les traductions dans des tables dédiées (icl_translations notamment) et gère le slug traduit au même endroit que le contenu, via l’écran de traduction classique ou l’Advanced Translation Editor. Le principe reste proche : chaque traduction possède son propre champ de permalien, éditable indépendamment de l’original.
Une différence pratique : WPML propose un réglage global dans WPML → Réglages pour choisir si les slugs de taxonomies doivent être traduits automatiquement ou laissés identiques entre langues. Ce réglage évite de devoir traduire manuellement chaque catégorie une par une, mais il doit être activé avant de créer les traductions, sinon les slugs déjà générés ne sont pas rétroactivement corrigés.
Éviter les pièges classiques
- Deux traductions différentes ne peuvent pas partager exactement le même slug dans la même langue : WordPress ajoute automatiquement un suffixe numérique en cas de collision, ce qui donne des URL comme
/en/services-2/peu engageantes. - Changer un slug déjà indexé sans redirection casse le référencement acquis : pensez à une redirection 301 vers la nouvelle URL, via une extension comme Redirection ou via les règles internes de Polylang/WPML si elles existent.
- Les slugs de pages système (page de blog, page de recherche) suivent des réglages spécifiques, souvent dans Réglages → Permaliens plutôt que dans l’éditeur de contenu.
Un cas particulier : les sous-pages
Quand une page fait partie d’une hiérarchie (page enfant d’une page parente), le slug traduit de la page enfant doit être cohérent avec le slug traduit du parent, sinon l’URL complète mélange les langues. Un exemple vu en projet : une page « À propos » traduite en anglais donnait bien /en/about/, mais sa sous-page « Notre équipe » restait en /en/about/notre-equipe/ faute d’avoir traduit également le parent en premier.
Notre règle maison : toujours traduire les slugs du haut vers le bas de la hiérarchie, jamais l’inverse. Un parent non traduit condamne toutes ses sous-pages à hériter d’une URL bâtarde.
Vérifier le résultat avant mise en ligne
Une fois les slugs traduits, un contrôle systématique s’impose avant la mise en production. La méthode la plus fiable reste de parcourir chaque langue depuis le sélecteur en façade, page par page, en notant les URL générées dans un tableau simple. Sur un site de taille moyenne (une trentaine de pages), l’opération prend environ vingt minutes et évite des découvertes gênantes après le lancement.
Pour les sites plus volumineux, un export de la table wp_posts filtré par langue permet de repérer rapidement les slugs restés identiques à l’original quand ce n’était pas voulu, en comparant simplement les colonnes post_name entre les lignes liées.
En résumé
Traduire un slug n’est jamais une opération anodine : c’est un engagement vis-à-vis du SEO acquis, qui exige une redirection propre en cas de changement d’URL déjà indexée. La règle qui a le mieux fonctionné sur nos projets tient en une phrase : traduire les taxonomies avant les contenus, les parents avant les enfants, et toujours vérifier en façade avant de livrer. Le gain en cohérence perçue par le client, lui, est immédiat.
