WordPress multilingue : les problèmes techniques à anticiper

Un site WordPress multilingue peut rencontrer des erreurs d’URL, des traductions non reliées, des conflits d’extensions ou encore servir une page dans la mauvaise langue à cause du cache. Pour les anticiper, choisissez une architecture d’URL cohérente et testez la navigation, les performances et l’indexation dans chaque langue. Ces contrôles sont aussi à reprendre après une migration ou une mise à jour.

Choisir les URL et vérifier les redirections

L’architecture d’un site multilingue détermine la manière dont chaque langue est accessible. Plusieurs configurations sont possibles :

• des sous-répertoires, comme exemple.com/fr/ et exemple.com/en/ ;
• des sous-domaines, comme fr.exemple.com ;
• des paramètres d’URL, comme ?lang=fr ;
• des domaines distincts pour chaque langue.

Ce choix concerne le référencement, mais aussi le routage, le cache, les redirections et les sitemaps. Pour préparer votre configuration, consultez également notre guide pour créer un site multilingue avec WordPress.

Les règles de réécriture et les redirections doivent fonctionner ensemble entre WordPress, l’extension multilingue et le serveur Apache ou Nginx. Une incohérence peut provoquer des pages 404 dans une seule langue, une boucle lors du changement de langue ou la perte d’un slug traduit.

Ces symptômes peuvent apparaître après une migration, une modification des permaliens, l’activation d’un cache ou un changement de configuration d’un proxy ou d’un CDN.

Définissez et documentez votre stratégie d’URL avant de publier les traductions. Avec des sous-répertoires, vérifiez la compatibilité des règles de réécriture et de cache. Avec des sous-domaines, préparez les enregistrements DNS et les certificats TLS, puis testez les cookies d’authentification et de préférence de langue.

Garder les traductions et les extensions cohérentes

Une page mise à jour en français ne l’est pas nécessairement dans ses autres versions. Les blocs, menus, modèles et liens internes peuvent alors diverger, même si toutes les pages restent accessibles.

Relier les contenus traduits

Dans l’interface de votre extension multilingue, vérifiez que chaque traduction est associée à sa page d’origine. Sans cette association, le sélecteur de langue peut renvoyer vers l’accueil au lieu de la page correspondante.

Contrôlez aussi les points suivants :

• Les liens internes mènent vers la version dans la bonne langue.
• Les slugs traduits restent cohérents après une modification des titres ou des permaliens.
• Les menus et leurs éléments sont disponibles dans chaque langue.
• Les contenus dupliqués ne sont pas publiés par erreur comme des traductions distinctes.
• Les traductions non reliées ne deviennent pas des contenus difficiles à retrouver depuis la navigation.

Évitez de coder des URL absolues dans l’éditeur lorsque votre extension propose des liens dynamiques ou une gestion par identifiant. Avant chaque publication, vérifiez la page, sa traduction associée, le menu, les métadonnées et les liens.

Repérer les incompatibilités techniques

Le fonctionnement multilingue dépend aussi du thème et des autres extensions : constructeur de pages, SEO, cache, sécurité, formulaires ou e-commerce. Un conflit peut rester invisible dans la langue principale et n’apparaître que sur un widget, une catégorie ou une page de commande traduite.

Soyez notamment attentif aux éléments suivants :

• Shortcodes et blocs personnalisés : un identifiant de page enregistré peut ne pas correspondre à la traduction.
• Champs personnalisés, notamment ACF : selon leur usage, ils doivent être traduits, copiés ou conservés indépendamment.
• Requêtes WP_Query : un filtre de langue incorrect peut mélanger les contenus.
• Endpoints REST et intégrations CRM : certaines intégrations ne transmettent pas la langue attendue.

Avant d’ajouter une extension, examinez sa documentation, son historique de mises à jour et sa compatibilité avec votre configuration. Notre méthode pour choisir une extension WordPress fiable aide à organiser ces vérifications.

Diagnostiquer une erreur multilingue avec Polylang ou WPML

Avec Polylang, WPML ou une autre extension, un sélecteur qui renvoie vers l’accueil, une traduction invisible ou une taxonomie désynchronisée peuvent avoir plusieurs causes. Le diagnostic doit tenir compte des traductions, des permaliens, du cache et des interactions avec le thème et les extensions.

Procédez dans cet ordre :

1. Reproduisez le problème en navigation privée. Cela permet de partir sans les cookies et les données de navigation habituels.
2. Désactivez temporairement les caches concernés, y compris ceux du serveur ou du CDN, afin de vérifier si une ancienne page est servie. Notez les réglages avant toute modification.
3. Contrôlez les associations de traduction des pages, articles, catégories et produits concernés.
4. Vérifiez les champs personnalisés et leurs réglages de traduction ou de copie.
5. Examinez les permaliens et les redirections, en particulier si le problème suit une migration ou une modification d’URL.
6. Testez un thème standard sur un site de test, lorsque cela est possible, pour isoler un éventuel conflit avec le thème actif.

Testez aussi les routes et les intégrations qui utilisent une variable de langue. Si une requête ou un service externe ne la prend pas en compte, le contenu retourné peut être différent de celui attendu.

Évitez de désactiver des composants sur le site en production sans mesurer les conséquences. Un environnement de test permet d’examiner les interactions sans perturber les visiteurs.

Configurer le cache et mesurer la vitesse par langue

Un cache mal configuré peut servir la version française d’une page à un visiteur qui consulte la version anglaise. Le risque dépend notamment de la manière dont la langue est déterminée : URL, cookie ou en-tête Accept-Language.

Définissez une règle de variation adaptée à votre architecture. Des URL distinctes par répertoire ou sous-domaine facilitent généralement la séparation des versions. Vérifiez également que le CDN et les autres couches de cache respectent cette séparation.

Excluez du cache les pages dynamiques lorsque leur contenu ne doit pas être partagé : panier, commande, compte et formulaires sensibles. Testez aussi les redirections géographiques et linguistiques ensemble, car leur combinaison peut créer une boucle. Pour approfondir le diagnostic, consultez notre guide pour résoudre les problèmes de cache sur WordPress.

Comparer les performances de chaque version

Une langue secondaire peut être plus lente à cause de polices différentes, d’un menu plus lourd, de médias non optimisés ou de requêtes supplémentaires. Le résultat dépend aussi de l’état du cache : une version peut déjà être en cache tandis qu’une autre ne l’est pas encore.

Effectuez des mesures comparables pour chaque langue, sur plusieurs types de pages : accueil, catégorie, article, produit et contact. Relevez notamment :

• le temps de réponse initial du serveur, ou TTFB ;
• le poids total de la page et le nombre de requêtes ;
• les scripts JavaScript qui retardent l’affichage ;
• les différences entre une réponse issue du cache et une réponse non mise en cache.

Répétez les tests dans des conditions similaires avant de conclure qu’une traduction est plus lente qu’une autre.

Contrôler le SEO et les médias traduits

Les versions linguistiques doivent être reliées clairement pour les moteurs de recherche comme pour les visiteurs. Les balises hreflang indiquent les correspondances entre pages, tandis que les URL canoniques et les sitemaps participent à la cohérence de l’indexation.

Sur un échantillon de pages dans chaque langue, vérifiez que :

• chaque hreflang pointe vers une page traduite accessible, et non vers une page 404 ou l’accueil par défaut ;
• les URL canoniques correspondent à la stratégie retenue, souvent avec une URL canonique propre à chaque version traduite ;
• les sitemaps incluent les URL attendues dans chaque langue ;
• les titres et méta-descriptions sont affichés dans la bonne langue ;
• les catégories ou étiquettes ne produisent pas inutilement des pages identiques dans plusieurs langues.

Dans l’extension SEO, contrôlez si les champs sont traduits ou copiés. Utilisez ensuite Google Search Console pour examiner l’indexation des différentes versions, en tenant compte des propriétés configurées pour vos domaines ou sous-domaines.

Partager ou localiser les médias

Les images peuvent être partagées entre langues ou dupliquées. Le partage simplifie la médiathèque, mais ne convient pas toujours aux visuels contenant du texte, des captures d’écran ou des devises à adapter.

Vous pouvez partager les images universelles et créer des fichiers distincts pour les visuels localisés, avec des noms explicites. Surveillez les tailles d’images générées et l’espace de stockage : les duplications peuvent augmenter le volume des sauvegardes et le temps nécessaire à leur restauration.

Si les médias sont stockés sur un service externe ou distribués par un CDN, vérifiez aussi leurs URL après une migration ou un changement de domaine.

Tester le parcours WooCommerce dans chaque langue

Sur une boutique WooCommerce multilingue, les produits, variations, attributs et pages système doivent rester cohérents entre les langues. Une variation absente, un attribut traduit mais non associé ou une page de commande liée au mauvais identifiant peut interrompre le parcours d’achat.

Testez une commande complète dans chaque langue, de la fiche produit jusqu’au retour du prestataire de paiement. Contrôlez en particulier :

• les pages panier, commande et mon compte ;
• les variations, attributs et stocks des produits ;
• les règles de taxes selon le pays, leur affichage et les arrondis ;
• les devises si la boutique en utilise plusieurs ;
• les URL de retour après paiement ou annulation ;
• la langue des e-mails transactionnels et les variables qu’ils contiennent.

Si les produits sont dupliqués, vérifiez que le stock reste synchronisé entre leurs versions. Documentez les pages système associées à chaque langue et répétez les tests sur un environnement de test après une mise à jour du thème ou des extensions.

Préparer les migrations et la maintenance multilingue

Une migration d’hébergeur, un passage en HTTPS, un changement de domaine ou l’ajout d’un CDN peuvent modifier plusieurs éléments à la fois : URL, règles de réécriture, cache et redirections. Les menus, taxonomies, slugs et balises SEO doivent ensuite être vérifiés dans chaque langue.

Avant une migration ou une mise à jour importante :

1. Préparez un environnement de test aussi proche que possible de la production, notamment pour le serveur, le cache et PHP.
2. Sauvegardez le site et vérifiez que vous disposez d’une procédure de restauration.
3. Établissez une correspondance entre anciennes et nouvelles URL si l’architecture change, par exemple de /en/ vers un sous-domaine.
4. Vérifiez l’encodage et la collation MySQL, en particulier pour les accents et les caractères non latins.
5. Testez les redirections, les médias et les traductions sur le site de test.
6. Prévoyez un retour arrière si une version linguistique ne fonctionne pas correctement.

Après une mise à jour du cœur, du thème ou d’une extension, ne vous limitez pas à la langue principale. Vérifiez l’accueil et une page interne par langue, les menus, le sélecteur, la recherche et les formulaires. Contrôlez également un échantillon de hreflang, de canonicals et de sitemaps, ainsi que le parcours de commande si vous utilisez WooCommerce.

Ces contrôles peuvent être intégrés à votre routine de mises à jour WordPress pour repérer une régression avant qu’elle ne passe inaperçue sur une langue secondaire.

Questions fréquentes

Article rédigé avec l’aide d’une IA à partir des sources citées et de notre pratique de la maintenance WordPress. Notre méthode éditoriale.