WordPress comment vider le cache ? Ouvrez le menu de votre solution de cache et utilisez l’action « Purger tout » ou « Clear all cache », puis videz le cache du navigateur avec Ctrl+F5. Si le changement reste invisible, purgez aussi le cache serveur, le CDN et le cache d’objets. Vérifiez ensuite la page en navigation privée et avec une URL de test. Cette méthode règle la grande majorité des pages WordPress qui affichent encore une ancienne version.

Pourquoi WordPress affiche encore une ancienne version

Le cache WordPress est une copie temporaire d’une page, d’un fichier ou d’une requête. Au lieu de reconstruire le HTML avec PHP et MySQL à chaque visite, le serveur renvoie une copie déjà préparée. Le visiteur gagne du temps, mais cette copie peut rester disponible après une modification de titre, de CSS, d’image ou de contenu.

Il n’existe pas un seul cache WordPress. Une page peut être conservée par le navigateur, par un plugin, par le serveur web, par un CDN comme Cloudflare et par un système de cache d’objets comme Redis. Purger une seule couche ne suffit donc pas toujours. La bonne méthode consiste à identifier la couche qui sert encore l’ancienne réponse, puis à l’invalider sans supprimer inutilement les données du site.

Le symptôme est simple : l’administration montre la nouvelle version, tandis qu’une fenêtre privée ou un autre appareil affiche l’ancienne. Un autre indice est un fichier CSS qui ne change qu’après un rechargement forcé. Dans ce cas, ne modifiez pas le contenu une deuxième fois. Commencez par le parcours de purge ci-dessous.

1. Enregistrer la modification dans WordPress
2. Purger le cache de page du plugin
3. Purger le cache serveur de l’hébergeur
4. Purger le CDN si le site en utilise un
5. Recharger le navigateur avec Ctrl+F5
6. Tester en navigation privée et sur mobile

Vider le cache WordPress avec un plugin

Avec un plugin de cache, la commande se trouve généralement dans la barre d’administration ou dans le tableau de bord du plugin. Les libellés changent selon l’outil, mais les actions sont proches : « Vider le cache », « Purger le cache », « Clear cache » ou « Purge all ». Commencez par la purge de la page concernée, puis utilisez la purge globale seulement si la première action ne suffit pas.

LiteSpeed Cache propose une purge depuis la barre d’administration, avec des actions distinctes pour la page courante et l’ensemble du cache. WP Rocket permet de supprimer les fichiers mis en cache depuis sa barre d’outils. W3 Total Cache utilise l’action « Purge All Caches ». Autoptimize, lorsqu’il ne sert pas de cache de page complet, demande plutôt de vider son cache de fichiers optimisés.

Après une modification CSS ou JavaScript, purgez également les fichiers minifiés et combinés. Un plugin peut servir un HTML neuf qui référence encore un ancien fichier CSS. Après cette purge, rechargez la page avec une chaîne de version ou un rechargement forcé, sans désactiver toutes les extensions au hasard.

# Vérifier les en-têtes de cache d’une page
curl -sI https://exemple.fr/ma-page/ | grep -iE 'cache|age|etag|x-litespeed|cf-'

# Tester une copie distincte sans modifier le contenu
curl -sI 'https://exemple.fr/ma-page/?cache-test=1'

Un seul plugin doit piloter le cache de page. Activer simultanément plusieurs moteurs de cache crée des règles de purge concurrentes, des fichiers minifiés contradictoires et parfois des boucles de redirection. Si vous venez de changer d’outil, désactivez l’ancien après avoir supprimé ses fichiers de cache, puis configurez le nouveau.

Vider le cache serveur et LiteSpeed

Le cache serveur se situe en dehors de WordPress. Il peut continuer à servir un ancien HTML même si le plugin indique que la purge est terminée. Sur un hébergement LiteSpeed, cherchez le bouton de purge dans LiteSpeed Cache, puis vérifiez que le plugin est bien connecté au service de cache du serveur. Une installation WordPress sur Apache ou Nginx peut aussi être placée derrière une couche de cache gérée par l’hébergeur.

Si vous n’avez pas accès au bouton, ouvrez le centre de support de l’hébergeur et demandez une purge du cache de page du domaine. Donnez l’URL exacte, l’heure de la modification et le type de ressource concerné. Une purge serveur ne demande pas de supprimer WordPress, de réinstaller le plugin ou de toucher à la base de données.

Le fichier wp-config.php peut confirmer qu’un cache applicatif est activé, mais la constante WP_CACHE ne purge rien à elle seule. Elle indique seulement qu’un mécanisme de cache peut être chargé. Ne changez pas cette valeur pour résoudre une ancienne page, car vous risquez de modifier le comportement du plugin sans supprimer les fichiers déjà générés.

// wp-config.php : indication, pas commande de purge
define('WP_CACHE', true);

// Pour diagnostiquer, ne pas ajouter de purge destructive ici.
// La purge doit être exécutée depuis le plugin ou l’hébergeur.

Les pages protégées, les utilisateurs connectés et les requêtes avec cookies peuvent recevoir une version différente. Faites le test déconnecté, puis déconnectez le CDN temporairement uniquement si son tableau de bord permet un mode diagnostic réversible. Ne supprimez jamais les dossiers du cache avec le gestionnaire de fichiers sans connaître le mécanisme qui les régénère.

Vider le cache du navigateur après une modification

Le cache du navigateur conserve les images, les feuilles de style et les scripts afin d’accélérer les visites suivantes. Pour vérifier un changement, utilisez Ctrl+F5 sous Windows et Linux, ou Cmd+Shift+R sur macOS. Une fenêtre privée est encore plus pratique, car elle démarre généralement avec un stockage séparé.

Si le problème ne touche que votre ordinateur, le cache navigateur est probablement responsable. Dans Chrome, ouvrez les outils de développement, maintenez le bouton de rechargement et choisissez « Vider le cache et effectuer un rechargement forcé ». Dans Firefox, utilisez Ctrl+F5, puis contrôlez l’onglet Réseau pour voir la réponse réellement téléchargée.

Ne demandez pas à tous les visiteurs de vider leur cache lorsque vous contrôlez un site public. Pour les ressources statiques, utilisez une version dans l’URL ou le nom du fichier. WordPress ajoute souvent un paramètre de version aux feuilles de style, mais un CDN mal configuré peut encore ignorer cette variation. La version doit changer au moment du déploiement.

// functions.php : version liée à la date du fichier CSS
wp_enqueue_style(
    'site-style',
    get_stylesheet_uri(),
    [],
    filemtime(get_stylesheet_directory() . '/style.css')
);

Cette technique ne purge pas un HTML déjà mis en cache. Elle force seulement le navigateur à demander une nouvelle ressource lorsque le fichier CSS change. Il faut donc l’associer à une purge du cache de page et du CDN si la page elle-même contient une ancienne référence.

Purger Cloudflare ou un autre CDN

Un CDN est une copie géographique des ressources et parfois du HTML. Si votre site passe par Cloudflare, ouvrez le tableau de bord du domaine, allez dans la zone de cache et choisissez la purge de l’URL concernée. La purge globale existe, mais elle force tous les fichiers à être redemandés et peut augmenter temporairement les requêtes vers l’origine.

Préférez une purge ciblée pour un article, une page ou une feuille de style. Utilisez la purge globale seulement après un changement de thème complet, une migration ou une erreur généralisée. Vérifiez aussi les règles « Cache Everything », les workers et les règles de contournement, car une règle personnalisée peut recréer une copie juste après la purge.

Les en-têtes HTTP indiquent souvent la couche responsable. cf-cache-status: HIT signale une réponse servie par Cloudflare. Un âge élevé dans l’en-tête Age indique une copie conservée par un proxy. À l’inverse, un statut MISS ou BYPASS signifie que la requête a probablement atteint le serveur d’origine.

URL='https://exemple.fr/ma-page/'
curl -sI "$URL" | tr -d 'r' | grep -iE 'cache|age|etag|server|last-modified'

# Comparer deux réponses sans ajouter de paramètres permanents
curl -sS -D - -o /dev/null "$URL" | grep -iE 'cache|age|etag|last-modified'

Un CDN ne remplace pas le cache WordPress. Il accélère la distribution d’une réponse, tandis que WordPress ou le serveur la génère. Purgez donc l’origine avant le CDN lorsque le contenu a été modifié, puis contrôlez la réponse depuis une connexion extérieure.

Réinitialiser le cache d’objets et OPcache

Le cache d’objets, souvent Redis ou Memcached, conserve les résultats de requêtes et les options WordPress. Il est utile pour accélérer les sites dynamiques, mais il ne remplace pas le cache de page. Si une option, un menu ou une donnée issue de la base semble ancienne alors que le HTML est neuf, le cache d’objets peut être en cause.

Utilisez le bouton « Flush cache » fourni par votre intégration Redis ou par l’hébergeur. Une purge du cache d’objets est plus large qu’une simple purge de page, mais elle ne supprime pas les articles ni les utilisateurs. Vérifiez ensuite que Redis se reconnecte et que le taux de succès du cache remonte normalement.

OPcache conserve le bytecode PHP compilé. Il concerne surtout une modification de PHP, d’un thème ou d’un plugin, pas une simple correction de texte. Si le serveur exécute réellement un ancien fichier PHP après un déploiement, demandez un reset OPcache à l’hébergeur ou redémarrez le processus PHP selon la procédure documentée. Ne supprimez pas les fichiers du dossier temporaire au hasard.

# WP-CLI : vider les transients WordPress, après sauvegarde
wp transient delete --all

# WP-CLI : vérifier l’état du cache objet
wp cache type
wp cache flush

La commande wp cache flush dépend de l’installation et peut vider un cache partagé. Lancez-la seulement avec le bon utilisateur et sur le bon environnement. Pour une boutique, testez ensuite le panier, la connexion et le passage de commande, car le contenu personnalisé ne doit jamais être mis en cache comme une page publique.

Diagnostiquer une page toujours ancienne

Lorsque la purge ne fonctionne pas, comparez les réponses depuis plusieurs contextes. Testez la page en navigation privée, depuis un téléphone mobile et avec curl. Notez le titre, la date de modification, l’URL canonique et les en-têtes de cache. Cette comparaison permet de distinguer un problème de cache d’un problème de déploiement, de routage ou de contenu enregistré dans le mauvais champ.

Contrôlez d’abord que la modification est bien publiée, et non enregistrée en brouillon ou dans une révision. Vérifiez ensuite l’URL exacte : une variante avec ou sans barre finale, un sous-domaine, HTTP au lieu de HTTPS ou une redirection peut afficher une autre copie. Regardez enfin les règles d’exclusion du cache, les cookies de connexion et les paramètres de préchargement.

Pour une feuille de style, inspectez l’onglet Réseau du navigateur et confirmez le fichier réellement chargé. Pour une image, vérifiez son nom et son URL complète. Pour un bloc WordPress, contrôlez le HTML source, pas seulement l’aperçu de l’éditeur. Si le HTML source est nouveau mais l’écran est ancien, le souci vient souvent du navigateur ou d’un script.

# Comparer le titre servi par le serveur
curl -sL 'https://exemple.fr/ma-page/' 
  | grep -oP '(?<=<title>).*?(?=</title>)' 
  | head -1

# Suivre une redirection et afficher son code final
curl -sIL 'https://exemple.fr/ma-page/' | grep -E 'HTTP/|location:'

Pour une procédure plus ciblée, notre guide sur vider le cache WordPress sans plugin détaille les méthodes natives, les fichiers temporaires et les purges manuelles prudentes. Si vous hésitez entre plusieurs extensions, consultez aussi notre comparatif du cache WordPress, qui distingue le cache de page, le cache d’objets et le CDN.

La méthode recommandée selon votre situation

Pour une simple correction de texte, purgez la page dans le plugin, puis rechargez en navigation privée. Pour une modification de CSS ou de JavaScript, purgez les fichiers optimisés, augmentez la version de la ressource et contrôlez l’onglet Réseau. Pour une migration ou un changement de thème, purgez le plugin, le serveur, le CDN et éventuellement OPcache, dans cet ordre.

Pour un site WooCommerce, excluez le panier, la commande et le compte du cache de page. Pour un site derrière Cloudflare, commencez par vérifier le statut de cache avant de lancer une purge globale. Pour un environnement de développement, désactivez le cache uniquement pendant le diagnostic et réactivez-le avant la mise en production.

La purge n’est pas une stratégie de performance. Elle corrige une incohérence ponctuelle. Un site sain invalide automatiquement les pages dépendantes lors d’une publication, conserve un cache long pour les contenus stables et exclut les zones personnalisées. Testez cette invalidation après chaque changement de plugin ou d’hébergeur.

Texte ou article modifié : purge de la page et de la catégorie
CSS ou JavaScript modifié : purge des fichiers optimisés et nouvelle version
Thème ou plugin PHP modifié : purge serveur et contrôle OPcache
CDN modifié : purge ciblée de l’URL, puis test depuis un autre réseau
Boutique : exclure panier, commande et compte

FAQ : cache WordPress

Comment vider rapidement le cache WordPress ?

Depuis la barre d’administration ou le tableau de bord de votre plugin, cliquez sur « Purger le cache » ou « Vider le cache », puis rechargez la page avec Ctrl+F5. Si l’ancienne version reste visible, purgez aussi le cache serveur et le CDN.

Pourquoi mon site WordPress ne se met pas à jour après une modification ?

Le navigateur, le plugin de cache, le serveur ou le CDN peut encore servir une copie ancienne. Testez en navigation privée, contrôlez les en-têtes HTTP et purgez chaque couche qui renvoie un statut HIT ou un âge élevé.

Est-il dangereux de vider le cache WordPress ?

Vider un cache ne supprime normalement ni les articles ni les réglages, mais cela peut augmenter temporairement la charge du serveur pendant la reconstruction. Évitez la purge globale en période de trafic élevé et testez les fonctions dynamiques après l’opération.

Faut-il vider le cache après chaque article publié ?

Un plugin correctement configuré purge automatiquement l’article, les archives dépendantes et la page d’accueil. Si ce mécanisme ne fonctionne pas, utilisez une purge ciblée et vérifiez les règles du CDN avant d’effacer tout le cache.

Quelle différence entre cache WordPress et cache navigateur ?

Le cache WordPress ou serveur conserve une réponse générée pour plusieurs visiteurs, tandis que le cache navigateur conserve des ressources sur un appareil. Purger le navigateur ne supprime donc pas la copie conservée par le serveur ou le CDN.

Sources et références

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.