Une page WordPress reste parfois bloquée sur une ancienne version après une modification de texte, de CSS ou d’image. Pour vider le cache de WordPress correctement, il faut identifier la couche concernée, car le fichier temporaire peut se trouver dans une extension, chez l’hébergeur, sur un CDN ou simplement dans votre navigateur.
La bonne purge dépend de l’endroit où le cache est stocké
- Un plugin de cache conserve souvent des pages HTML prêtes à servir.
- L’hébergeur et le CDN peuvent garder une copie indépendante du site.
- Le navigateur mémorise surtout les fichiers CSS, JavaScript et les images.
- WP-CLI permet de vider rapidement le cache objet sur un serveur accessible en SSH.
- Après chaque purge, contrôlez le résultat dans une fenêtre privée ou avec un rechargement forcé.
Pourquoi le cache WordPress affiche encore une ancienne version
Le cache sert à accélérer un site en réutilisant des fichiers déjà générés. Au lieu de reconstruire une page à chaque visite, WordPress ou l’infrastructure serveur peut envoyer une copie temporaire. C’est efficace pour les performances, mais cela explique pourquoi une modification récente n’apparaît pas immédiatement.
WordPress ne possède pas toujours un cache de page actif par défaut. Celui-ci vient généralement d’un plugin de mise en cache, d’une fonction intégrée à l’hébergement ou d’un réseau de diffusion de contenu, appelé CDN. Le navigateur ajoute parfois sa propre copie par-dessus.
Dans la pratique, je distingue quatre niveaux. Le cache de page concerne le HTML final, le cache objet conserve des résultats issus de la base de données, le cache navigateur garde des ressources statiques et le cache CDN se situe entre le serveur et le visiteur. Vider un seul niveau ne suffit donc pas toujours.
| Type de cache | Ce qu’il conserve | Quand le purger |
|---|---|---|
| Cache de page | Pages HTML générées | Après une modification de contenu ou de plugin |
| Cache objet | Résultats de requêtes et données temporaires | Après un changement important dans la base de données |
| Cache navigateur | CSS, JavaScript, images | Après une modification visuelle |
| Cache CDN ou serveur | Copies distribuées du site | Après une mise en ligne ou une correction urgente |
La méthode la plus simple avec une extension de cache
Si votre site utilise une extension comme WP Rocket, LiteSpeed Cache, WP Super Cache ou W3 Total Cache, commencez par son interface. Connectez-vous à l’administration, ouvrez la page de réglages du plugin, puis cherchez une commande intitulée Vider le cache, Supprimer les fichiers mis en cache ou Purge cache.
Le bouton exact dépend de l’extension, mais l’action est similaire. Elle supprime les fichiers HTML temporaires afin que les prochaines visites déclenchent une nouvelle génération des pages. Sur certains plugins, un bouton séparé permet aussi de purger le cache CSS et JavaScript.
Je conseille de ne pas modifier plusieurs réglages à la fois. Une purge simple est sans risque dans la grande majorité des cas, tandis qu’une désactivation brutale de la minification ou du chargement différé peut changer l’affichage du site. Commencez par supprimer les fichiers temporaires, puis testez.
Que faire après la purge
- Ouvrez la page concernée dans une fenêtre de navigation privée.
- Rechargez-la avec Ctrl + F5 sous Windows ou Cmd + Maj + R sur macOS.
- Vérifiez la page d’accueil, une page interne et, si nécessaire, la version mobile.
- Reconnectez-vous à l’administration pour confirmer que la modification est bien enregistrée.
Si le changement apparaît en navigation privée mais pas dans votre fenêtre habituelle, le problème vient probablement du cache du navigateur. Il est inutile de purger à nouveau toute l’installation WordPress dans ce cas.
Purger l’hébergeur, le CDN et le navigateur
Les hébergements WordPress gérés proposent souvent leur propre système de cache. La commande se trouve parfois dans le tableau de bord de l’hébergeur, dans une barre d’administration WordPress ou dans une rubrique nommée Performance. Cette purge est indépendante de celle du plugin installé sur le site.
Un CDN comme Cloudflare peut également conserver une copie des fichiers. Si une ancienne page continue d’être servie malgré la purge du plugin, utilisez l’option de purge du CDN. Je recommande de commencer par l’URL modifiée lorsque cette possibilité existe, puis de purger l’ensemble du cache seulement si le problème touche plusieurs pages.
| Symptôme | Cache à vérifier en priorité | Action conseillée |
|---|---|---|
| Un nouvel article n’apparaît pas | Page et serveur | Purger le plugin puis l’hébergeur |
| La couleur ou la mise en page reste ancienne | Navigateur, CSS et CDN | Reconstruire les fichiers CSS puis recharger de force |
| Une image remplacée ne change pas | Navigateur ou CDN | Purger la ressource concernée et tester en navigation privée |
| Le site affiche des données incohérentes | Cache objet ou transients | Vider le cache objet avec l’outil prévu par l’hébergement |
Le cache navigateur se vide depuis les paramètres de Chrome, Firefox, Safari ou Edge. Il n’est généralement pas nécessaire de supprimer tout l’historique. Effacer les fichiers et images mis en cache suffit, mais cela peut entraîner un premier chargement un peu plus lent sur les sites visités fréquemment.
Dans certains cas, une modification de fichier CSS semble ignorée parce que son nom n’a pas changé. Les extensions de performance ajoutent alors une version, appelée cache busting, pour forcer le navigateur à télécharger le nouveau fichier. Si cette option existe, utilisez-la avant de désactiver toute l’optimisation.
Nettoyer le cache avec WP-CLI ou sans plugin
Sur un serveur accessible en SSH, WP-CLI offre une méthode rapide. La commande suivante vide le cache objet WordPress :
wp cache flushElle est utile après une modification de données ou lorsqu’un cache persistant, comme Redis ou Memcached, conserve une valeur obsolète. Elle ne supprime pas forcément les pages HTML créées par une extension ni les copies présentes sur un CDN. WP-CLI ne remplace donc pas toujours une purge complète.
Les transients sont d’autres données temporaires enregistrées par WordPress ou par des extensions. Ils expirent normalement seuls, mais une suppression globale peut aider après une migration ou un dysfonctionnement précis :
wp transient delete --allJe réserve cette commande aux situations où je sais que des données temporaires sont en cause. Elle peut obliger certaines extensions à recalculer des informations lors des prochaines visites. Sur une boutique active, faites une sauvegarde et évitez de lancer des nettoyages massifs pendant une période de forte activité.
Suppression manuelle des fichiers
Certains plugins stockent leurs fichiers dans wp-content/cache/, mais ce chemin n’est pas universel. Avant toute suppression par FTP ou par le gestionnaire de fichiers, désactivez temporairement le plugin concerné ou utilisez sa commande officielle. Supprimez le contenu du dossier de cache, pas le dossier lui-même, sauf si la documentation de l’extension indique précisément le contraire.
Ne touchez jamais aux dossiers wp-content/uploads/, wp-content/plugins/ ou wp-content/themes/ pour résoudre un simple problème de cache. Une suppression au mauvais endroit peut retirer des images, du code ou des réglages nécessaires au fonctionnement du site.
Quand la purge ne suffit pas à corriger le problème
Une page qui reste ancienne n’est pas toujours victime d’un cache. Le changement peut ne pas avoir été enregistré, être affiché uniquement pour les visiteurs connectés ou être écrasé par le thème. Je vérifie d’abord la page dans un autre navigateur, puis j’examine le code source ou la console du navigateur si le problème concerne un script ou une feuille de style.
La modification est visible pour vous mais pas pour les visiteurs
Cette situation arrive avec les caches conditionnels. Les visiteurs connectés peuvent recevoir une version différente de celle des visiteurs anonymes. Testez avec une fenêtre privée et, si le résultat diverge encore, contrôlez le cache de page et celui du CDN.
Le CSS ou le JavaScript provoque un affichage cassé
Après une purge, les fichiers optimisés sont parfois régénérés progressivement. Une combinaison de minification, de fusion de fichiers et de chargement différé peut créer un conflit. Désactivez temporairement une seule option d’optimisation à la fois pour identifier la cause, puis réactivez les réglages qui ne posent pas problème.
Lire aussi : Article WordPress - Rédigez et gérez efficacement
Le site utilise un cache PHP
L’OPcache conserve en mémoire du code PHP déjà compilé. Il s’agit d’un cache différent de celui des pages WordPress. Si une modification de code semble ignorée après un déploiement, l’hébergeur peut proposer un bouton pour redémarrer PHP ou réinitialiser l’OPcache. Cette opération est rarement nécessaire pour un simple changement d’article ou d’image.
Si aucune purge ne change le résultat, contrôlez aussi les règles de mise en cache dans le fichier de configuration du serveur, les en-têtes HTTP et les éventuelles règles du CDN. À ce stade, le problème vient souvent d’une configuration, d’un conflit d’extension ou d’un fichier qui n’est pas celui réellement chargé par le navigateur.
La routine que j’applique avant de publier une modification
Pour une modification de texte, je purge le cache de page et je teste en navigation privée. Pour une modification graphique, j’ajoute le cache CSS, le navigateur et éventuellement le CDN. Pour une intervention sur la base de données ou une migration, je vérifie aussi le cache objet et les transients.
Cette méthode prend généralement moins de cinq minutes et évite de supprimer des fichiers au hasard. Le bon réflexe consiste à purger la couche qui contient réellement l’ancienne version, puis à vérifier le résultat depuis un contexte non connecté.
Un cache correctement configuré doit accélérer le site sans compliquer sa maintenance. Si vous devez le vider manuellement chaque jour, cherchez plutôt la cause du problème dans les règles d’expiration, l’extension utilisée ou la configuration de l’hébergeur.
