WordPress affiche un contenu différent connecté vs non connecté (Solution complète)

Vous apportez une modification à votre site WordPress, rechargez la page en étant connecté, et tout semble parfaitement correct. Puis vous ouvrez une fenêtre de navigation privée ou demandez à quelqu'un d'autre de vérifier, et la page semble complètement différente ou affiche encore l'ancien contenu. C'est l'un des problèmes les plus déstabilisants à rencontrer en tant que propriétaire de site, car tout semble bien de là où vous vous trouvez.

La cause est presque toujours le cache, mais ce mot couvre beaucoup de terrain. Il peut y avoir un plugin de cache actif sur votre installation WordPress, un cache au niveau serveur sur le serveur d'hébergement, un CDN comme Cloudflare qui met en cache vos pages HTML, ou une combinaison des trois. Chaque couche fonctionne indépendamment et peut servir différentes versions de votre contenu selon sa configuration.

Ce guide explique exactement pourquoi les utilisateurs connectés et déconnectés voient des choses différentes, comment identifier quelle couche de cache est responsable, et comment corriger la configuration à chaque niveau pour que tous les visiteurs voient un contenu cohérent et à jour.

Résumé de la correction rapide

• Vider tous les caches incluant votre plugin de cache WordPress, le cache serveur et le cache Cloudflare
• Tester le site en étant déconnecté avec une fenêtre de navigation privée ou incognito
• Désactiver temporairement votre plugin de cache pour confirmer si le cache est la cause
• S'assurer que les pages dynamiques comme le panier, le paiement et le compte sont exclues de toutes les couches de cache
• Vérifier les règles de cache Cloudflare pour confirmer que les pages HTML ne sont pas mises en cache au niveau CDN

Pourquoi les utilisateurs connectés et déconnectés voient un contenu différent

WordPress génère les pages de façon dynamique, ce qui signifie qu'il construit chaque page en interrogeant la base de données et en assemblant le HTML à chaque requête. C'est flexible mais lent à grande échelle, donc les outils de cache interviennent pour stocker des versions préconstruites des pages et les servir aux visiteurs sans déclencher une génération complète de page à chaque chargement.

Le problème est que les utilisateurs connectés et les visiteurs déconnectés sont traités très différemment par WordPress et ses outils de cache. Quand vous êtes connecté en tant qu'administrateur ou éditeur, WordPress définit des cookies d'authentification dans votre navigateur. La plupart des systèmes de cache détectent ces cookies et contournent intentionnellement le cache pour vous, servant la version en direct et fraîchement générée de chaque page. C'est conçu ainsi pour que vous voyiez vos modifications immédiatement sans avoir à vider quoi que ce soit.

Quand un visiteur arrive sans ces cookies, le système de cache sert quelle que soit la version de la page actuellement stockée dans le cache. Si cette version mise en cache est ancienne, a été construite avec un contenu différent, ou a été construite quand un widget ou un menu était configuré différemment, le visiteur voit quelque chose qui ne correspond pas à ce que vous voyez. L'écart entre ce que vous voyez et ce qu'il voit est entièrement une question de ce qui se trouve dans le cache et quand il a été construit pour la dernière fois.

C'est pourquoi le conseil habituel de simplement recharger la page ou vider le cache du navigateur ne résout pas le problème. Le problème n'est pas dans votre navigateur. Il se trouve dans une couche de cache entre votre serveur et vos visiteurs.

Étape 1 : Confirmer que le problème est lié au cache

Avant de modifier des paramètres, confirmez que le cache est bien la cause. Ouvrez une fenêtre de navigation privée ou incognito, ce qui garantit que vous n'avez aucun cookie WordPress, et accédez à la page qui semble incorrecte. Si elle affiche un contenu différent de ce que vous voyez en étant connecté, le cache est presque certainement responsable.

Vous pouvez aussi inspecter les en-têtes de réponse HTTP de la page pour voir quelle couche de cache la sert. Dans Chrome, ouvrez les Outils de développement, allez dans l'onglet Réseau, rechargez la page, cliquez sur la requête du document principal et regardez les en-têtes de réponse. Les en-têtes à rechercher incluent :

• X-Cache: HIT indique qu'une version mise en cache est servie, soit au niveau serveur soit au niveau CDN
• CF-Cache-Status: HIT confirme que Cloudflare a servi une version mise en cache de la page
• X-LiteSpeed-Cache: hit indique que le cache serveur de LiteSpeed est actif
• Age: montre depuis combien de secondes la version mise en cache a été construite ; une valeur élevée signifie que le cache est obsolète

Si aucun de ces en-têtes n'est présent et que le contenu est toujours différent, le problème peut être un conflit de plugin plutôt qu'un problème de cache, et vous pouvez passer directement à la section sur les conflits de plugins ci-dessous.

Étape 2 : Vider toutes les couches de cache

La façon la plus rapide de rétablir un contenu cohérent pour tous les visiteurs est de vider simultanément toutes les couches de cache. Vider uniquement une couche alors que les autres restent actives ne résoudra souvent pas le problème.

Plugin de cache WordPress

Si vous utilisez WP Rocket, accédez au menu WP Rocket dans votre tableau de bord WordPress et cliquez sur Vider le cache. Si vous utilisez LiteSpeed Cache, allez dans LiteSpeed Cache dans le menu et cliquez sur Tout purger. W3 Total Cache, WP Super Cache et d'autres plugins ont des options de purge similaires dans leurs menus respectifs. Videz tout, pas seulement le cache d'une page spécifique.

Cache au niveau serveur

De nombreux serveurs d'hébergement exécutent une couche de cache indépendamment de tout plugin WordPress. Les serveurs LiteSpeed ont leur propre cache d'objet et de page qui fonctionne au niveau serveur. Les serveurs Nginx peuvent exécuter un cache FastCGI. Les environnements d'hébergement cPanel ont parfois une couche de cache intégrée. Dans de nombreux cas, vider le cache depuis votre plugin WordPress vide également le cache serveur, mais pas toujours. Si vous avez accès à WHM ou cPanel, vérifiez s'il existe un panneau de configuration de cache. Vous pouvez aussi contacter votre hébergeur et lui demander de purger le cache serveur pour votre compte.

Cache Cloudflare

Connectez-vous à votre tableau de bord Cloudflare, sélectionnez votre domaine, accédez à Mise en cache, puis Configuration, et cliquez sur Tout purger. Cela vide le cache périphérique de Cloudflare pour toutes les pages de votre domaine et le force à récupérer du contenu frais depuis votre serveur d'origine à la prochaine requête. Après la purge, attendez deux à trois minutes avant de tester, car la purge peut prendre un moment pour se propager à tous les nœuds périphériques de Cloudflare.

Après avoir vidé les trois couches, testez à nouveau le site dans une fenêtre de navigation privée. Si le contenu correspond maintenant à ce que vous voyez en étant connecté, le problème était un cache obsolète. Si le contenu est toujours différent, la configuration du cache doit être ajustée pour éviter que le même problème ne se reproduise.

Étape 3 : Vérifier que votre plugin de cache exclut les pages dynamiques

Vider le cache corrige le problème immédiat mais ne l'empêche pas de se reproduire. Pour cela, vous devez vous assurer que votre plugin de cache est configuré pour exclure du cache les pages qui contiennent du contenu dynamique spécifique à l'utilisateur.

Les pages qui ne doivent jamais être mises en cache incluent le panier, la page de paiement, la page de compte, la page de connexion, et toute page qui affiche du contenu spécifique à la session du visiteur actuel. Sur un site WordPress standard, ce sont typiquement des chemins comme /cart, /checkout, /my-account, /login et /register. Votre plugin de cache devrait avoir une liste d'exclusion dans ses paramètres où vous pouvez ajouter ces chemins.

Dans WP Rocket, allez dans Paramètres, puis Cache, et cherchez la section Ne jamais mettre en cache les URLs. Ajoutez-y chacun des chemins de pages dynamiques. WP Rocket a également une intégration WooCommerce intégrée qui gère automatiquement les exclusions du panier et du paiement quand WooCommerce est actif, mais il vaut la peine de confirmer que c'est activé.

Dans LiteSpeed Cache, allez dans LiteSpeed Cache dans le menu, puis Cache, et cherchez l'onglet Exclusions. Vous pouvez y ajouter des patterns d'URL qui seront contournés par le cache. LiteSpeed a également un onglet de paramètres WooCommerce dédié qui configure automatiquement ces exclusions.

Au-delà des chemins de pages spécifiques, toute page qui utilise des shortcodes ou des blocs pour afficher du contenu qui change en fonction du visiteur doit également être exclue. Cela inclut le contenu d'adhésion, les plugins d'affichage conditionnel, et tout plugin qui affiche un contenu différent selon le rôle de l'utilisateur ou son statut de connexion.

Étape 4 : Vérifier le comportement de mise en cache Cloudflare pour les pages HTML

Cloudflare est conçu pour mettre en cache les ressources statiques comme les images, les feuilles de style et les fichiers JavaScript. Par défaut, il ne met pas en cache les pages HTML, ce qui signifie que vos pages WordPress devraient être récupérées fraîches depuis votre serveur d'origine à chaque requête. Cependant, ce comportement par défaut peut être remplacé par des Page Rules ou des Cache Rules configurés pour améliorer les performances, et ces règles peuvent causer exactement le problème que vous observez.

Connectez-vous à Cloudflare, sélectionnez votre domaine et accédez à Règles, puis Page Rules ou Cache Rules selon ce que votre compte utilise. Cherchez toute règle qui inclut Tout mettre en cache comme action. Une règle Tout mettre en cache appliquée à vos pages WordPress causera la mise en cache et le service des pages HTML par le réseau périphérique de Cloudflare, contournant entièrement votre origine sur les requêtes suivantes. Si les visiteurs reçoivent une version mise en cache de Cloudflare, vider vos caches WordPress et serveur n'aura aucun effet sur ce qu'ils voient.

Si vous trouvez une règle Tout mettre en cache, vous avez deux options. Vous pouvez la supprimer entièrement si elle a été configurée par erreur. Ou, si elle était intentionnelle pour des raisons de performance, vous pouvez ajouter une condition de contournement qui empêche Cloudflare de mettre en cache les pages quand un cookie de connexion WordPress est présent. Cela se fait en ajoutant une condition à la règle qui vérifie la présence du cookie wordpress_logged_in_ et définit le niveau de cache sur Contourner quand ce cookie existe.

Pour la plupart des sites WordPress, la configuration de cache Cloudflare recommandée est de laisser les pages HTML au niveau de cache par défaut, ce qui signifie que Cloudflare ne les met pas en cache, et de ne mettre en cache que les ressources statiques. Cela vous donne les avantages CDN pour les images et les scripts sans risquer un contenu HTML obsolète pour les visiteurs.

Étape 5 : Vérifier les conflits de plugins

Si vous avez vidé tous les caches et vérifié les paramètres d'exclusion mais que les visiteurs voient toujours un contenu différent, un plugin génère peut-être une sortie différente selon que quelqu'un est connecté ou non. C'est moins courant qu'un problème de cache mais cela arrive, particulièrement avec des plugins qui utilisent des shortcodes ou des blocs pour afficher du contenu conditionnel.

Pour tester un conflit de plugin, désactivez tous les plugins sauf WordPress lui-même et vérifiez la page affectée en étant déconnecté. Si le contenu correspond maintenant, réactivez les plugins un par un en vérifiant après chacun jusqu'à ce que la différence réapparaisse. Le dernier plugin activé avant que le problème ne revienne est la source du conflit.

Les suspects courants incluent les plugins d'adhésion et de contrôle d'accès qui restreignent le contenu selon le statut de connexion, les plugins de personnalisation qui affichent un contenu différent à différents segments d'utilisateurs, et certains constructeurs de pages qui rendent les shortcodes différemment dans l'éditeur versus sur le front-end. Une fois que vous avez identifié le plugin responsable, vérifiez ses paramètres pour des options liées à la compatibilité du cache ou au comportement d'affichage déconnecté, ou contactez le développeur du plugin pour des conseils.

Plusieurs couches de cache et pourquoi elles entrent en conflit

La version la plus compliquée de ce problème se produit quand plusieurs couches de cache sont actives simultanément et ne sont pas configurées pour fonctionner ensemble. Une configuration typique pourrait inclure un plugin de cache WordPress, un cache LiteSpeed ou Nginx au niveau serveur, et Cloudflare devant tout. Chaque couche a ses propres règles sur ce qu'il faut mettre en cache, pendant combien de temps, et dans quelles conditions contourner le cache.

Quand ces couches ne sont pas alignées, vous pouvez vous retrouver dans des scénarios où le plugin WordPress vide son propre cache mais le cache serveur sert toujours une ancienne version, ou où Cloudflare sert une page qu'il a mise en cache avant que l'une ou l'autre des couches soit vidée. Le visiteur peut même recevoir un contenu différent selon les chargements de page, selon quel nœud périphérique ou serveur de cache traite sa requête.

La solution n'est pas nécessairement de supprimer des couches de cache, car chacune offre de réels avantages de performance. La solution est de s'assurer que toutes les couches sont configurées avec le même ensemble de règles d'exclusion, que les valeurs TTL sont raisonnables et non définies sur des durées extrêmement longues, et que vider le cache dans une couche déclenche une purge dans les autres dans la mesure du possible. La plupart des plugins de cache majeurs ont des paramètres d'intégration pour Cloudflare qui leur permettent de déclencher automatiquement une purge Cloudflare chaque fois que le cache WordPress est vidé.

Dans WP Rocket, allez dans Paramètres, puis Extensions, et cherchez l'intégration Cloudflare. Entrer vos identifiants API Cloudflare permet à WP Rocket de purger automatiquement le cache Cloudflare chaque fois qu'il vide son propre cache. LiteSpeed Cache a un onglet d'intégration CDN similaire. Ce type de configuration coordonnée élimine la plupart des problèmes de contenu obsolète découlant de l'exécution de plusieurs couches de cache.

Considérations spécifiques à WooCommerce

Si votre site utilise WooCommerce, les conséquences d'un cache mal configuré sont plus sérieuses qu'une différence cosmétique dans l'apparence d'une page. Les pages de panier et de paiement contiennent des données de session uniques à chaque visiteur. Si une version mise en cache de la page panier est servie à un nouveau visiteur, il peut voir un panier appartenant à une session précédente, avec des articles qu'il n'a pas ajoutés. Sur la page de paiement, une version mise en cache pourrait afficher des totaux incorrects, des options de livraison manquantes, ou dans des cas extrêmes des données partielles d'une session d'un autre utilisateur.

WooCommerce lui-même définit des cookies que la plupart des plugins de cache reconnaissent comme signaux pour contourner le cache. Quand un visiteur ajoute quelque chose à son panier, WooCommerce définit les cookies woocommerce_cart_hash et woocommerce_items_in_cart. Un plugin de cache correctement configuré détectera ces cookies et cessera de mettre en cache les pages pour la session de ce visiteur.

Si votre plugin de cache ne dispose pas d'un support WooCommerce natif, vous devez ajouter manuellement tous les cookies WooCommerce à la liste d'exclusion de cookies dans les paramètres de votre plugin de cache. Vous devez également exclure manuellement les pages de panier, de paiement et de mon compte du cache de pages. Ne pas faire l'un ou l'autre ouvre la porte aux problèmes de contamination de session décrits ci-dessus.

Quand contacter le support?

Si vous avez vidé tous les caches, revu vos paramètres d'exclusion de plugin, vérifié vos règles Cloudflare et testé des conflits de plugins, et que les visiteurs voient toujours un contenu différent, le problème peut nécessiter une investigation au niveau serveur. Certains environnements d'hébergement ont un cache configuré à un niveau qui n'est pas accessible depuis WordPress ou cPanel, et l'ajustement de ces paramètres nécessite un accès direct au serveur.

Ouvrez un ticket de support depuis votre espace client et décrivez ce que vous avez déjà essayé, quelles pages sont affectées et quelle est la différence de contenu. Si vous pouvez inclure une capture d'écran de la page telle qu'elle apparaît en étant déconnecté, ainsi que son apparence correcte, cela accélère considérablement le diagnostic. Notre équipe peut inspecter la configuration du cache serveur, examiner les en-têtes HTTP servis aux visiteurs, et identifier quelle couche est responsable de l'incohérence.