← retour Vieille machine à écrire sur un bureau avec des papiers montrant différents scripts de langue en lumière d'après-midi tardive

Traduire WordPress sans casser votre SEO

Un client m'a contacté en 2021 avec une boutique WooCommerce qui fonctionnait magnifiquement en anglais depuis trois ans. Des classements solides. Un trafic correct. Ensuite, son agence l'a « internationalisée » pour les marchés français et allemand. Six semaines plus tard, les classements en anglais avaient chuté de 40 %. Les pages en français et en allemand étaient indexées, mais Google était confus quant à quelle version servir pour quelle requête. Personne n'avait touché aux balises hreflang. Personne n'avait pensé à la structure d'URL. La « traduction » était juste du contenu dupliqué assis sur le même domaine avec une chaîne de requête comme ?lang=fr.

J'ai passé deux week-ends à démêler ce gâchis. Alors laissez-moi vous épargner la même douleur.

Traduire un site WordPress n'est vraiment pas difficile une fois que vous comprenez ce que Google demande réellement. Le problème, c'est que la plupart des tutoriels s'arrêtent à « installez un plugin, ajoutez vos langues, c'est fait ». C'est là que les dégâts SEO commencent.

---

Pourquoi la traduction casse le SEO (et pourquoi la plupart des gens ne le remarquent pas immédiatement)

Les moteurs de recherche sont pointilleux sur le contenu dupliqué. Quand vous ajoutez une version française de votre page d'accueil et qu'elle se trouve à yourdomain.com/?lang=fr au lieu de yourdomain.com/fr/ ou fr.yourdomain.com, Google traite souvent les deux URL comme la même page avec un contenu légèrement différent. Aucune version ne se classe bien. Votre page anglaise existante peut commencer à perdre de l'autorité car les signaux sont dilués.

Le deuxième problème : hreflang. C'est l'attribut HTML qui dit à Google « cette page en français est l'équivalent de cette page en anglais ». Mal le faire et vous créez ce que Google lui-même appelle une erreur de « balise de retour », où la chaîne hreflang est cassée et Google ignore le tout.

J'ai vu cela sur un projet Seahawk pour un client SaaS en 2023. Ils avaient 11 langues ajoutées via un plugin, mais le plugin générait des balises hreflang uniquement pour les pages qu'il avait traduites. Les pages non traduites n'avaient pas de balise hreflang auto-référencée. Résultat : Google a commencé à désindexer les versions anglaises de ces pages parce qu'il les prenait pour des doublons orphelins. Pas malveillant, juste une configuration négligente.

La correction n'est pas compliquée. Mais vous devez être délibéré à ce sujet dès le premier jour.

---

Choisir la bonne structure d'URL avant de toucher à un plugin

C'est la décision qui verrouille votre architecture. Vous avez trois options.

  1. Sous-répertoires : yourdomain.com/fr/, yourdomain.com/de/, ma recommandation par défaut pour la plupart des sites.
  2. Sous-domaines : fr.yourdomain.com, de.yourdomain.com, fonctionne bien si vous voulez traiter chaque langue comme une propriété distincte dans la Search Console.
  3. Domaines séparés (ccTLD) : yourdomain.fr, yourdomain.de, signal de géo-ciblage le plus fort, mais coûteux et complexe à maintenir.

Pour 90 % des sites que je construis, les sous-répertoires gagnent. Ils héritent de l'autorité du domaine, ils sont plus simples à gérer dans une seule installation WordPress, et Google les traite bien. La seule fois où je choisirais un sous-domaine ou un ccTLD, c'est quand un client a des exigences sérieuses de géo-ciblage et une équipe dédiée pour chaque marché.

Choisissez votre structure avant d'installer un seul plugin de traduction. La changer plus tard signifie des redirections 301, des hreflang mis à jour, des sitemaps mis à jour, et au moins quelques semaines de turbulence de classement. J'ai appris cela à mes dépens sur le site d'un client d'hôtellerie en 2020 où nous avons basculé de sous-domaines à sous-répertoires au milieu du projet. Douloureux.

---

Choisir un plugin de traduction qui ne combattra pas votre SEO

Il y a trois plugins qui méritent votre attention. Tout le reste est du bruit.

WPML

WPML est ce que j'utilise sur presque chaque construction multilingue professionnelle chez Seahawk. Ce n'est pas gratuit (commence autour de 39 $/an pour la licence basique), mais il génère des balises hreflang propres, gère correctement la structure d'URL, s'intègre à WooCommerce sans problème, et dispose d'un module String Translation pour des choses comme les labels de navigation et le texte des widgets.

La seule chose que vous devez faire : allez à WPML > Languages > Language URL format et choisissez « Different languages in directories » (c'est-à-dire l'option sous-répertoire) sauf si vous avez une raison spécifique de ne pas le faire. Le défaut est parfois défini sur les chaînes de requête. Changez-le.

Polylang

Polylang est l'alternative gratuite et c'est vraiment solide pour les sites plus simples. La version gratuite gère la structure d'URL et hreflang basique. Vous voudrez la version Pro (99 $/an) si vous exécutez WooCommerce ou avez besoin de fonctionnalités de gestion de traduction. Je l'ai utilisé sur un petit site d'ONG l'année dernière et il s'est comporté parfaitement pour trois langues.

TranslatePress

TranslatePress fonctionne différemment : vous traduisez directement sur le front end, visuellement. C'est idéal pour les clients qui veulent gérer leurs propres traductions. L'extension SEO pack (payante) gère hreflang et la traduction des métadonnées. Sans elle, vos pages traduites auront des titres et descriptions en double. Ne la skipper pas.

Évitez la traduction automatique comme seule couche. Une traduction automatique avec DeepL ou Google Translate va bien comme brouillon de départ, mais elle a besoin d'une relecture humaine avant publication. Un contenu mal traduit et superficiel se classe mal et crée une mauvaise expérience utilisateur. Je dis toujours aux clients : si votre contenu traduit semble écrit par quelqu'un qui ne parle pas la langue, Google le découvrira aussi.

---

Configurer correctement les hreflang

Les hreflang, c'est ce que la plupart des développeurs ratent. Voici les règles, sans détours :

  • Chaque page a besoin d'une balise hreflang pour chaque version linguistique de cette page, y compris elle-même.
  • Vous devez inclure x-default pointant vers la version à servir quand aucune préférence linguistique ne correspond.
  • La valeur hreflang doit correspondre à une balise de langue BCP 47 valide. Cela signifie en-gb et non en-GB (minuscules, tirets, code région après la langue).
  • La relation doit être réciproque. Si /fr/ pointe vers /en/ via hreflang, alors /en/ doit pointer en retour vers /fr/.

WPML gère la plupart de cela automatiquement. Mais je valide toujours manuellement avec Hreflang Tags Checker by Aleyda Solis après configuration. C'est gratuit et prend environ trois minutes à exécuter. Ça vaut chaque seconde.

Un cas limite : si vous avez des pages pas encore traduites. Ne les laissez pas sans hreflang. Soit pointez x-default vers la version anglaise, soit ajoutez une hreflang auto-référencée pour l'anglais uniquement jusqu'à ce que la traduction soit prête. Une lacune dans la chaîne hreflang fait plus de dégâts que vous ne le pensez.

---

Plans de site, Search Console et budget de crawl

Une fois vos pages traduites en ligne, vous avez besoin de trois choses avant que Google les voie.

  1. Soumettez un plan de site qui inclut toutes les versions linguistiques. WPML et Polylang génèrent tous deux des plans de site multilingues automatiquement quand combinés avec Yoast SEO ou Rank Math. Vérifiez que le plan de site sur yourdomain.com/sitemap.xml liste réellement vos URLs /fr/ et /de/ avant de rien soumettre.
  2. Ajoutez chaque répertoire linguistique comme propriété séparée dans Google Search Console si vous voulez des données de performance granulaires par langue. Ou ajoutez-les comme préfixes au sein de la même propriété de domaine racine. L'un ou l'autre fonctionne, mais les propriétés séparées vous donnent des données plus nettes.
  3. Pensez au budget de crawl. Pour un site avec 500 pages et 5 langues, vous vous retrouvez soudainement avec jusqu'à 2 500 URLs indexables. Google n'a pas un appétit illimité pour le crawling. Assurez-vous que vos pages traduites ne sont pas derrière du rendu JavaScript inutile, n'ont pas de balises noindex restantes de la préproduction, et se chargent raisonnablement vite. Moins de 3 secondes en mobile, c'est mon objectif de travail.

Une note rapide sur Rank Math : son module Multilingual SEO fonctionne bien avec WPML et Polylang et vous permet de définir des titres et descriptions de métadonnées traduits par langue depuis l'interface Rank Math familière. J'ai changé un client de Yoast à Rank Math spécifiquement pour cette raison en mars dernier et le workflow s'est considérablement amélioré.

---

Gérer les métadonnées traduites et l'optimisation sur la page

Les slugs d'URL traduits comptent. /fr/a-propos/ fonctionne mieux que /fr/about/ pour les chercheurs francophones. Cela signale à la fois aux utilisateurs et à Google que c'est une page véritablement localisée, pas une copie directe.

WPML vous permet de définir des slugs traduits. Polylang aussi. Utilisez-les. Je sais que c'est du travail supplémentaire. Faites-le de toute façon.

Les titres et descriptions de métadonnées doivent être traduits et réécrits pour chaque marché, pas juste passés à travers un traducteur mot à mot. L'intention de recherche varie selon la langue. Un utilisateur français cherchant votre produit peut utiliser une formulation différente d'un utilisateur anglophone. Une recherche de mots clés par langue, même une recherche basique avec Google Keyword Planner ou Ahrefs, fait une vraie différence pour la performance des pages traduites.

Le texte alternatif des images est souvent totalement oublié. Vos pages traduites devraient avoir un texte alternatif dans la langue cible. Pareil pour tout balisage de schéma incluant des champs texte.

Une chose de plus qui piège les gens : les menus WordPress. Si votre navigation a « À propos » en anglais, vous avez besoin d'un élément de menu traduit en français pointant vers /fr/a-propos/. WPML a une fonctionnalité de synchronisation de menu qui vous invite à traduire les éléments de menu. Utilisez-la. Sinon vous obtenez des pages françaises avec une navigation en anglais, ce qui semble négligé et confond les crawlers.

---

Tester avant de lancer

Ne sautez pas cette étape. Je passe en revue une checklist rapide sur chaque projet multilingue avant de basculer en production.

  • Vérifiez les balises hreflang sur au moins la page d'accueil, une page intérieure et une page produit ou blog par langue. Consultez le code source ou utilisez une extension navigateur comme SEO Meta in 1 Click.
  • Analysez le site avec Screaming Frog. Filtrez par hreflang dans l'onglet Hreflang. Toute erreur "non-200" ou "missing return tag" doit être corrigée avant le lancement.
  • Confirmez que votre sitemap XML liste toutes les URLs par langue et soumettez-le dans Search Console.
  • Testez le changement de langue dans une fenêtre de navigation privée pour vous assurer que les cookies ou les redirections de géolocalisation n'envoient pas les utilisateurs vers la mauvaise version.
  • Vérifiez que les pages traduites retournent des codes de statut 200, pas des 301 ou 404.

La checklist complète prend environ 90 minutes sur un site de taille moyenne. Ces 90 minutes m'ont épargné au moins quatre crises post-lancement au fil des ans.

---

FAQ

La traduction de mon site me garantit-elle un classement dans d'autres pays ?

Non. La traduction est un prérequis, pas une garantie. Vous avez toujours besoin de backlinks depuis des domaines locaux pertinents, une véritable demande de recherche locale et un contenu qui répond réellement à l'intention de l'utilisateur sur ce marché. La traduction ouvre la porte. Le travail SEO dans chaque langue vous fait passer le seuil.

Puis-je utiliser Google Translate ou DeepL pour traduire automatiquement l'ensemble de mon site ?

Vous pouvez les utiliser comme brouillon initial. WPML et TranslatePress intègrent tous deux DeepL pour la traduction automatique. Mais publier une traduction brute sans révision humaine est une mauvaise idée. Le contenu se lit maladroitement, ce qui augmente le taux de rebond, et les évaluateurs de qualité de Google évaluent bel et bien la qualité de la traduction sur les sites plus importants.

Chaque langue doit-elle avoir sa propre propriété Google Search Console ?

Cela dépend de votre structure d'URL. Si vous utilisez des sous-répertoires (yourdomain.com/fr/), une propriété de domaine racine dans Search Console couvre tout, mais l'ajout d'une propriété de préfixe d'URL spécifiquement pour /fr/ vous donne des données plus propres par langue. Si vous utilisez des sous-domaines, vous aurez besoin de propriétés distinctes. Pour les ccTLD, vous n'avez pas le choix, ce sont des domaines séparés.

Et si je veux traduire seulement quelques pages, pas tout le site ?

C'est parfait. Assurez-vous simplement que ces pages traduites ont un hreflang approprié pointant vers leurs équivalents anglais, et que les pages anglaises pointent vers les versions traduites. La traduction partielle est une approche légitime, surtout pour les sites où seule une section produit ou landing page cible un marché étranger.

Vaut-il mieux engager un traducteur professionnel ou la traduction automatique suffit-elle ?

Pour tout ce qui est public, je dirais toujours faire relire le résultat par un traducteur humain. Pour un petit site brochure avec 10 pages, le coût est minimal. Pour un large catalogue WooCommerce, vous pourriez utiliser la traduction automatique pour le contenu en masse et la révision humaine pour les pages à forte valeur comme les descriptions de produits, les flux de paiement et les pages légales. Cette approche mixte fonctionne bien en pratique.

---

La traduction bien faite est l'une de ces choses qui s'accumulent silencieusement. Vous la mettez en place correctement une fois, Google indexe tout proprement, et sur 12 à 18 mois votre empreinte organique sur un nouveau marché se développe sans que vous ayez à reconstruire quoi que ce soit. Si vous vous trompez sur l'architecture, vous vous battez contre Google indéfiniment. Le travail du plugin est la partie facile. Les décisions structurelles, le format d'URL, le hreflang, les métadonnées traduites, c'est là que se situe le vrai travail. Consacrez un après-midi supplémentaire pour bien maîtriser ces éléments. Votre moi du futur vous en sera reconnaissant.

← retour