Browser showing old or stale website content

The cache layers that hide a new version

A stale page rarely has one cause. The browser cache, the CDN edge cache, the origin page cache, the DNS cache, and a caching plugin each keep their own copy, and the newest code at the source can be invisible because an earlier cache answers first.

The cache headers are the map. A page served from the browser cache has a status 200 (from disk cache); from a CDN, a CF-Cache-Status: HIT header, or an Age header; from a server, a X-Powered-By with the CMS. Line up the headers in the Network tab before changing anything.

Clear the browser first

The fastest test is a hard reload: Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (macOS) forces the browser to bypass its own cache for that tab. If the new version appears, the browser cache was the layer holding the old copy.

If the old version persists after a hard reload:

1. Open the Network tab and reload. Look at the status column for the document request.
2. If it shows from memory, purge: DevTools, right-click the reload arrow, choose 'Empty Cache and Hard Reload'.
3. If it shows from disk, clear the site data for just that domain so logins are not lost.
4. Check the service worker: DevTools > Application > Service Workers, tick 'Bypass for network' and reload. A service worker that never updates serves old shells silently.

The next stop is the CDN

When the browser is clean but the page is still old, the CDN or the origin proxy holds a copy. The proof is a cache-busting request:

curl -sI "https://example.com/page?v=12345"

The response has CF-Cache-Status: MISS (or Age: 0) and returns the raw origin. If that shows the new version, the cache is the only wrong layer. Purge the URL, the entire CDN zone, or this preference of the origin from the control panel, and re-fetch without the query string.

If the ?v= copy is still old, the fix belongs to the source: the new content never reached the origin.

Server side caches

A CMS keeps its own cache. WordPress page with a caching plugin serves a stale HTML copy until it expires, and the renewal often depends on the file's timestamp, not the DB. The steps:

1. Purge the object cache (Redis, Memcached), the page cache, and the CDN in that order.
2. In WordPress press "Clear all caches" on the plugin or use the host cache button.
3. Note the file mtime of the cached HTML and the page template; the rule "the cache regenerates when the content changes" only works if the cache updates its key when content changes.

Why a fresh visitor still sees old content

If the browser is bypassed, the CDN is purged, and the new page shows in curl, but the visitor still sees the old version, the nastiest cause is a visitor cache that lives in the server, such as a proxy on a shared host, or the old page was in the DNS cache and the page top resolves to the new IP while the reverse proxy serves the old asset. In that case follow the website-not-loading article up to the point the new IP answers, then check whether the host itself serves the old copy for that visitor's network.

Prevention

• Set Cache-Control respected by human traffic: short max-age for HTML, long for versioned assets, and Cache-Control: no-cache for pages that can change without a deployment. src rules for images and CSS that break hashes are a classic cause of the stale-looking long-lived asset.
• Version every asset: add a hash to the filename (bundle.4f3c2.css) or a query, so a cache miss fixes itself without a manual purge.
• Schedule a purge, not an "expire": CDN purge commands remove the stale copy, while TTL expire still lets between the flag changes.

When the cache is not the problem

If every cache layer is cleared and a curl still returns old text, the change never hit the origin. Check the code, the DB, the branch, and the agent attribution the change actually deployed. A stale page with a fresh body is then a deployment, not a cache, problem.