WPML : configurer un site multilingue qui plaît à Google

Un site multilingue mal configuré est pire qu’un site monolingue : Google indexe des pages à moitié traduites, sert la version espagnole à des visiteurs allemands, ou considère vos langues comme du contenu dupliqué. Nous récupérons régulièrement des sites dans cet état, et dans neuf cas sur dix, le problème n’est pas le plugin : c’est la configuration.

WPML, l’outil de référence du multilingue WordPress, fait correctement les choses par défaut sur l’essentiel. Mais « par défaut » ne suffit pas dès qu’on vise un vrai référencement par langue : il y a une dizaine de décisions à prendre, et certaines sont irréversibles sans casse SEO.

Nous exploitons WPML sur des sites de production en trois à six langues, du B2B industriel au tourisme. Voici la configuration que nous appliquons, décision par décision, et les pièges que nous avons appris à contourner sur le terrain.

Avant de commencer : la bonne licence

Vérifié à la date de cet article, WPML (lien partenaire, sans surcoût pour vous) existe en trois licences : Blog à 39 €/an, Multilingual CMS à 99 €/an, Agency à 199 €/an. Soyons directs : pour un site professionnel, c’est Multilingual CMS minimum. C’est elle qui apporte la traduction des chaînes (String Translation), la gestion de traduction et la compatibilité constructeurs de pages, indispensables en pratique. Elle couvre 3 sites et inclut 90 000 crédits de traduction automatique. La licence Agency (sites illimités, WooCommerce Multilingual, 180 000 crédits) ne se justifie que si vous gérez plusieurs sites ou une boutique.

Si vous hésitez encore entre WPML et les autres approches du multilingue (surcouches type Weglot, pipeline IA), nous avons publié un comparatif complet : WPML, traduction IA, ou les deux ?. Ici, on part du principe que WPML est choisi, et on le configure pour Google.

Structure d’URL : la décision irréversible

Première décision, la plus structurante : où vivent vos langues ? WPML propose trois formats.

Format	Exemple	Verdict SEO
Sous-dossiers	site.com/de/	Notre recommandation par défaut : une seule autorité de domaine, mutualisée entre les langues
Domaines séparés	site.de, site.fr	Pertinent uniquement avec une vraie stratégie locale par pays (marque, contenus, liens distincts par marché)
Paramètre d’URL	site.com/?lang=de	À proscrire : URLs faibles, mal partagées, mal indexées

Le sous-domaine (de.site.com) n’est même pas proposé par WPML, et c’est tant mieux : Google le traite peu ou prou comme un domaine à part, sans les bénéfices.

Concrètement : sauf stratégie multi-pays assumée avec des moyens dédiés par marché, prenez les sous-dossiers. Chaque lien gagné par n’importe quelle langue renforce toutes les autres. C’est la configuration de nos sites en production, du trilingue FR/EN/ES de JC Industries au quadrilingue de No Upwind.

Décidez-le avant le lancement : changer de structure ensuite signifie migrer toutes les URLs traduites, avec redirections et pertes temporaires à la clé.

Hreflang : ce que WPML fait bien, et ce qu’il faut vérifier

Le hreflang est la balise qui dit à Google « cette page existe aussi en allemand, ici ». Sans elle, Google devine, et devine mal.

Bonne nouvelle : WPML génère automatiquement les annotations hreflang pour chaque contenu traduit, y compris le x-default. Mais trois vérifications s’imposent, car nous avons vu chacun de ces cas en production :

• Les paires doivent être réciproques. Si la page FR pointe vers la DE mais pas l’inverse (page traduite puis repassée en brouillon, par exemple), Google ignore l’annotation. Auditez avec un crawler (Screaming Frog fait ça très bien) après chaque lot de traductions.
• Réglez les codes régionaux à bon escient. de cible tous les germanophones, de-CH seulement la Suisse. Sauf besoin réel de ciblage par pays, restez sur les codes langue simples : sur-préciser fragmente vos signaux.
• Ne traduisez que ce qui est traduit. Le pire réglage de WPML est « afficher le contenu original dans les langues sans traduction » : il crée des dizaines d’URLs allemandes au contenu français, du duplicate content annoté hreflang. Préférez ne pas publier une langue tant qu’elle est incomplète.

Slugs traduits : le détail qui différencie

Une page /en/nos-services/ fait désordre. WPML permet de traduire les slugs, et il faut le faire systématiquement : /fr/nos-services/ devient /en/our-services/, /de/unsere-leistungen/. Le mot-clé dans l’URL est un signal faible, mais la cohérence linguistique de l’expérience, elle, joue sur le taux de clic depuis les résultats de recherche.

Deux points de vigilance : les slugs des types de contenus personnalisés et des taxonomies (réglage séparé, dans WPML puis String Translation), et les slugs des pages construites avec un page builder, à vérifier un par un. Sur un site e-commerce, traduisez aussi les bases d’URL (/produit/, /product/, /produkt/).

Traduire les metas, pas seulement les pages

Un piège classique : le contenu est traduit, mais les title et meta descriptions restent dans la langue d’origine, parce qu’ils vivent dans le plugin SEO et pas dans l’éditeur. Résultat : des snippets français sur des pages anglaises dans Google.

WPML s’interface avec les principaux plugins SEO (Yoast, Rank Math, SEOPress) : leurs champs apparaissent dans l’éditeur de traduction. Ce qu’il faut traiter, dans l’ordre d’impact : les title, les meta descriptions, les données Open Graph, puis les modèles de titres globaux et les chaînes du plugin SEO lui-même via String Translation. Astuce de production : ne traduisez pas les metas littéralement, réécrivez-les. Une meta description est un texte publicitaire ; ce qui fait cliquer un Français ne fait pas forcément cliquer un Allemand.

Les pièges qui ne pardonnent pas

Notre liste noire, constituée sur de vrais projets, y compris des sites cinq langues comme Tige Boats, distributeur européen de bateaux américains :

Les médias. WPML duplique les entrées de médias entre langues. Traduisez les attributs alt (signal SEO image et accessibilité), et vérifiez que les images placées dans les contenus traduits pointent vers l’entrée de la bonne langue, sinon les galeries et les vignettes se mélangent.

Les formulaires. Le formulaire de contact reste souvent dans la langue d’origine : libellés, messages d’erreur, message de confirmation. Selon le plugin de formulaire, la traduction passe par la duplication du formulaire par langue ou par String Translation. Testez l’envoi réel dans chaque langue, pas seulement l’affichage.

Les emails. Le grand oublié : le client allemand commande sur la version allemande et reçoit une confirmation en français. Emails transactionnels WooCommerce, notifications de formulaires, répondeurs : tout doit passer par String Translation ou WooCommerce Multilingual, et être testé par un vrai achat ou envoi de test par langue.

Les chaînes du thème et des widgets. Boutons « Lire la suite », fils d’Ariane, mentions du footer : scannez le thème dans String Translation, puis parcourez chaque langue page par page. Une seule chaîne française sur une page allemande suffit à décrédibiliser l’ensemble.

Le sélecteur de langue. Il doit lier chaque page à sa traduction exacte, pas à l’accueil de l’autre langue. C’est le comportement par défaut de WPML, mais certains thèmes le court-circuitent avec leur propre sélecteur : vérifiez.

Et la traduction elle-même ?

Tout cet article porte sur la tuyauterie, à dessein : c’est elle qui décide de l’indexation. Mais la tuyauterie ne remplit pas les tuyaux. La traduction automatique brute de WPML est correcte pour comprendre, insuffisante pour convaincre et pour se différencier dans les résultats de recherche.

Notre pratique, détaillée dans notre article sur les approches du multilingue : l’architecture WPML pour la structure, des agents IA pour produire des déclinaisons rédigées (avec glossaire et contexte métier), et une relecture humaine, native quand l’enjeu le justifie. C’est ce pipeline qui nous permet de maintenir des sites de trois à six langues sans que les langues secondaires deviennent des langues de seconde zone.

Questions fréquentes

WPML ralentit-il le site ?

Moins qu’avant : les versions récentes ont sérieusement optimisé le chargement des traductions de chaînes, historique point noir. Sur nos sites en production, l’impact est marginal avec une configuration propre : limiter les langues affichées aux langues réellement publiées, purger les chaînes obsolètes, et s’appuyer sur un hébergement avec cache serveur correct. Un site multilingue lent l’est rarement à cause de WPML seul.

Combien coûte WPML en 2026 ?

Trois licences annuelles, vérifiées à la date de cet article sur le site de WPML : Blog à 39 € (trop limitée pour un site professionnel), Multilingual CMS à 99 € (3 sites, toutes les fonctionnalités, 90 000 crédits de traduction automatique), Agency à 199 € (sites illimités, WooCommerce Multilingual, 180 000 crédits). Le renouvellement annuel bénéficie d’un tarif réduit ; il donne droit aux mises à jour et au support, et nous le recommandons vivement sur un site vivant.

Google va-t-il pénaliser mes pages traduites comme contenu dupliqué ?

Non, à condition que le hreflang soit correct : des pages traduites sont des contenus différents aux yeux de Google, pas des doublons. Le vrai risque de duplication vient du réglage qui affiche le contenu original sur les URLs des langues non traduites : là, vous créez réellement des pages identiques sous des URLs différentes. Publiez une langue quand elle est traduite, pas avant.

Dois-je traduire tout le site d’un coup ?

Non, mais traduisez par ensembles cohérents : une langue publiée doit couvrir au minimum le parcours complet d’un visiteur (accueil, offres, contact, mentions légales) et ses emails transactionnels. Publier une langue avec 3 pages traduites sur 40 donne des impasses de navigation et des signaux faibles à Google. Mieux vaut deux langues complètes que cinq langues squelettiques, quitte à ajouter les suivantes ensuite.