Job cloudflare-cache-showing-stale-or-private-pages · revised 11 October 2026
Fix Cloudflare caching that shows visitors old, wrong or private pages
Find which cache rule or response header makes pages stale or shared between visitors, fix it for up to five page types, and prove it with headers and two test sessions.
You might be seeing
- Edits appear for you but not for other visitors, or only after many hours
- A logged-in page, basket or form seems to be shared between people
- Purging "everything" fixes it for a while and it comes back
- The response headers show a cached copy for pages that should never be cached
No passwords, keys, card details or admin invites needed to start.
What usually happened
A CDN stores copies of pages so it can serve them faster. Cloudflare does not cache ordinary HTML or JSON pages by default, so stale or shared pages point to a cache rule or caching plugin that has made them eligible, or to site headers that do not mark personal pages private. The visitor then sees an old copy after an edit or, worse, a copy made for someone else. Fixing it needs the right rule per page type, not a blanket purge.
Who it’s for: Owner of a small business whose site sits behind Cloudflare and shows visitors out-of-date content after an edit, or shows one person's account or basket page to another.
Usually starts when: You edited a page and it will not update, a price change did not show, or a customer reports seeing someone else's logged-in page.
The result: For up to five agreed page types, the response headers show the cache behaviour you decided, an edit followed by a purge shows to an anonymous visitor, and in the two-session test the second test session does not receive the first session's page.
Check whether this job fits
Four questions, about two minutes. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Read the cache status of one page
On a Mac or Linux terminal, request the affected address the way a browser does (a GET), throw the page body away and show only the response headers. Run it twice and compare: the first request can fill the cache, so the second shows what is stored. Do not use curl -I here: it sends a header-only HEAD request, and Cloudflare's documentation lists any request method other than GET as not cached, so it is not a reliable stand-in for what a browser is served.
curl -s -o /dev/null -D - https://yourbusiness.co.uk/the-page/ | grep -i -E "^(cf-cache-status|age|cache-control|set-cookie):"Look for: HIT means a stored copy was served, MISS and EXPIRED mean the origin was asked, DYNAMIC means not eligible for cache and BYPASS means the origin said not to cache. A HIT on a page that should be fresh is the cause. Send us the output.
What you get
- A table of page types with the cache behaviour wanted, the behaviour found and the cause
- The changed rules and settings, with their previous values
- A test record of the edit-and-purge test and the two-session test
- A one-page note of how to purge one address and how to read the status header
Included
- One site behind one Cloudflare account, with up to five page types, for example public pages, blog posts, account pages, basket and checkout pages, and the admin area
- Reading the response headers for each page type, including the cache status, the age and the site's cache and cookie headers
- Reading the account's cache rules and any caching plugin settings that apply to the site
- Changing the cache rules, and the plugin or server setting that sets the headers where you grant access, so each page type behaves as agreed
- A purge of the affected addresses, and tests as an anonymous visitor and as two separate test sessions
Not included
- Speed tuning, image optimisation or choosing a faster host: see the slow-site checks in the guides
- Changing application code beyond a plugin or server setting that sets cache headers
- Security rules, bot protection or a web application firewall
- Moving to or away from Cloudflare
- Any assessment of personal data already exposed: stopping further exposure and deciding whether anything must be reported are yours to do with your adviser; we correct the rule afterwards
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For each agreed page type, the response headers for two GET requests (body discarded, because Cloudflare lists other request methods as not cached) show the cache status and cache headers you decided, and no personal page type shows a cached copy.
Evidence: A table of page type, address, status, age and cache-control for both requests
curl -s -o /dev/null -D - https://yourbusiness.co.uk/the-page/ | grep -i -E "^(cf-cache-status|age|cache-control|set-cookie):"After an agreed edit to one public test page and a purge of that address, the first anonymous request returns the edited content and a cache status other than a hit on the old copy.
Evidence: Before and after screenshots and the headers of the first request after the purge
Two separate test sessions request the same account or basket address; the second never receives the first session's content.
Evidence: Screenshots from each session and the headers of both requests
Sign-off. You sign off after the header table, the edit-and-purge test and the two-session test pass, and you have read the purge note.
If it fails. If a page type cannot be settled with the agreed access, it is listed with the reason and what the site's developer must change, and you pay only for page types that pass.
When it fits, and when we stop
It fits when
- The site is behind a Cloudflare account that you or its holder can show us, with read access at least
- You can create two test accounts or sessions that you delete afterwards, if the site has logged-in pages
- Someone can change the Cloudflare rules or will make the changes from our steps
We stop and tell you if
- A customer's personal data may already have been shown to another person: stop further exposure first, then take advice on reporting. This job corrects the cache rule afterwards
- The site is not behind Cloudflare, or the account cannot be shown to us
- The page type is generated by code that sets no usable cache headers and nobody can change it
- The site has more than five distinct page types to settle
What could go wrong
Every rule and setting is recorded with its previous value, so the account holder can put it back. A purge only clears cached copies and cannot lose content.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A stricter rule makes the site slower because pages are no longer cached. | We cache only what is safe and say which page types stay uncached and why. |
| A personal page is accidentally made cacheable. | The two-session test and a second reviewer look for that case specifically. |
| A second cache, such as a plugin, keeps the problem alive. | We list every cache in the path and test with each purged. |
A second reviewer, separate from the work that produced the change, checks it against the evidence before you are asked to apply or approve it. No human supervisor is included unless your proposal names one. At launch much of the preparation is automated, and we say so.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Read the headers for each page type and record what is served and why
- Read the Cloudflare cache rules and any caching plugin and host settings that apply
- Agree the wanted behaviour for each page type with you
- Prepare the smallest change per page type; a second reviewer checks that no personal page can become cacheable
- You or the account holder apply the changes; we purge the affected addresses and run the edit-and-purge test and the two-session test
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
To keep the site and certificate watched, ask about the standing domain and DNS responsibility or the uptime alerts job.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Cloudflare's dashboard can purge one address at a time, and its documentation explains each cache status value. If the site just needs one stale page cleared, that is free. developers.cloudflare.com
- If the site runs WordPress, the caching plugin's own settings often have a "never cache these pages" list for baskets and account pages. Check it first.
Questions
Why not just purge everything each time?
It clears the symptom but not the rule that caused it, so it returns. It also removes caches that were helping you.
Will my site get slower?
Possibly for the page types that stop being cached, which is why we cache only what is safe and tell you which pages stay uncached.
Someone saw another customer's page. What now?
Stop further exposure first: ask your developer or host to bypass caching for those pages or take them offline. Then take advice on whether anything must be reported. We correct the cache rule afterwards.
Send an enquiry
Send us
- The site address and the page or page type that is wrong, with what you expected
- Whether the site runs WordPress or another platform, and whether a cache plugin is installed
- Whether it has logged-in pages, baskets or checkout
- When you first noticed it and anything that changed that day
Later, once you agree
- A read-only invitation to the Cloudflare account, or screenshots of the cache rules, the cache settings and any page rules
- Two test accounts you create for us, or a plan for creating two sessions
- Access to the caching plugin settings or the host's header setting, or a person who will change them
- No live passwords or customer records by ordinary email
The site and the Cloudflare account stay in your name. We ask for read access and make changes only through you or a scoped invitation you can withdraw. Test accounts hold no customer data and are deleted afterwards.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “cloudflare-cache-showing-stale-or-private-pages” as the subject.