Why are visitors seeing an old version of my page?

The browser, governed by the `Cache-Control` header your server sent with the page. A long `max-age` on an HTML document is the single most common cause.

A CDN or reverse proxy, which caches according to its own configuration and can be told to keep content longer than the browser does.

An application or plugin page cache, which generates the HTML once and serves the stored copy — and which frequently has its own invalidation rules nobody remembers configuring.

A service worker, which intercepts requests in the browser and can serve its own cached response without ever reaching the network.

Each is a separate cache with a separate lifetime. Purging one while another still holds the page produces the symptom of a purge that did nothing.

`curl -sI https://example.com/page` from a machine that never visited the site shows what a cold client receives. If that is current, the browser or a service worker is the culprit.

Look for a cache status header on the response. Most CDNs report a hit or a miss, and a hit on a stale page names the CDN immediately.

Compare against the origin directly where you can. A current page at the origin and a stale one at the public hostname isolates the edge.

In the browser, a hard reload bypasses the browser cache but not a service worker. The Application panel lists registered service workers and lets you unregister one.

An `Age` header on the response tells you how long the copy has been sitting in a shared cache, in seconds, which is often the whole answer.

A long `max-age` applied to HTML. Documents change in place at the same URL, so they need a short lifetime or revalidation.

A cache policy set once at the server root and inherited by everything, so HTML and versioned assets get the same treatment when they need opposite policies.

`immutable` on a page, which tells the browser not to revalidate even when the visitor reloads.

A CDN configured to ignore the origin's headers and apply its own longer lifetime.

A deployment process that publishes new files without purging the edge, so the origin is current and the edge is not.

Give versioned static assets — files whose names contain a content hash — a long lifetime with `immutable`. They can never change without the name changing, so a year is correct.

Give HTML a short `max-age`, or `no-cache` with a validator so the client revalidates and usually receives a cheap `304`.

Add a purge step to the deployment so the edge is invalidated when new content ships, rather than waiting for it to expire.

Use `stale-while-revalidate` where a few seconds of staleness is acceptable: the visitor gets an instant response and the cache refreshes behind them.

Resist the reflex to set short lifetimes everywhere. That removes the symptom and the benefit together.

A service worker can serve a cached response without any network request, which makes it invisible to every server-side check.

A cache-first strategy for HTML is the configuration that produces indefinitely stale pages, and it is a common default in progressive web app templates.

The symptom is distinctive: the page is stale for returning visitors and current for anyone arriving for the first time.

Unregistering the worker in the Application panel and reloading confirms it. The real fix is a network-first strategy for documents.

VeriFixScan reads the caching headers a page and its assets actually return. `performance.cache_control` reports the policy on the document and `performance.static_cache` the policy on static resources.

`performance.cdn_cache_status` and `infrastructure.cache_state` report what an edge cache said about the response, which is what separates an origin problem from an edge one.

A scan sees one request from one client. It cannot observe a service worker, because that runs in a visitor's browser and never reaches the network.

Where the headers look correct and visitors still report staleness, the service worker is the remaining candidate and has to be checked in a browser.