Modification WordPress invisible : trouver et vider le bon cache

Vérifier que la modification attendue est bien publique

Vous avez corrigé une page WordPress, mais le site montre encore l’ancienne version. Avant de vider des caches, vérifiez la page, son adresse et l’état de l’enregistrement. Une prévisualisation, un brouillon, une autre langue ou un modèle différent peut expliquer l’écart sans qu’une copie ancienne soit en cause.

Dans l’éditeur, confirmez que la mise à jour prévue a abouti, puis ouvrez l’adresse publique exacte du contenu. Choisissez un détail reconnaissable déjà présent dans votre modification, par exemple un titre corrigé. N’ajoutez pas un texte artificiel en production pour servir de test. Gardez l’heure et le résultat attendu dans vos notes.

Le but est de retrouver cette version pour les visiteurs, avec un cache qui continue à accélérer le site. Le parcours commence dans le navigateur, puis examine les couches réellement présentes côté hébergement et CDN. Si le contenu affiché appartient à un autre utilisateur ou révèle des informations privées, il s’agit d’un problème de personnalisation et de confidentialité, qui demande son traitement propre plutôt qu’un simple rafraîchissement.

Distinguer navigateur, page serveur et CDN

Le navigateur peut conserver des fichiers ou une réponse déjà reçue. Un cache de page sur le serveur conserve du HTML généré par WordPress. Un CDN peut stocker une autre copie proche des visiteurs. Un cache objet conserve, lui, des résultats de données ou de calcul ; le vider n’est pas forcément la bonne action pour une ancienne page HTML.

Les couches n’ont pas nécessairement le même contenu ni la même durée de conservation. Un CDN qui sert les images ne conserve pas automatiquement les pages HTML ; Cloudflare ne les met pas en cache par défaut. Une règle particulière ou un service complémentaire peut toutefois changer ce comportement.

Relevez les outils déjà actifs : extension de cache, outil intégré de l’hébergement, CDN et éventuelle fonction hors ligne du site. N’installez pas un nouveau cache pour vider celui qui existe. Les actions suivantes demandent, selon le parcours, votre navigateur, l’administration WordPress ou le compte du prestataire. En multisite, confirmez toujours le site visé avant une commande qui pourrait concerner tout le réseau.

Approche 1 : comparer sans le cache HTTP du navigateur

Ce parcours convient si l’ancienne version semble limitée à votre navigateur. Il ne demande aucun accès WordPress. Le résultat attendu est une comparaison entre le chargement habituel et une nouvelle récupération réseau. Une meilleure version après ce contrôle oriente le diagnostic vers le poste ou ses conditions, sans prouver à elle seule que tous les caches distants sont corrects.

Le réglage décrit ne purge pas les copies conservées chez l’hébergeur ou le CDN. Pour revenir au fonctionnement normal, décochez Désactiver le cache et fermez les outils. Il n’est pas nécessaire de supprimer vos mots de passe, votre historique ou tous vos cookies pour ce premier essai.

1. Ouvrez la page publique exacte, puis F12 et le panneau Réseau de Chrome.
2. Cochez Disable cache, ou Désactiver le cache, et rechargez pendant que les outils restent ouverts.
3. Sélectionnez le document ou le fichier concerné. Vérifiez sa réponse et l’indication éventuelle d’un chargement depuis la mémoire, le disque ou un service worker.
4. Comparez le détail attendu, décochez Disable cache, puis recommencez en navigation ordinaire. Au besoin, les outils restant ouverts, maintenez le bouton de rechargement ou ouvrez son menu contextuel pour choisir Empty cache and hard reload. Cette action concerne le cache local, pas une purge du site.

Vérifier séparément un service worker

Un service worker est un script du site qui peut intercepter des requêtes et fournir une copie locale, notamment pour une fonction hors ligne. Son stockage n’est pas identique au cache HTTP habituel. Si Réseau indique son intervention, vous pouvez le contourner temporairement pour un diagnostic sans le supprimer.

Dans les outils Chrome, ouvrez Application, puis Service Workers. Vérifiez que le service affiché concerne bien ce site. Cochez Bypass for network, rechargez la page et comparez la version. Décochez ensuite cette option et refaites une ouverture normale. Le résultat attendu est de savoir si cette couche participe à l’ancienne réponse.

Si le contournement règle le défaut, faites vérifier la stratégie de mise à jour du composant qui gère ce service worker. Ne cliquez pas aveuglément sur Unregister ou sur une suppression de tout le stockage : cela peut modifier les données locales et le fonctionnement hors ligne. Le contournement du navigateur est un diagnostic, pas une correction à demander à chaque visiteur. Conservez l’adresse du script et les observations, sans exporter de données de session.

Lire les en-têtes sans confondre cache et ancien contenu

Dans Réseau, sélectionnez la requête concernée puis En-têtes. Cache-Control décrit des consignes de conservation ou de validation. no-cache ne signifie pas qu’aucune copie n’est stockée : cette directive impose une validation avant réutilisation. no-store demande de ne pas stocker la réponse concernée ; ajouter cette directive ne purge pas rétroactivement toutes les copies déjà distribuées. Ne remplacez pas ces valeurs globalement pour résoudre un seul défaut.

Un statut 304 signifie que la réponse à une requête conditionnelle autorise la réutilisation d’une copie ; il ne prouve pas que WordPress a perdu votre mise à jour. Regardez le contenu attendu et la ressource exacte. Le document peut être récent alors qu’un fichier CSS ou une image ne l’est pas.

Chez Cloudflare, CF-Cache-Status donne un indice sur cette couche : HIT indique une réponse trouvée dans son cache, MISS une ressource éligible absente de ce cache au moment de la demande. L’absence de HIT ne prouve pas l’absence d’un cache chez l’hébergeur. Age doit aussi être interprété selon sa provenance ; sa valeur n’est pas la date de votre dernière modification éditoriale. Conservez les en-têtes utiles avec l’URL et l’heure.

Approche 2 : vider les caches gérés de WordPress.com

Ce parcours concerne WordPress.com avec les fonctions d’hébergement accessibles sur un site disposant des extensions activées. La documentation actuelle vise Personal, Premium, Business et Commerce dans ce contexte. Il faut l’accès au tableau de bord d’hébergement du bon site. Sur un autre hébergeur, utilisez son outil documenté ; ne cherchez pas ces mêmes menus dans WordPress auto-hébergé. Sans ces fonctions, WordPress.com gère automatiquement le cache du site : poursuivez les contrôles locaux et contactez son assistance si nécessaire. Un achat ou une extension de cache supplémentaire n’est pas requis par ce diagnostic.

Pour une ancienne page publique, commencez par le cache global, appelé global edge cache. Le cache objet concerne les données intermédiaires et ne doit pas être vidé systématiquement pour une modification visuelle. Le menu propose aussi Clear all caches pour une invalidation des deux couches lorsque le diagnostic le justifie. La reconstruction peut ralentir les visites suivantes ; la purge ne modifie pas le contenu publié.

1. Ouvrez le tableau de bord d’hébergement WordPress.com et sélectionnez le titre du site concerné.
2. Dans la barre latérale, ouvrez Settings, puis Caching dans la section Server.
3. Choisissez l’effacement du global edge cache pour une ancienne page publique. Si les deux couches doivent être invalidées, utilisez Clear all à côté de Clear all caches. Attendez la confirmation ; les boutons concernés sont ensuite indisponibles pendant une minute.
4. Ouvrez ensuite la page publique dans une session non connectée et vérifiez la modification. Ne répétez pas la purge à chaque rechargement ; si la version reste ancienne, examinez les autres couches et la ressource réellement reçue.

Purger la page avec WP Super Cache déjà installé

Ce parcours concerne une installation qui utilise déjà WP Super Cache, extension gratuite d’Automattic. La version vérifiée est 3.1.5, avec WordPress 6.8 et PHP 7.4 minimum, et des essais déclarés jusqu’à WordPress 7.1.4. Revérifiez ces informations si votre version diffère. N’installez pas cette extension pour piloter un cache fourni par un autre outil.

Le bouton Delete Cache n’a pas la même portée selon l’endroit où vous le cliquez. Sur la page publique, avec les droits appropriés, il vise le cache de cette page. Depuis l’administration, il peut nettoyer les caches du site. La purge plus ciblée est donc préférable pour une modification isolée.

1. En restant connecté avec un compte autorisé, ouvrez l’adresse publique de la page modifiée, pas son écran d’édition.
2. Dans la barre d’administration affichée sur cette page, utilisez Delete Cache lorsque ce bouton est présent et confirmez que vous êtes sur le bon contenu.
3. Ouvrez ensuite la même URL dans une session non connectée. Vérifiez le détail attendu, puis rechargez pour contrôler la copie reconstruite.
4. Si le bouton est absent, ne modifiez pas les droits du compte pour le faire apparaître. Un administrateur peut utiliser Réglages, WP Super Cache, onglet Easy, Delete Cache, en sachant que cette action vise plus largement le site. En réseau, ne choisissez pas Delete Cache On All Blogs pour une seule page.

Invalider les copies dans le bon ordre

Si plusieurs couches conservent la page, commencez par celle qui la génère ou la garde près de WordPress, puis invalidez la copie du CDN. Si vous videz seulement le CDN alors que le serveur fournit encore l’ancienne réponse, la visite suivante peut remplir le cache distant avec cette même ancienne version.

Conservez une note de chaque action : outil, site, URL et heure. Vérifiez après la première couche avant d’en conclure qu’il faut tout purger. Pour un changement global de navigation ou de modèle, plusieurs pages peuvent réellement dépendre de la modification ; le périmètre sera alors plus large qu’une URL. Il doit rester justifié par ce changement.

Une purge ne modifie normalement pas les règles de conservation. Il n’existe donc pas de réglage à rétablir après une simple invalidation : les prochaines requêtes reconstruisent les copies. Si vous avez aussi modifié un réglage, gardez sa valeur initiale et annulez cette modification séparément. Ne supprimez pas manuellement des dossiers de cache, et ne videz pas des tables de la base pour forcer cette reconstruction.

Approche 3 : purger une URL dans Cloudflare

Ce parcours vise un domaine déjà géré par Cloudflare, avec une ressource effectivement mise en cache à cette couche. Il demande l’accès autorisé au bon domaine dans le tableau de bord. La purge ne supprime pas le fichier d’origine et ne vide pas les copies déjà conservées dans les navigateurs des visiteurs.

Le résultat attendu est une nouvelle récupération de la ressource depuis l’origine, dont la version doit donc être correcte auparavant. Vérifiez l’URL complète : le document, son fichier CSS et son image sont des ressources distinctes. Ne choisissez pas une purge générale pour remplacer cette identification. Si l’adresse répond par une redirection 301 ou 302, sa purge invalide cette redirection mise en cache, pas automatiquement la page de destination. Identifiez séparément la ressource dont la version est ancienne avant de demander une autre purge.

1. Dans le tableau de bord Cloudflare, sélectionnez le domaine concerné puis ouvrez Caching, Configuration.
2. Dans Purge Cache, choisissez Custom Purge, puis URL dans Purge by.
3. Saisissez l’adresse exacte de la ressource à invalider, avec le bon protocole, domaine, chemin et, le cas échéant, paramètres pertinents. Le chemin est sensible à la casse.
4. Relisez la liste et cliquez sur Purge. Rechargez ensuite dans une session de contrôle et vérifiez le contenu et ses en-têtes.
5. Si la version reste ancienne, ne répétez pas automatiquement : examinez les variantes et les clés de cache. Une purge simple n’a pas de contenu à restaurer ; la ressource reste disponible à l’origine.

Tenir compte des clés et des variantes de cache

Une même page peut avoir plusieurs copies selon la langue, les paramètres, l’appareil ou d’autres critères définis par la configuration. La clé de cache est l’ensemble des informations qui désigne une copie. Si vous mesurez une variante et purgez une autre, le résultat peut sembler inchangé.

Cloudflare précise qu’une purge par URL dans son tableau de bord ne suffit pas pour certaines clés personnalisées comprenant des en-têtes, des cookies ou d’autres propriétés. Les zones Enterprise disposent de cas particuliers pour le type d’appareil et le pays dans les options avancées. Cela ne transforme pas la purge simple en invalidation universelle de toutes les variantes.

Si cette configuration existe, relevez la règle et les critères utilisés, puis faites employer la méthode de purge adaptée par la personne qui gère le cache. Ne simplifiez pas la clé en supprimant arbitrairement la langue ou un cookie : vous pourriez mélanger des contenus qui doivent rester distincts. Ajouter un paramètre aléatoire à l’URL peut changer le trajet de cache, mais certaines règles ignorent ces paramètres ; ce n’est donc pas une preuve universelle d’accès direct à l’origine.

Autre point à faire contrôler si la purge ciblée échoue : une règle Cloudflare limitée aux requêtes GET peut ne pas correspondre à la requête de purge. Le responsable doit vérifier cette condition avec la documentation de la règle. Ne la remplacez pas par une règle globale et ne purgez pas toutes les variantes à répétition pour masquer cet écart.

Distinguer HTML récent, ancien fichier et fichier généré

Si le texte est correct mais que les couleurs, le script ou une image restent anciens, examinez la ressource précise dans Réseau. La page HTML peut contenir la bonne modification tout en demandant un fichier dont l’adresse n’a pas changé. Purger seulement le document ne garantit pas que tous les fichiers liés seront renouvelés.

Pour une image remplacée, vérifiez la variante réellement choisie par le navigateur, pas seulement l’original de la bibliothèque. Pour du CSS généré par un constructeur ou une optimisation, contrôlez le fichier produit et l’outil qui le crée. Une purge ne reconstruit pas nécessairement un fichier généré encore ancien ; utilisez la fonction documentée du composant concerné si ce cas est confirmé.

Une gestion correcte des versions de fichiers aide à éviter la répétition du problème. WordPress permet notamment d’associer une version à une feuille chargée avec wp_enqueue_style(). Cette adaptation appartient au code ou à l’outil qui publie la ressource ; changer au hasard une URL dans le navigateur ne met pas tous les visiteurs à jour. Conservez les anciennes ressources encore référencées pendant la transition et faites contrôler l’ordre de génération, de publication et d’invalidation.

Éviter la désactivation permanente des caches

Un cache correctement configuré réduit le travail répété et rapproche les réponses des visiteurs. Une ancienne copie demande une correction du cycle de mise à jour, pas nécessairement la suppression durable de toutes les couches. Les purges générales répétées peuvent augmenter la charge et ralentir les premières visites qui suivent.

Gardez les caches actifs pendant les contrôles ordinaires, sauf comparaison précise avec un réglage initial conservé. Ne passez pas le domaine hors du CDN et ne changez pas ses DNS pour observer une page : vous modifieriez aussi son trajet, sa protection et parfois sa disponibilité. Les menus de purge existants permettent une action plus limitée.

Si vous adaptez une durée de conservation, choisissez-la selon le type de contenu et le mécanisme d’invalidation disponible. Une page éditoriale, un fichier versionné et une page personnalisée n’ont pas les mêmes besoins. Ne copiez pas un en-tête Cache-Control identique sur tout le site pour obtenir une actualisation immédiate. Conservez la valeur initiale et vérifiez les effets sur les réponses publiques et privées avant tout changement durable.

Vérifier les visiteurs et la copie reconstruite

Après l’invalidation, ouvrez la page dans une session non connectée et contrôlez le détail attendu. Rechargez une seconde fois pour vérifier que la copie reconstruite reste correcte. Comparez ensuite un autre navigateur ou appareil si le défaut concernait plusieurs visiteurs. Gardez le même domaine, la même langue et les mêmes paramètres pertinents.

Dans Réseau, distinguez le document des fichiers liés. Une réponse correctement mise en cache peut désormais contenir la bonne version ; un statut HIT n’est donc pas un échec en soi. Ce qui compte est le contenu reçu et sa cohérence avec la modification prévue.

Vérifiez aussi les fonctions concernées par le changement. Pour une page avec compte, panier ou autre contenu personnalisé, assurez-vous que le contexte reste correct avec les parcours de test prévus. Ne déclenchez pas une opération réelle pour vérifier un simple rafraîchissement. Notez l’heure de la purge et le résultat plutôt que de continuer à effacer les copies une fois le contenu validé.

Si la version ancienne revient, contrôler le cycle de mise à jour

Si une purge fonctionne puis que l’ancienne version réapparaît, examinez la source qui remplit le cache : autre serveur d’origine, fichier généré, synchronisation ou variante oubliée. Une copie peut être renouvelée avec un contenu déjà incorrect avant son arrivée dans le CDN. Conservez les URL, les heures, les réponses et les couches déjà invalidées.

Vérifiez que la modification a été faite sur la bonne installation et que les sauvegardes ou déploiements ne rétablissent pas un ancien fichier. Une ancienne version dans l’éditeur lui-même ne se résout pas en purgeant seulement le cache public. Distinguez aussi les modifications de modèle et le contenu spécifique de la page.

Transmettez ensuite un dossier précis à la personne qui maintient le site : changement attendu, date, ressource concernée, contexte visiteur et résultat de chaque parcours. Gardez les réglages de cache documentés avec leur rôle. Cela permet de corriger l’invalidation ou la génération à sa source, sans demander aux visiteurs de vider leur navigateur à chaque mise à jour.