Website showing old content after update: how to clear cache at every level

A client says "I published the update but the site still shows the old version". The system administrator already knows the answer is not just one thing: there are at least four different caches between the user's browser and the PHP file on the server, and they are independent. Clearing one does not touch the others. Here's where to look, in order, from closest to the user to furthest away.

Level 1: the browser

This is the easiest suspect to rule out and the first to check. The browser keeps HTML, CSS, JS and images from the previous visit in memory. To bypass it, a hard refresh will do: Ctrl+F5 on Windows, Cmd+Shift+R on Mac, or open the page in an incognito window, which starts without cache. If the old content disappears in incognito, the problem is solved here and you don't need to touch anything upstream.

Level 2: the CDN

If the site goes through a CDN (Cloudflare is the most common among hosting providers), the CDN keeps copies of static files — and sometimes HTML pages too — on its nodes, regardless of what happens on the origin. Cloudflare provides four purge modes, documented in its reference page:

• Purge by single file: deletes a specific URL. Pay attention if the site uses custom cache keys: custom cache keys that only modify query string handling generally work with purge from the dashboard, but for other cases you need to use the API including the cache key's headers and cookies.
• Purge by prefix: deletes everything under a path, useful after redesigning an entire section of the site.
• Purge by cache-tag: requires adding a Cache-Tag header to responses from the origin server; then you can use specific tags to instantly delete from the CDN cache all content with that tag, from the dashboard or via API.
• Purge Everything: deletes the entire zone. The Purge Everything operation removes all assets associated with a Cloudflare zone from the cache across all data centres, regardless of the method set.

After a purge, the next request for the deleted content is a cache MISS: Cloudflare retrieves the complete response from the origin and recaches it, and does not serve the deleted content again even if the origin is unreachable.

For those who want to automate purge after a deploy, the command via API is:

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"]}'

The token should be created with Zone → Cache Purge → Purge permission, limited to the zone in question.

Level 3: the WordPress cache plugin

The name changes depending on which plugin is installed. A table so you don't waste time looking for the right button:

Plugin	Location	Command
WP Rocket	Settings → WP Rocket, Dashboard section	"Clear Cache" button
WP Rocket (single content)	Top bar in post/page editor	"Clear this cache"
W3 Total Cache	Performance → Dashboard	"Empty All Caches" button
WP Super Cache	Settings → WP Super Cache	Clear/purge button in cache tab
LiteSpeed Cache	LiteSpeed Cache menu in sidebar	"Purge All"

It should be noted that when you write or update an article or page, WP Rocket automatically clears the cache for that specific content and all other related content, such as home, categories and tags. If after a change the content doesn't update even in incognito, the problem is often not the plugin but a level further up (CDN) or further down (server).

Level 4: server cache and OPcache

This is the level that the plugin button never touches. Two distinct things:

• OPcache: the cache of compiled PHP bytecode. If you replace a .php file directly via FTP without going through the WordPress panel, OPcache can continue to execute the previous compiled version until the configured TTL expires or you force reset with opcache_reset() in a PHP script, or by restarting PHP-FPM (systemctl restart php-fpm or the specific version, e.g. php8.2-fpm).
• Server-side object cache (Redis or Memcached, if configured): cleared with redis-cli FLUSHALL or by restarting the Memcached service. No WordPress plugin touches it unless explicitly configured to do so.

Practical order of verification

When a change is not visible, it's best to proceed in this order: incognito (rules out browser) → purge WordPress plugin → purge CDN → reset OPcache/restart PHP-FPM. Skipping a step is the most common reason why "I cleared the cache but nothing changes".