Cloudflare Cache Not Updating? Here Is What to Clear and When
You change a page, click Purge Cache in Cloudflare, and the old version is still there.
The catch is that Cloudflare might have fetched the old version again. Your website can keep its own cached copy, and clearing Cloudflare does nothing to that copy. The next visitor arrives, Cloudflare asks the server for the page, and the server sends back the same old HTML.
The browser can keep another copy too. That is why a page sometimes looks fixed on your phone but unchanged on your laptop.
Work through the checks below in order. You should be able to narrow it down before clearing the whole site's cache again.
1. Check the Page in a Private Window
Open the public page in a private or incognito window. Make sure you are looking at the published page, not a CMS preview.
If it is current there, check the browser you normally use. It may have an old copy saved, or a login cookie may be changing what the website serves you.
If it is old there too, continue to the website and Cloudflare checks below.
Cloudflare's cache and your browser's cache are separate. Purging Cloudflare does not clear visitors' browsers, so repeating the purge will not remove a file already saved on someone's laptop.
A hard refresh may help with your own browser. For a permanent fix to stale CSS, JavaScript or images, see the file-versioning section below.
2. Work Out Whether the Page or a File Is Old
If your new text appears but the logo is unchanged, check the logo's URL. The page and the image are separate files, with separate cached copies.
The same applies to styling. A page can contain the right text while loading an old stylesheet.
In Cloudflare, open the caching configuration and choose Custom Purge → URL. Enter the full URL of the stale page or file, for example:
1https://example.com/about2https://example.com/images/logo.pngPurge the object you actually changed. Cloudflare's single-file purge instructions cover the process.
Cloudflare recommends targeted purges. Purge Everything also removes unchanged files, sending more requests back to your server while the cache rebuilds.
Then check it again. If the old version returns immediately, find out what the website is sending Cloudflare.
3. Check the Website's Own Cache
Ask your host or developer to load the page directly from the web server, bypassing Cloudflare. That server is what Cloudflare calls the origin.
If the origin returns the old page, clear the website's page cache first. On WordPress that may be a caching plugin or a cache supplied by the host. On Statamic, it may be static caching, which stores the rendered page for reuse.
For Statamic, the command is:
1php please static:clearRun it in the deployed application. Statamic has a dedicated static-cache command; clearing Laravel's general cache does not necessarily clear those pages.
Now check the origin again. Once it returns the new content, purge the affected Cloudflare URL and reload the public page.
The order matters:
- Publish the change.
- Clear the website or hosting cache that still holds the old page.
- Confirm the server returns the new version.
- Purge the affected URL in Cloudflare.
If you run several web servers, make sure the update reached all of them. Otherwise Cloudflare can fetch the new page from one server and the old page from another.
4. Check Whether Cloudflare Is Caching It
Cloudflare does not automatically cache every HTML page. Its default caching mainly applies to supported static file types. Cache Rules, WordPress APO or Worker code can enable caching for more content.
To check a response in Chrome:
- Open developer tools and select Network.
- Tick Disable cache, keep developer tools open and reload the page.
- Select the page request, or the image or stylesheet you are investigating.
- Under Headers, find
CF-Cache-Status.
Chrome's Disable cache option avoids reading a saved browser response and mistaking its old headers for a fresh Cloudflare result.
These are the main results to look for:
| Result | What it means |
|---|---|
| HIT | Cloudflare served a cached copy |
| MISS | Cloudflare fetched a cacheable response from the origin |
| DYNAMIC or BYPASS | Cloudflare did not serve this response from its normal cache |
| STALE | Cloudflare served an expired copy because it could not reach the origin |
The full status reference includes revalidation and background updates.
An old page with MISS is a useful clue. Cloudflare fetched a response, but the response was already old. Go back to the website cache or deployment.
If the origin is current and Cloudflare still returns an old HIT after a purge, check that you purged the exact URL being requested. If a developer has configured different cached versions for devices, cookies or other request details, they may need a purge that includes those details.
Two Settings That Make This Confusing
Development Mode does not empty the cache
Development Mode bypasses Cloudflare's cache for three hours unless you turn it off sooner. It leaves the stored files in place.
That makes it useful for testing: if the new page appears while Development Mode is on, investigate Cloudflare's cache settings. But an unexpired old copy can become relevant again when the bypass ends. Fix the purge or caching rule before treating the problem as resolved.
A later Cache Rule can undo an earlier one
Suppose you add a rule to bypass caching for /pricing, but a rule further down the list makes every page eligible for caching.
Both can match. For conflicting settings, Cloudflare uses the last matching Cache Rule. The broad rule can undo your exception.
Check the rule order, or use Cloudflare Trace to see which settings apply to the URL. If the site uses Workers to generate or cache responses, have the developer check that code too.
Stop CSS and Images Getting Stuck on the Old Version
If you replace logo.png with a new image at the same address, a visitor's browser may keep using the old file until its cache expires.
A new filename avoids that problem:
1logo.png → logo-2026.pngUpdate the page to reference the new filename as well. For CSS and JavaScript, build tools can include a content hash in the filename, so changed files automatically get new addresses.
Adding ?v=2 can also work, but only if the cache includes that parameter when choosing which copy to serve. A rule that ignores query strings can make both versions use the same cached file.
Be careful with that setting on product pages. Ignoring a tracking ID may be fine; ignoring a size or colour parameter can show the wrong product. My Statamic query-string caching guide goes into that distinction.
If new files reach the browser but the page still looks old, check for a service worker, which can keep its own offline cache. Chrome has a separate Bypass for network option for testing that.
Make Cache Clearing Part of Publishing
A one-off purge gets the current edit visible. If every edit needs the same treatment, fix the publishing process.
Your CMS or deployment should clear the affected website cache and then the corresponding Cloudflare copies. Assets should get new filenames when their content changes, and the updated page should reference those files.
That is the kind of routine work a website maintenance plan should cover. You should be able to publish a corrected price or phone number without wondering which version customers will see.
Syntax highlighting by Torchlight