WordPress multilingue : Polylang vs WPML vs TranslatePress comparatif

Pourquoi rendre un site WordPress multilingue en 2026

Depuis 2015, j’ai livré plus de vingt sites WordPress multilingues pour des clients allant du cabinet d’avocats franco-allemand à la PME industrielle qui exporte en Espagne. Le constat est toujours le même : un site traduit correctement génère entre 30 et 60 % de trafic organique supplémentaire sur les marchés ciblés, à condition que le SEO multilingue soit propre dès le départ.

En 2026, trois extensions dominent le marché WordPress francophone : Polylang, WPML et TranslatePress. Chacune a une philosophie différente, un modèle économique distinct et des implications techniques qu’il faut comprendre avant de s’engager. Changer de plugin multilingue en cours de route, c’est souvent des dizaines d’heures de migration et un risque réel de perdre du référencement.

Ce comparatif est basé sur mes installations réelles, avec des vrais temps de chargement mesurés, des vrais budgets clients et les vrais problèmes que j’ai rencontrés. Pas de lien d’affiliation, pas de partenariat avec l’un ou l’autre éditeur.

Avant d’entrer dans le détail de chaque plugin, rappelons que Google recommande officiellement d’utiliser des URL distinctes par langue (sous-répertoires /fr/, /en/ ou sous-domaines) plutôt que de la traduction dynamique côté client. Les trois plugins que je compare ici respectent cette recommandation, contrairement aux solutions basées uniquement sur Google Translate ou des proxys JavaScript. Selon la documentation officielle de Google sur les sites multirégionaux, chaque version linguistique doit avoir sa propre URL explorable et indexable.

Polylang : le choix gratuit et léger

Polylang est développé par WP FLAVOR, une entreprise française basée à Toulouse. C’est le plugin multilingue que je recommande le plus souvent pour les sites vitrines bilingues ou trilingues avec un budget serré. La version gratuite est étonnamment complète.

Ce que Polylang fait bien

Le principe est simple : chaque contenu (article, page, catégorie, tag, menu) existe en autant d’exemplaires que de langues. Polylang crée des posts séparés dans la base de données et les lie entre eux via une taxonomie custom. Cette approche a un avantage majeur : si vous désinstallez Polylang un jour, vos contenus restent intacts dans la base, chacun dans sa langue.

En version gratuite, vous obtenez la gestion complète des langues, le sélecteur de langue en widget ou shortcode, la synchronisation des médias entre les traductions, et la détection automatique de la langue du navigateur. C’est suffisant pour un site vitrine classique avec deux ou trois langues.

La version Pro (99 € par an pour un site) ajoute la traduction des slugs d’URL, la traduction des chaînes du thème depuis l’interface, et le support de certains page builders. C’est un surcoût raisonnable quand on en a besoin.

Les limites que je rencontre en production

Polylang ne traduit pas nativement les options de thème ni les widgets en version gratuite. Si votre thème stocke du texte dans les options (adresse, téléphone, slogan), il faut soit passer en Pro, soit bidouiller avec des filtres PHP. Par ailleurs, la compatibilité avec WooCommerce nécessite l’extension payante Polylang for WooCommerce (99 € supplémentaires par an). C’est un point que beaucoup de clients découvrent trop tard.

Sur les gros sites (plus de 500 articles par langue), j’ai constaté un ralentissement notable du back-office lors de la synchronisation des termes de taxonomie. Rien de bloquant, mais c’est à anticiper. Pour l’optimisation globale de votre WordPress, je détaille les réglages essentiels dans mon guide sur le SEO technique WordPress.

WPML : la référence historique payante

WPML existe depuis 2009. C’est le plugin multilingue le plus installé au monde avec plus de 1,5 million de sites actifs selon l’éditeur OnTheGoSystems. Pendant longtemps, c’était le seul choix sérieux. En 2026, il reste incontournable sur certains projets, mais il n’est plus le choix par défaut que je recommande systématiquement.

Les trois formules de WPML

WPML propose trois niveaux de licence. Le Multilingual Blog à 39 € par an convient pour un blog simple mais ne traduit pas les custom post types ni les custom fields. Le Multilingual CMS à 99 € par an est la version que 90 % des projets nécessitent : elle traduit tout, y compris les types de contenu personnalisés, les champs ACF, et s’intègre avec les principaux page builders. La version Multilingual Agency à 199 € par an permet une utilisation sur un nombre illimité de sites.

Point important : le renouvellement est obligatoire pour les mises à jour et le support. Si vous ne renouvelez pas, le plugin continue de fonctionner mais vous ne recevez plus les correctifs de sécurité ni les mises à jour de compatibilité. Sur un site professionnel, c’est un risque que je déconseille de prendre.

Pourquoi WPML reste pertinent

La force de WPML, c’est son écosystème d’intégrations. Il fonctionne nativement avec WooCommerce (traduction des produits, des variations, des e-mails transactionnels, des devises), avec Elementor, WPBakery, Divi, avec les champs ACF, Toolset et Meta Box. Quand un client me demande un site e-commerce multilingue avec des custom post types complexes, WPML est souvent le choix le plus sûr.

WPML inclut aussi un système de gestion de traduction intégré : vous pouvez assigner des traducteurs, suivre l’avancement, et même connecter des services de traduction automatique (DeepL, Google Translate) directement depuis le tableau de bord. Pour les projets avec beaucoup de contenu, c’est un gain de temps considérable.

Ce qui me pose problème avec WPML

WPML crée plusieurs tables supplémentaires dans la base de données et ajoute des métadonnées à chaque post. Sur les sites avec beaucoup de contenus, j’ai mesuré des requêtes SQL 20 à 40 % plus lentes qu’avec Polylang sur des configurations équivalentes. Ce surcoût en base de données rend aussi les migrations et les sauvegardes plus lourdes. À ce sujet, mon comparatif sur les sauvegardes WordPress détaille les solutions adaptées aux grosses bases.

L’autre problème récurrent, c’est la complexité de l’interface. WPML ajoute des dizaines de sous-menus, des options partout, et le client non technique se perd facilement. J’ai passé des heures à former des clients sur WPML là où Polylang ou TranslatePress se prennent en main en vingt minutes.

TranslatePress : la traduction visuelle depuis le front-end

TranslatePress adopte une approche radicalement différente : au lieu de créer des posts séparés, il stocke les traductions dans une table unique et vous permet de traduire directement depuis une interface visuelle qui ressemble au Customizer de WordPress. Vous voyez votre page telle qu’elle s’affiche, vous cliquez sur un texte, vous le traduisez dans le panneau latéral.

L’approche visuelle qui change tout

C’est le plugin que je choisis quand le client final veut gérer ses traductions en autonomie. Pas besoin d’expliquer la différence entre un post et sa traduction, pas de back-office complexe à naviguer. Le client ouvre le traducteur visuel, il voit sa page, il traduit. Point.

TranslatePress traduit tout ce qui s’affiche à l’écran : le contenu des pages, les chaînes du thème, les textes des plugins, les menus, les widgets, les formulaires. Là où Polylang et WPML nécessitent parfois des configurations spécifiques pour traduire les chaînes de thème, TranslatePress les attrape automatiquement depuis le rendu visuel.

La version gratuite est limitée à une langue supplémentaire. Pour plusieurs langues, il faut passer au plan Personal à 89 € par an (nombre de langues illimité), Business à 149 € par an (détection automatique de langue, traduction automatique via DeepL), ou Developer à 199 € par an (utilisation illimitée sur plusieurs sites).

Les compromis techniques

L’approche par remplacement de chaînes a un coût en performance. TranslatePress intercepte le rendu HTML de chaque page pour remplacer les textes par leurs traductions. Sur un site non mis en cache, j’ai mesuré un surcoût de 50 à 150 ms par page par rapport à un site sans plugin multilingue. Avec un bon système de cache (WP Rocket, LiteSpeed Cache), ce surcoût disparaît pour les visiteurs, mais il reste présent pour les pages non cachées et le back-office.

L’autre limite : TranslatePress ne crée pas de posts séparés. Si vous le désinstallez, vos traductions sont perdues (elles sont dans la table wp_trp_dictionary_). Ce verrouillage est le prix de la simplicité. C’est un point que j’explique systématiquement au client avant de m’engager.

Pour les aspects plus larges de la gestion technique de votre WordPress, notamment le déploiement, je recommande de consulter mon guide sur le déploiement WordPress sur VPS OVH qui couvre la configuration serveur adaptée aux sites multilingues.

Tableau comparatif détaillé des trois plugins

Voici le comparatif que j’aurais aimé trouver quand j’ai commencé à travailler sur des projets multilingues. Tous les prix sont ceux de juin 2026, vérifiés sur les sites officiels.

Quel plugin choisir selon votre type de projet

Après des dizaines de projets multilingues, j’ai développé une grille de décision simple. Le choix dépend de trois facteurs : le budget, la complexité technique du site et l’autonomie souhaitée par le client.

Site vitrine bilingue avec budget limité : Polylang gratuit

Un artisan, un cabinet de conseil ou une association qui veut son site en français et en anglais. Pas de custom post types exotiques, pas de WooCommerce. Polylang gratuit fait le travail proprement. Coût total du plugin : 0 €. C’est le scénario le plus fréquent dans ma pratique freelance, et je n’ai jamais eu de client déçu par ce choix.

Site corporate multilingue avec contenus complexes : WPML

Une entreprise avec des custom post types (références clients, produits, équipe), des champs ACF partout, un page builder, et trois à cinq langues. WPML Multilingual CMS est le choix le plus solide. L’investissement de 99 € par an est vite amorti par le temps gagné sur les intégrations.

Site où le client traduit lui-même : TranslatePress

Un client qui veut modifier ses traductions sans appeler son développeur à chaque virgule. L’interface visuelle de TranslatePress est imbattable sur ce point. Je le recommande aussi pour les sites construits avec des thèmes premium dont les chaînes sont difficiles à traduire autrement.

E-commerce WooCommerce multilingue : WPML ou TranslatePress Business

Pour WooCommerce, Polylang seul ne suffit pas. Il faut soit WPML CMS (qui inclut WooCommerce Multilingual), soit TranslatePress Business. Mon choix par défaut est WPML pour les boutiques avec beaucoup de variations produit et de devises, TranslatePress pour les boutiques plus simples où le client gère seul.

Dans tous les cas, je recommande de configurer les données structurées Schema.org correctement pour chaque version linguistique. C’est un point souvent négligé qui impacte directement la visibilité dans les résultats de recherche locaux.

SEO multilingue : hreflang, slugs et indexation

Le SEO multilingue est le domaine où les erreurs coûtent le plus cher. Un site mal configuré peut voir ses pages se cannibaliser entre langues, ou pire, être ignoré par Google sur certains marchés. Voici les points critiques à vérifier quel que soit le plugin choisi.

Les balises hreflang

Les trois plugins génèrent automatiquement les balises hreflang dans le <head> de chaque page. Ces balises indiquent à Google quelle version linguistique servir à quel utilisateur. Vérifiez systématiquement trois choses après l’installation : que chaque page a bien une balise hreflang pour chaque langue, que les URL sont absolues (pas relatives), et qu’il y a une balise x-default pointant vers la version par défaut.

Pour valider vos hreflang, utilisez l’outil gratuit le validateur hreflang de TechnicalSEO.com qui détecte les erreurs courantes comme les liens non réciproques ou les codes langue incorrects.

La traduction des slugs d’URL

C’est un détail qui fait une vraie différence en SEO. Avoir /en/services/ et /fr/services/ est correct, mais avoir /en/services/ et /fr/prestations/ est meilleur pour le référencement local. Polylang le propose en version Pro, WPML le fait nativement, TranslatePress aussi en version payante.

N’oubliez pas de traduire aussi les slugs de catégories et de tags. C’est un oubli classique que je corrige sur au moins un projet sur trois. Pour les réglages SEO de base à ne pas manquer, consultez mon article sur les 10 réglages SEO techniques WordPress.

Sitemap multilingue et Search Console

Configurez un sitemap XML par langue ou un sitemap unique avec les annotations hreflang. WPML et Polylang s’intègrent avec Yoast SEO et Rank Math pour générer des sitemaps multilingues corrects. TranslatePress génère son propre sitemap si vous activez l’option.

Dans Google Search Console, ajoutez chaque version linguistique comme propriété si vous utilisez des sous-répertoires (/fr/, /en/). Cela vous permet de suivre les performances par langue et de détecter les problèmes d’indexation spécifiques à un marché.

Installation et configuration : les pièges à éviter

En onze ans de WordPress multilingue, j’ai compilé une liste de pièges qui reviennent systématiquement. Les voici, pour vous éviter de perdre des heures de débogage.

Piège n°1 : ne pas figer la structure des permaliens avant d’installer le plugin

Choisissez votre structure de permaliens (/%postname%/ dans 99 % des cas) avant d’activer le plugin multilingue. Changer de structure après l’installation casse toutes les associations entre les traductions et génère des redirections en cascade.

Piège n°2 : oublier de traduire les éléments non visibles

Les balises title, les meta description, les textes alternatifs des images, les libellés de formulaires, les messages d’erreur de WooCommerce. Tout ce qui n’est pas directement visible sur la page est souvent oublié. Avec WPML et Polylang, il faut les traduire manuellement ou via l’interface de traduction de chaînes. TranslatePress les attrape automatiquement si vous les voyez dans le rendu front-end, mais pas les meta tags : il faut un add-on SEO Pack.

Piège n°3 : la traduction automatique comme solution unique

DeepL et Google Translate ont fait d’énormes progrès, mais la traduction automatique brute n’est pas suffisante pour un site professionnel. Je l’utilise comme base de travail pour gagner du temps, puis je fais relire par un natif. La CNIL rappelle d’ailleurs les enjeux de la traduction automatique en matière de données personnelles quand des textes contenant des informations sensibles sont envoyés à des services tiers.

Piège n°4 : ignorer l’impact sur le cache

Un site multilingue multiplie le nombre de pages à mettre en cache. Si vous avez 50 pages et 3 langues, votre cache doit stocker 150 versions. Vérifiez que votre plugin de cache gère correctement la variation par langue (cookie ou URL). LiteSpeed Cache et WP Rocket le font bien, mais certains plugins de cache basiques servent la même version cachée quelle que soit la langue demandée.

Piège n°5 : ne pas tester l’accessibilité du sélecteur de langue

Le sélecteur de langue (dropdown ou drapeaux) doit être accessible au clavier et aux lecteurs d’écran. C’est une obligation RGAA que beaucoup de sites multilingues ignorent. J’en parle en détail dans mon guide sur l’accessibilité RGAA en 2026. Vérifiez que le sélecteur a un attribut aria-label explicite et que le changement de langue est annoncé par les technologies d’assistance.

Piège n°6 : utiliser des drapeaux pour représenter les langues

Un drapeau représente un pays, pas une langue. Le français est parlé en France, en Belgique, en Suisse, au Canada, en Afrique. Utiliser le drapeau français pour représenter la langue française exclut tous les francophones non français. La bonne pratique est d’afficher le nom de la langue dans cette langue : « English », « Français », « Deutsch ». Les trois plugins permettent de configurer cela, mais l’option drapeaux est activée par défaut sur Polylang et WPML.

Pour gérer efficacement la maintenance d’un site multilingue, notamment les mises à jour en masse, WP-CLI est un outil indispensable que je détaille dans un autre article.

Si vous automatisez des tâches autour de votre site multilingue (publication sur les réseaux, synchronisation de contenus), je vous recommande aussi de jeter un œil à mon guide sur l’automatisation avec Make qui s’applique très bien à la gestion multilingue.