Il sito mostra contenuti vecchi dopo un aggiornamento: come svuotare la cache a ogni livello

Un cliente dice "ho pubblicato la modifica ma il sito mostra ancora la versione vecchia". Il sistemista sa già che la risposta non è una sola: ci sono almeno quattro cache diverse tra il browser dell'utente e il file PHP sul server, e sono indipendenti. Svuotarne una non tocca le altre. Ecco dove guardare, in ordine, dal più vicino all'utente al più lontano.

Livello 1: il browser

È il sospettato più facile da escludere e il primo da controllare. Il browser tiene in memoria HTML, CSS, JS e immagini della visita precedente. Per saltarlo basta un hard refresh: Ctrl+F5 su Windows, Cmd+Shift+R su Mac, oppure aprire la pagina in una finestra in incognito, che parte senza cache. Se il contenuto vecchio sparisce in incognito, il problema è finito qui e non serve toccare nient'altro a monte.

Livello 2: la CDN

Se il sito passa da una CDN (Cloudflare è la più diffusa tra chi gestisce hosting), la CDN tiene copie dei file statici — e a volte anche delle pagine HTML — sui suoi nodi, indipendentemente da cosa succede sull'origine. Cloudflare mette a disposizione quattro modalità di purge, documentate nella sua pagina di riferimento:

• Purge per singolo file: cancella un URL preciso. Attenzione se il sito usa chiavi di cache personalizzate: le chiavi di cache personalizzate che modificano solo la gestione della query string generalmente funzionano con il purge da dashboard, ma per gli altri casi va usata l'API includendo header e cookie della chiave di cache.
• Purge per prefisso: cancella tutto ciò che sta sotto un percorso, utile dopo un redesign di una sezione intera del sito.
• Purge per cache-tag: richiede di aggiungere un header Cache-Tag alle risposte del server d'origine; poi si possono usare tag specifici per cancellare istantaneamente dalla cache della CDN tutti i contenuti con quel tag, dalla dashboard o via API.
• Purge Everything: cancella tutto lo zone. L'operazione Purge Everything rimuove tutti gli asset associati a una zona Cloudflare dalla cache in tutti i data center, indipendentemente dal metodo impostato.

Dopo un purge, la richiesta successiva per il contenuto cancellato è un cache MISS: Cloudflare recupera la risposta completa dall'origine e la ricachea, e non torna a servire il contenuto cancellato nemmeno se l'origine è irraggiungibile.

Per chi vuole automatizzare il purge dopo un deploy, il comando via API è:

curl --request POST \
 --url https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache \
 --header "Authorization: Bearer TOKEN" \
 --header 'Content-Type: application/json' \
 --data '{"files": ["https://example.com/pagina.html"]}'

Il token va creato con permesso Zone → Cache Purge → Purge, limitato alla zona interessata.

Livello 3: il plugin di cache di WordPress

Qui cambia nome a seconda del plugin installato. Una tabella per non perdere tempo a cercare il pulsante giusto:

Plugin	Dove si trova	Comando
WP Rocket	Impostazioni → WP Rocket, sezione Dashboard	Pulsante "Pulizia Cache" / "Clear Cache"
WP Rocket (contenuto singolo)	Barra in alto nell'editor di post/pagina	"Pulisci questa cache"
W3 Total Cache	Performance → Dashboard	Pulsante "Empty All Caches"
WP Super Cache	Impostazioni → WP Super Cache	Pulsante clear/purge nella scheda cache
LiteSpeed Cache	Menu LiteSpeed Cache nella sidebar	"Purge All"

Va tenuto presente che quando si scrive o aggiorna un articolo o una pagina, WP Rocket cancella automaticamente la cache di quel contenuto specifico e di tutti gli altri contenuti collegati, come home, categorie e tag. Se dopo una modifica il contenuto non si aggiorna nemmeno in incognito, il problema spesso non è il plugin ma un livello più a monte (CDN) o più a valle (server).

Livello 4: la cache del server e OPcache

Questo è il livello che il pulsante del plugin non tocca mai. Due cose distinte:

• OPcache: la cache dei bytecode compilati di PHP. Se si sostituisce un file .php direttamente via FTP senza passare dal pannello WordPress, OPcache può continuare a eseguire la versione compilata precedente finché non scade il TTL configurato o non si forza il reset con opcache_reset() in uno script PHP, oppure riavviando PHP-FPM (systemctl restart php-fpm o la versione specifica, es. php8.2-fpm).
• Cache oggetti lato server (Redis o Memcached, se configurati): si svuota con redis-cli FLUSHALL o riavviando il servizio Memcached. Nessun plugin WordPress la tocca se non è configurato per farlo esplicitamente.

Ordine pratico di verifica

Quando una modifica non si vede, conviene procedere in quest'ordine: incognito (esclude il browser) → purge plugin WordPress → purge CDN → reset OPcache/riavvio PHP-FPM. Saltare un passaggio è il motivo più comune per cui "ho svuotato la cache ma non cambia niente".