Pourquoi un visiteur qui navigue en français voit-il, une fois sur deux, un titre de page affiché en anglais après avoir cliqué sur un lien depuis les résultats de recherche ? C’est la question remontée par le support client d’un site e-commerce fraîchement passé sous WP Rocket, quelques semaines après l’activation du cache de page sur un site Polylang existant en trois langues.
Le test utilisateur interne organisé pour reproduire le bug a confirmé le problème sur trois profils sur dix, tous avec un point commun : ils avaient visité une version anglaise ou allemande du site avant de revenir sur une URL française, et se retrouvaient face à une page mise en cache dans la mauvaise langue.
Symptôme précis : le cache sert une version figée, indépendamment de l’URL demandée
En reproduisant le scénario avec les outils de développement du navigateur, la page servie provenait bien du cache de WP Rocket (en-tête X-Cache: HIT présent), mais son contenu ne correspondait pas à l’URL demandée. Sur une même URL /produit-x/, sans préfixe de langue apparent dans l’exemple précis en cause, deux visiteurs différents recevaient deux contenus différents selon leur navigation précédente.
Le site utilisait une structure d’URL avec la langue par défaut sans préfixe (configuration Polylang fréquente : le français n’a pas de /fr/ dans l’URL, seules les langues secondaires en ont un). Sur cette URL sans préfixe, rien dans la clé de cache ne permettait à WP Rocket de distinguer une requête destinée à afficher le français d’une requête qui, via un cookie de langue posé par Polylang, aurait dû rediriger ou adapter l’affichage.
Diagnostic : le cookie de langue Polylang, invisible pour la clé de cache HTTP
Polylang pose un cookie pll_language pour mémoriser la langue précédemment choisie par le visiteur, utilisé notamment pour adapter certains blocs dynamiques ou le comportement de redirection. Un cache de page HTTP classique, WP Rocket compris, ne fragmente pas ses clés de cache selon les cookies par défaut — ce serait d’ailleurs contre-productif pour la performance si c’était systématique, un cache doit rester basé sur des critères simples et stables comme l’URL.
Le vrai problème ici n’était donc pas un bug de WP Rocket, mais une configuration Polylang où une même URL pouvait légitimement afficher un contenu différent selon un cookie, ce qui est structurellement incompatible avec un cache de page basé uniquement sur l’URL. C’est un piège d’architecture, pas un piège d’extension.
Correctif : imposer un préfixe de langue systématique, y compris pour la langue par défaut
La solution retenue a été de changer le réglage Polylang « URL » pour forcer un préfixe de langue sur toutes les langues, y compris celle par défaut :
Réglages Polylang → Langues → URL des langues
Avant : "Ne pas afficher la langue par défaut dans l'URL"
Après : "Afficher la langue par défaut dans l'URL"
Résultat :
/produit-x/ devient /fr/produit-x/
/en/produit-x/ reste /en/produit-x/Une fois chaque langue associée à une URL unique et stable, la clé de cache de WP Rocket redevient fiable : une URL correspond à un seul contenu possible, plus de dépendance cachée à un cookie pour déterminer quoi afficher. Le prix à payer est une redirection 301 ponctuelle des anciennes URL françaises sans préfixe vers leurs équivalents préfixés, à mettre en place avant le déploiement pour ne pas casser le référencement existant.
Vérifier le réglage « Variation de cache mobile » de WP Rocket, un faux ami
WP Rocket propose un réglage de variation de cache selon le type d’appareil (mobile/desktop), mais aucune option native de variation selon la langue au-delà de ce que l’URL elle-même détermine. C’est précisément pourquoi une architecture d’URL propre par langue, sans dépendre d’un cookie pour distinguer deux contenus sur une même URL, est la seule fondation solide pour faire cohabiter cache de page et multilingue.
En résumé
Un cache de page HTTP classique ne peut pas deviner qu’une même URL doit afficher un contenu différent selon un cookie de langue : il faut lui donner une URL différente par langue, sans exception pour la langue par défaut. Ce réglage, souvent négligé au moment de l’installation initiale de Polylang, devient bloquant dès qu’un cache de page est activé, et la correction impose une redirection soignée pour ne pas perdre le référencement acquis sur les anciennes URL.
