Traduire un site WordPress : versions linguistiques explorables et SEO

Traduire un site WordPress ne se limite pas à installer une extension multilingue. Google attend que chaque version linguistique dispose de sa propre URL explorable, avec une navigation et un contenu principal rédigés majoritairement dans une seule langue, ainsi que des balises hreflang réciproques lorsque vous publiez des versions alternatives.

En bref : des URL WordPress distinctes pour chaque langue

Les sites WordPress peuvent évoluer grâce à des extensions, à des réseaux multisites ou à des proxys externes, mais les fondamentaux du SEO restent les mêmes : une URL explorable par langue. Google recommande des URL différentes pour chaque langue ou région, plutôt qu’un fonctionnement reposant uniquement sur les cookies ou la langue du navigateur. Les extensions qui se contentent de remplacer le texte sur /pricing via JavaScript ou des cookies ne laissent aux moteurs de recherche qu’une seule URL à indexer.

Commencez par écarter les sélecteurs de langue qui conservent une URL unique. Choisissez ensuite une structure en répertoires, sous-domaines ou domaines que votre équipe pourra maintenir. Consultez notre article sur le SEO international et le SEO multilingue si vous définissez vos marchés cibles avant de concevoir vos URL.

Les architectures possibles pour un WordPress multilingue

Trois architectures courantes :

1. Extension multilingue sur un seul site — ajoute des préfixes de langue ou des slugs parallèles (/en/about, /fr/a-propos). C’est la solution la plus simple à mettre en œuvre pour les petits sites marketing.
2. WordPress multisite — des sites distincts pour chaque langue, réunis au sein d’un réseau. Une séparation nette, mais une gestion technique plus lourde.
3. Proxy inverse ou couche headless — WordPress reste la source ; une couche en périphérie du réseau ou une couche statique sert les URL des versions linguistiques. Une bonne option pour les architectures aux fortes exigences de performance.

Ces trois approches peuvent répondre aux attentes de Google si chaque version linguistique possède une URL publique distincte et un HTML complet. Aucune ne justifie de changer de langue sur une même adresse en s’appuyant uniquement sur des cookies.

Structures d’URL : répertoires, sous-domaines et domaines

Les répertoires (/de/, /es/) permettent de conserver un seul certificat et une seule propriété Search Console, avec un suivi par langue à partir des chemins d’URL. Les sous-domaines (de.example.com) conviennent aux équipes régionales ou aux règles de CDN. Les ccTLD indiquent un ciblage par pays lorsque vous exploitez des sites véritablement locaux.

Google détermine la langue d’une page à partir de son contenu visible. Choisissez une structure, documentez-la et conservez des permaliens stables après le lancement. Modifier la structure des slugs rompt les groupes de pages reliées par hreflang ainsi que les liens entrants.

Évitez les redirections automatiques fondées sur une langue ou une localisation supposée. Proposez plutôt un sélecteur de langue visible qui renvoie vers l’URL de la version correspondante.

Extension, multisite ou proxy : les compromis

Les extensions (WPML, Polylang, TranslatePress et d’autres) diffèrent par leur interface d’édition et leurs modèles d’URL : évaluez la facilité d’exploration, pas les promesses marketing. Vérifiez que l’extension crée des URL distinctes pour chaque langue, et ne se contente pas de remplacer le contenu par AJAX sur un même permalien.

Le multisite donne à chaque version linguistique ses propres options de thème, menus et utilisateurs. L’exploration est naturellement facilitée, car les sites ont des URL d’accueil distinctes. La contrepartie : l’administration du réseau et les licences d’extensions pour chaque site.

Les approches par proxy peuvent servir rapidement le HTML mis en cache pour chaque langue, mais doivent toujours générer des balises canoniques et hreflang correctes en périphérie du réseau. Les versions linguistiques de WordPress nécessitent des URL publiques distinctes ; un changement de langue reposant uniquement sur les cookies ou JavaScript va à l’encontre des recommandations de Google.

Pour comparer les outils, posez-vous ces questions : chaque traduction dispose-t-elle d’une URL unique ? Les balises hreflang et les sitemaps sont-ils automatisés ou exportables ? L’équipe éditoriale peut-elle relire les traductions en contexte ?

Hreflang, balises canoniques et sitemaps XML

Implémentez hreflang dans WordPress à l’aide d’extensions SEO, d’extensions dédiées à hreflang ou d’entrées xhtml:link dans les sitemaps. Les références hreflang doivent être réciproques : si /en/about fait référence à /fr/a-propos, la page française doit faire référence à la page anglaise et à elle-même, avec les codes correspondants.

Pour chaque langue, faites pointer les balises canoniques vers l’URL privilégiée de cette version linguistique. Ne désignez pas des URL anglaises comme URL canoniques des pages françaises.

Les sitemaps XML de WordPress doivent répertorier les URL de toutes les langues et rester cohérents avec la stratégie hreflang et les balises canoniques. De nombreuses extensions SEO génèrent des sitemaps par langue ; vérifiez qu’ils incluent tous les types de contenus personnalisés traduits, et pas seulement les articles et les pages. Consultez notre présentation d’une plateforme SEO multilingue pour découvrir des méthodes d’audit.

Menus, widgets, médias et chaînes de texte du thème

Les thèmes contiennent souvent du texte anglais codé en dur dans les pieds de page, les boutons et les titres des widgets. Exportez les chaînes du thème via l’interface de traduction de chaînes de votre extension ou au moyen de surcharges dans un thème enfant. Les menus doivent être propres à chaque langue : la navigation française doit renvoyer vers des URL françaises, et non vers des slugs anglais avec des libellés traduits.

Les médias doivent disposer de textes alternatifs et de légendes pour chaque langue. Les mêmes images peuvent être partagées ; les métadonnées doivent correspondre à la langue de la page. Les widgets (recherche, newsletter, articles associés) doivent interroger les contenus dans la langue concernée.

Pour que chaque URL présente un contenu majoritairement dans une seule langue, il faut aussi traduire ces éléments d’interface, et pas seulement le corps des articles.

Le processus éditorial sur WordPress

La maintenance se complique lorsque les traducteurs travaillent uniquement dans l’éditeur d’articles, sans glossaire ni mémoire de traduction. Ajoutez les éléments suivants :

• Glossaire pour les termes produits et juridiques
• Mémoire de traduction pour réutiliser les formulations validées
• Statuts de révision avant publication
• Détection des modifications lors des mises à jour de la version anglaise

Les recommandations de Google sur le contenu utile privilégient les pages conçues avant tout pour les internautes ; les traductions pauvres ou limitées aux textes génériques ne répondent pas à cette exigence. Planifiez des audits réguliers des principales pages de destination dans chaque langue.

Liste de contrôle de mise en œuvre

• Une URL distincte par langue (à vérifier dans le code source et la barre d’adresse)
• Un sélecteur de langue qui renvoie vers les URL des autres versions, et ne repose pas uniquement sur les cookies
• Des balises hreflang réciproques sur les modèles et les types de contenus personnalisés
• Des balises canoniques propres à chaque version linguistique, sans renvoi vers une autre langue
• Des sitemaps XML complets incluant tous les types de contenus publics
• Des menus, widgets, chaînes de texte du thème et textes alternatifs des médias traduits
• Aucune redirection automatique fondée sur la localisation ou la langue qui bloque les robots d’exploration
• Une révision en préproduction dans les langues cibles

Les consignes de Bing aux webmasters soulignent également l’importance d’une structure explorable et d’un contenu utile pour l’indexation sur les différents marchés.

Erreurs courantes

Traduction AJAX sur une URL unique — une seule URL indexée, des versions alternatives invisibles.

Attributs hreflang pointant vers des erreurs 404 ou des redirections — rupture de la réciprocité.

Menus mêlant plusieurs langues — des libellés en français renvoyant vers des slugs en anglais.

Pied de page du thème non traduit — des signaux linguistiques brouillés.

URL canonique en anglais sur les articles traduits — consolidation vers la mauvaise version.

Redirection automatique selon le pays — blocage des robots d’exploration et des utilisateurs.

Traduction automatique sans révision des contenus piliers — des pages localisées de faible qualité.

Les fondamentaux de la recherche traditionnelle et des moteurs de réponse

Les fondamentaux communs aux extensions multilingues WordPress et aux URL publiques des versions localisées restent essentiels pour Google, Bing et les moteurs de réponse : des versions linguistiques explorables, des entités clairement identifiées, des affirmations étayées par des preuves, des données structurées fidèles au contenu et une véritable localisation, plutôt que de simples coquilles en anglais. Considérez les guides ci-dessous comme des éclairages propres à chaque plateforme sur un même niveau d’exigence en matière de publication multilingue.

Guide par plateforme : Google Search

Sur Google Search, la découverte des pages repose sur des URL localisées explorables, avec un HTML adapté à la langue, des titres et des intertitres précis, ainsi que des annotations hreflang réciproques lorsqu’il existe des versions alternatives. Les bases techniques comprennent du contenu indexable, et non des changements de langue reposant uniquement sur des cookies, des métadonnées localisées, des sitemaps et une gestion rigoureuse des URL canoniques. Un contenu de qualité suppose un contenu principal conçu d’abord pour les internautes dans chaque langue ; l’autorité repose sur une identité d’organisation claire et des sources concordantes, pas sur le discours marketing d’un outil de traduction. Conséquence pour le multilingue : chaque URL propre à un marché ou à une langue doit se suffire à elle-même. Mesurez les résultats à l’aide des rapports de couverture et de l’outil d’inspection d’URL de Search Console pour chaque version locale. Ce qui est établi et ce qui reste incertain : Google documente le fonctionnement du multilingue et de hreflang, mais ne garantit aucun positionnement lié à un CMS ou à un processus de post-édition de traduction automatique (MTPE).

Guide par plateforme : Bing

Bing découvre et indexe les pages multilingues explorables dont la structure est claire, avec des exigences de clarté des URL et du contenu similaires à celles de Google. Les bases techniques comprennent des URL localisées accessibles aux robots, du contenu utile et un suivi dans Bing Webmaster Tools. Privilégiez la localisation des titres, des affirmations et des FAQ plutôt que la seule traduction de l’interface. Les signaux d’autorité reposent toujours sur des sources fiables et des entités cohérentes. Conséquence pour le multilingue : ne masquez pas les langues derrière des sélecteurs fonctionnant uniquement côté client. Mesurez l’indexation et les statistiques d’exploration dans Bing Webmaster Tools. Ce qui est établi et ce qui reste incertain : les consignes de Bing mettent l’accent sur du contenu utile et explorable ; n’inventez pas de facteurs de classement propres à Bing pour les outils de traduction.

Guide par plateforme : ChatGPT

ChatGPT peut citer ou résumer des pages accessibles au public lorsque leurs versions linguistiques sont clairement identifiées et que leur contenu se prête à la formulation de réponses. La découverte ne suit pas un classement classique fondé sur l’exploration : la visibilité consiste à être sélectionné comme source ou mentionné dans les réponses. Les bases techniques reposent toujours en premier lieu sur des URL HTML accessibles, et non sur des widgets en surcouche qui masquent le texte. Parmi les qualités utiles du contenu figurent des réponses directes, des FAQ et une terminologie stable issue de glossaires. L’autorité repose sur des preuves et sur la cohérence des entités entre les versions locales. Conséquence pour le multilingue : chaque page localisée doit être compréhensible de manière autonome. La mesure reste imparfaite : considérez les vérifications de citations comme des hypothèses à tester. Ce qui est établi et ce qui reste incertain : aucune garantie documentée n’indique que la MTPE ou une quelconque intégration à un CMS permet d’obtenir des citations dans ChatGPT.

Guide par plateforme : Gemini

Gemini et les expériences d’IA associées de Google bénéficient d’entités cohérentes, de données structurées conformes à la réalité et de pages localisées indexables. La visibilité consiste à être cité ou reconnu, pas à inventer des facteurs de classement pour Gemini. Les bases techniques recoupent les exigences de Google Search en matière d’explorabilité et de qualité des métadonnées. Le contenu doit présenter des affirmations et des définitions claires dans chaque langue. L’autorité dépend de la cohérence de l’identité de l’organisation et d’éléments corroborants. Conséquence pour le multilingue : des noms de produits encadrés par un glossaire réduisent les confusions entre les versions locales. Mesurez les performances de manière classique avec Search Console et analysez qualitativement un échantillon de réponses de l’IA. Ce qui est établi et ce qui reste incertain : le comportement de Gemini ne remplace pas les recommandations documentées de Google Search concernant hreflang et les versions linguistiques.

Guide par plateforme : Google AI Overviews

Google AI Overviews peut proposer des liens vers des pages qui étayent ses réponses ; les critères d’éligibilité reposent toujours sur un contenu indexable, conçu d’abord pour les internautes. Ces aperçus ne sont pas un sélecteur de langue et ne remplacent pas hreflang. Les bases techniques restent un HTML localisé explorable et des données structurées conformes à la réalité. Un contenu de qualité comprend des réponses concises et des titres clairs dans chaque langue. Les signaux d’autorité reflètent les exigences relatives au contenu utile. Conséquence pour le multilingue : aucune page traduite n’est assurée d’être incluse dans un aperçu. Utilisez les rapports de Search Console sur les résultats génératifs lorsqu’ils sont disponibles, tout en suivant séparément les indicateurs d’indexation classiques. Ce qui est établi et ce qui reste incertain : aucun processus de traduction ne peut promettre une présence dans les aperçus.

Le rôle de GlotEO

Les équipes WordPress atteignent souvent les limites des processus improvisés à l’aide d’extensions lorsque la maîtrise du glossaire et la validation SEO deviennent essentielles. GlotEO propose une intégration de traduction pour WordPress qui permet aux équipes marketing de gérer les versions localisées, tandis que WordPress conserve des URL explorables. Consultez les tarifs et les offres de GlotEO ainsi que la plateforme de localisation de sites web pour comparer les options de déploiement.