Old or wrong page showing behind Cloudflare? Read the cache status before purging

Start from the defaults

Cloudflare decides what to cache by file extension, not by content type, and its documentation says it does not cache HTML or JSON by default. Images, stylesheets, scripts, fonts and downloads are eligible; ordinary page HTML is not. So when an ordinary page is stale or shared between visitors, something has made it eligible: a rule, a plugin or an instruction in the site's own headers. That narrows the search a good deal.

A response is also bypassed, not cached, when it carries Cache-Control of private, no-store, no-cache or max-age=0, sets a cookie, or is not a GET. A personal page should do at least one of these. If it does not, nothing is protecting it from a rule that makes it eligible.

Read the cache status

Each response carries a cf-cache-status header. HIT means a stored copy was served. MISS and EXPIRED mean the origin was asked. STALE means an out-of-date copy was served because the origin could not be reached. REVALIDATED and UPDATING mean the copy was checked or is being refreshed. BYPASS means the request was eligible but the origin said not to cache the response. DYNAMIC means Cloudflare decided at request time the item is not eligible. NONE or UNKNOWN means Cloudflare produced the response itself, for example a redirect or a blocked request.

An Age header accompanies HIT, STALE and UPDATING responses and shows how long the copy has been held. A HIT with a large age on a page that should be fresh is the clearest sign of the problem.

• Request the headers for the same address twice and compare the two results.
• Note cache-control, set-cookie and vary alongside the cache status.

How a page becomes wrongly cached

A Cache Rule can mark matching requests eligible for cache, and its Edge TTL setting can follow the origin's cache-control header or ignore it and use a fixed lifetime. A rule that ignores the origin's header also ignores the origin's instruction to treat a page as private. Our reading is that this is why a broad "cache everything" rule is risky on a site with accounts, baskets or checkout, and why it must exclude those page types. A caching plugin or a host-level cache can add the same effect on its own.

• Rules that match a whole site or a broad address pattern.
• Edge TTL set to ignore the origin's headers.
• A second cache in a plugin or at the host that is not purged with the first.

Test safely, then purge the right thing

Test as an anonymous visitor in a private window, and with a test account you create for the purpose. Do not use a real customer's account or ask a customer to try. If you think one person has already seen another's personal page, treat that as a possible data incident. Stop further exposure first, for example by asking your developer or host to bypass caching for those pages or take them offline, then take advice on whether anything must be reported. A purge will not undo what was shown, and the rule can be corrected afterwards.

Cloudflare recommends purging by address. A 200 reply to a purge request only confirms it was received. Request the page again and check that the status is no longer a HIT on the old copy. Purging everything clears the symptom, and the cause returns, so fix the rule or header as well.

How the paid outcome is accepted

The fixed-price job for this is a published test price of £195, not yet tested with buyers, and you pay after sign-off. It covers up to five page types behind one Cloudflare account. Acceptance is a header table showing the behaviour you decided for each page type, an edit followed by a purge that shows to an anonymous visitor with a status other than a hit on the old copy, and a two-session test in which a second visitor never receives the first one's page.

It does not cover speed tuning, a different CDN, security rules or application code beyond a plugin or server header setting.