Vous avez fait une modification sur votre site WordPress mais celle-ci ne s’affiche pas ? Dans bien des cas, c’est simplement une histoire de cache. Voici un guide pratique pour vider les différents caches qui peuvent intervenir, du plus courant au plus avancé.
1. Vider le cache de page (et plus) dans WordPress
La plupart des sites WordPress utilisent une extension de cache de page (WP Rocket, LiteSpeed Cache, WP-Optimize, W3 Total Cache, etc.) Ces extensions génèrent des versions statiques de vos pages pour accélérer l’affichage. Pour vider ce cache :
connectez-vous à votre tableau de bord WordPress,
utilisez le bouton Vider le cache présent dans la barre d’administration ou dans le menu de l’extension.
Avec LiteSpeed Cache, vous disposez même de plusieurs options de purge :
Tout purger (tous les caches d’un coup),
Tout purger – LSCache (cache des pages),
Tout purger – Cache CSS/JS,
Tout purger – Mise en cache d’objet (Redis/Memcached),
Tout purger – Cache Opcode (PHP OPcache).
Cela permet de cibler exactement le type de cache qui pose problème.
L’ensemble des options de purge LiteSpeed Cache
2. Vider le cache objet dans WordPress
Si votre site utilise un cache objet (Redis ou Memcached), certaines données sont conservées pour réduire les requêtes vers la base de données.
Avec LiteSpeed Cache, utilisez l’option Tout purger – Mise en cache d’objet (voir capture d’écran ci-dessus).
Avec une extension dédiée comme Redis Object Cache ou Memcached, vous trouverez un menu Cache Objet dans la barre d’administration haute.
En ligne de commande avec WP-CLI : wp cache flush
3. Vider le cache des transients
WordPress utilise aussi des transients, un système interne de cache pour stocker temporairement certaines données (résultats d’API, options d’extensions, etc.) Pour les vider :
La commande WP-CLI pour supprimer les transients expirés : wp transient delete --expired
Vous pouvez aussi gérer les transients dans votre cPanel, dans WPTiger → Performances
L’emplacement dans WPTiger, dans votre cPanel, pour vider les transients.
L’interface de l’extension Delete Expired Transients.
Dans un premier temps, essayez de supprimer les transients expirés et si un problème ou une incohérence persiste, videz tous les transients (en wp cli : wp transient delete --all)
4. Vider le cache CDN (exemple avec Cloudflare)
Si vous utilisez un CDN comme Cloudflare, celui-ci conserve également des copies de vos pages. Pour vider ce cache :
Connectez-vous à votre compte Cloudflare,
Sélectionnez votre domaine,
Allez dans Caching → Configuration → Vider tous les éléments (Purge Everything) pour tout vider,
Ou utilisez Personnaliser le vidage (Custom Purge) pour cibler une seule URL.
5. Vider le cache du navigateur
Même après avoir purgé WordPress et Cloudflare, votre navigateur peut continuer à afficher une ancienne version de la page. Solution : un rechargement forcé.
Windows/Linux : Ctrl + F5
Mac : Cmd + Shift + R
6. Vider le cache FAI
Dans de rares cas, c’est votre fournisseur d’accès Internet qui conserve une page en cache. Cela peut retarder l’affichage de vos modifications, surtout pour les images et fichiers statiques. Ce peut-être aussi dans le cadre d’une migration.
Mémo rapide : quel cache vider selon la situation ?
Quand une modification n’apparaît pas sur votre site, ce n’est pas forcément un bug : dans de nombreux cas, le cache peut en être la cause. Ce tableau vous aide à identifier, en un coup d’œil, l’action la plus appropriée.
Situation rencontrée
Type de cache concerné
Action à faire
Une page WordPress ne reflète pas vos dernières modifications
Cache de page (plugin CMS)
Purger le cache via votre extension (WP Rocket, LiteSpeed Cache → Tout purger – LSCache)
Les requêtes ou données affichées semblent obsolètes (produits WooCommerce, statistiques…)
Cache objet
Purger le cache objet (Tout purger – Mise en cache d’objet dans LSCache, ou via l’extension Redis/Memcached, ou wp cache flush)
Les résultats d’API ou options WordPress ne se mettent pas à jour
Transients
Supprimer les transients expirés (wp transient delete --expired) ou tout supprimer si nécessaire (wp transient delete --all)
Les fichiers CSS/JS modifiés ne s’appliquent pas
Cache CSS/JS
Purger avec LiteSpeed Cache (Tout purger – Cache CSS/JS) ou via votre plugin d’optimisation
Le site utilise Cloudflare et les fichiers statiques ne sont pas à jour
Cache CDN
Purger le cache via Cloudflare (Purge Everything ou URL ciblée)
Une image ou une feuille de style ne s’affiche pas correctement après vos modifications
Cache navigateur
Rechargement forcé (Ctrl+F5 ou Cmd+Shift+R)
Après une migration ou un changement de DNS, le site pointe encore vers l’ancien serveur
Cache FAI
Vider le cache DNS local + redémarrer le modem (ou changer de DNS) → voir notre guide
02switch propose dans WpTiger l’option « actions avancées » qui permet de vider le cache (transients et cache objet). Quand on utilise XtremCache il y a également la possibilité de vider le cache via les outils exclusifs d’O2switch. L’extension Redis permet de vider le cache également depuis l’administration WordPress.ou via les outils. J’ai l’impression que sans action de ma part, les changements sont rapidement pris en compte mais je m’interroge au delà de savoir si passer par « actions avancées » agit aussi au niveau de XtremCache et/ou s’il y a un ordre dans lequel agir quand on a fait de gros changements structurels. J’aurais tendance à dire : vider le cache au niveau de WPTiger, puis vider XtremCache, puis Redis (je parle de gros changements) mais peut-être me trompe-je ? Merci
La logique est plutôt de partir du plus large vers le plus fin :
1. Purger XtremCache (niveau serveur, toutes les pages),
2. Vider les caches via WP Tiger – Actions avancées (transients + cache objet),
3. Purger Redis si activé (couche objet côté WordPress),
Et enfin, si besoin, un rechargement forcé du navigateur.
En pratique, comme vous l’avez remarqué, WordPress et ses extensions gèrent assez bien la cohérence des caches et la plupart des changements sont pris en compte rapidement sans action manuelle.
L’ordre de purge n’est donc pas une obligation stricte, mais peut être utile en cas de doute ou pour éviter de chercher trop longtemps pourquoi une modification n’apparaît pas.
02switch propose dans WpTiger l’option « actions avancées » qui permet de vider le cache (transients et cache objet). Quand on utilise XtremCache il y a également la possibilité de vider le cache via les outils exclusifs d’O2switch. L’extension Redis permet de vider le cache également depuis l’administration WordPress.ou via les outils. J’ai l’impression que sans action de ma part, les changements sont rapidement pris en compte mais je m’interroge au delà de savoir si passer par « actions avancées » agit aussi au niveau de XtremCache et/ou s’il y a un ordre dans lequel agir quand on a fait de gros changements structurels. J’aurais tendance à dire : vider le cache au niveau de WPTiger, puis vider XtremCache, puis Redis (je parle de gros changements) mais peut-être me trompe-je ? Merci
La logique est plutôt de partir du plus large vers le plus fin :
1. Purger XtremCache (niveau serveur, toutes les pages),
2. Vider les caches via WP Tiger – Actions avancées (transients + cache objet),
3. Purger Redis si activé (couche objet côté WordPress),
Et enfin, si besoin, un rechargement forcé du navigateur.
En pratique, comme vous l’avez remarqué, WordPress et ses extensions gèrent assez bien la cohérence des caches et la plupart des changements sont pris en compte rapidement sans action manuelle.
L’ordre de purge n’est donc pas une obligation stricte, mais peut être utile en cas de doute ou pour éviter de chercher trop longtemps pourquoi une modification n’apparaît pas.
merci ! c’est très clair !