Single page cache purge not working

I can see the same thing happening in my web app. Everything works fine, with the Cache Everything and Respect Headers settings and all. Once the cache naturally expires it gets refreshed and served properly via CF for the next period.
But the API-based purge and Custom Purge by URL in the CF panel both have no effect, despite the first one giving an optimistic “success” response.

Well, perhaps it’s not just me. So thanks for your feedback.

Your description of the issue is exactly the same for me. Everything works fine except for custom purge from the CF dashboard or via my plugin.

Both deliver a success message, but without a successful refresh.

I’ve checked, and triple checked all my settings.

I can only hope Cloudflare is aware of the issue because there’s not much else I can do to resolve this.

As an extra note, I just discovered that new comments on my blog are not appearing for non-logged-in users.

I’m not able to replicate this. I was able to purge the URL of one of my image files.

When it says “Success”, it just means it successfully sent the purge request. If it doesn’t match the cache key, the resource will not get purged.

This should never happen, unless you’ve deliberately configured Cloudflare to cache HTML.

Yes, I’m caching HTML with the cache everything rule using the Super Page Cache for Cloudflare plugin.

But it has been working perfectly for a couple of years now. The problem only arose yesterday.

As for cache keys, I have no idea how to use or change them. What do you suggest?


I also use super page cache WordPress plugin for 1-2 years now and was working fine.
This plugin uses page rules for caching everything in Cloudflare, and has an option to clear cache only for updating posts and relevants. This suddenly stopped working since yesterday.

So I went to Cloudflare, press custom purge, put my domain name homepage only and it still doesnt work!
So after I choose purge all cache and ONLY then it works after some time.

The second step was to use workers instead of page rules for caching and it worked out of the box from plugin, without changing anything in Cloudflare!

Waiting for feedback



Interesting :thinking:

I haven’t used this caching plugin for WP in combination with Cloudflare.

However, I wonder how does it work, does it “on save” or “on publish” or “on update” of the WP post/page, purge locally disk files then via API executes the “Purge Everything” at Cloudflare for a connected zone?

Do you see any event when you navigate to the CF account → Audit Log? :thinking:

Typical behavior with the plugin is to refresh a single page on “update”. If it fails for some reason, then using CF Custom Purge usually fixes the problem.

But at the moment, neither of these options work with the Cache Everything rule.

I checked the Audit Log, and there are only entries for Purge Everything, and none for any single page updates.

However, there is an option in the plugin to use CF Workers. When I change to this option, everything works correctly.

So it seems to tell me that the plugin is working as it should.

I had this same issue last year, and it turned out to be a CF problem.

I’m not sure what more I can do other than to use Workers until there is a resolution for the Cache Everything rule.

1 Like

Just one more piece to the puzzle, Fritex.

The developer of the plugin has checked the log files from myself and another user.

He says:

The logs are showing that on sending the purge request the CF API is not throwing any errors but rather sending success. But the weird part is it is actually not happening.

So, there is definitely some issue going on inside Cloudflare where despite API showing success, the task is actually not getting performed.

Hopefully, this information helps.

1 Like

Sounds to be like using Cloudflare Workers as “Bypass Cache by Cookie” (which is available on a Business or Enterprise plan) if we want to use Cache Everything as described here:

Otherwise, we’d have issues like other visitors, like non-logged-in users would end-up having and seeing the “admin top bar” from the served and cached version of the “logged-in” admin user when visting your homepage or some other webpage → not good.

If they visited the page before login, therefore after, they still see the cached version .html webpage.

After they hit refresh, or fire up Developer Console (F12) with feature “Disable cache”, should se the other version as “logged-in”.

If that does not happen, you might need to flush the cache frome somewhere else to get the “non-cached” version for the “logged-in” user.
I saw similar behaviour using WordPress / W3 Total Cache (Browser cache / Disk Cache) / Cloudflare (Cache Everything).

For example, I visit the homepage, open an article, go back to homepage, not being logged into WP Admin dashboard.
After that, I log into the WP Admin dashboard.
Go back to homepage and see the same cached homepage, there is no “top admin bar” shown indicating I am logged into.
I have to hit refresh or start-up Developer Console (F12) to make it appear.
Sometimes even twice.
Or there was one situation where I have had to “Purge Cache” from W3 Total Cache, so it triggered even purging Disk Cache at the server + Cloudflare Purge Everything (I saw in Audit Logs from my Cloudflare account).
Thereafter, hit F5 (refresh) and woulla, the “top admin bar” appeared.

From my point of view, we shouldn’t use a Page Rule with the option Cache Level: Cache Everything, except if we’d have some kind of a content extension which isn’t already being listed at the link above, therefore you can remove that option while keep the others.

Furthermore, regarding a WordPress website and login forms and cached content, using Cache Level: Cache Everything would not be suitable over the whole domain (only on a part of it such as sub-directory, etc.) as far as non-logged visitors would end-up seeing a cached logged-in version of a homepage or an article with the Admin Bar / Logged-in user bar at the top, which would make nosense and confuse and create bad user experience.

For example, if you’d setup your Page Rule like that, but for like*, then you’d have the issues as mentioned above and even more like you’d keep that cached at Cloudflare for a month and in user’s device web browser for 5 days. So, even you might not see any new posted content too. That would be an issue then. In case if that happens, disable the Page Rule which is affecting and messing around your Website and use “Purge Everything” from the Cloudflare dashboard → Caching → Configuration tab to clear the cache at the Cloudflare (at least).

It’s a bit tricky to setup “origin cache control headers”, then Browser Cache TTL, Edge Cache TTL and if so, over the top of all that, Cache Everything, and expect it to work fine on a Free plan :smiley:

1 Like

Thanks for your in-depth explanation, fritex.

But it doesn’t really explain why the Cache Everything rule has worked perfectly for well over two years, apart from a glitch in June 2021 and now in the last few days.

But to save wasting time chasing the current issue, I have enabled Workers and the paid plan for my main site.

As far as I can see, everything works perfectly, so it’s the best solution for me.

I’ll check my one site that is still using the Cache Everything rule over the coming days but will probably change it over to Workers if there is no resolution to the problem.


I just tried Cloudflare plugin for WordPress and caching still doesn’t work.

In the Apply Recommended Cloudflare Settings for WordPress option, when I enabled it keeps rotating for even and never ends, which means a communication error with Cloudflare maybe.

Also the Always Online option doesn’t work from the plugin when I enabled it. In Cloudflare it stays off

Bottom line there is an issue with Cloudflare CDN caching for sure, and Engineers must have a look into it

Thank you for feedback in the meantime.

I cannot figure it out, however if this is something with Cloudflare, kindly I’d suggest you to write a ticket to the Cloudflare support and share your ticket number here with us so we could escalate your issue.

You might be offered to switch to the new Customer Support Portal and create a ticket there.


  • Ticket ID: [2585671]
  • Ticket ID: 2585671

Ok the ticket is ready.

Single page (custom) cache purge does not work even from Cloudflare panel, only full cache purge is working after some time…

They mark my ticket as resolved… :roll_eyes:

Thank you for contacting Cloudflare Support. Your plan type grants you access to Support via our Cloudflare Community.

**It looks like you are experiencing an issue with cache. Our Support team is only available to provide assistance on billing, account, and registrar related issues. If you believe your issue falls into one of these categories, please reply here. Otherwise, see the resources below.

Alright, I’ve escalated this ticket. Thanks for the report.


I have the same problem. Also started to happen 2 days ago. Also super cache Cloudflare plugin. For me my website doesn’t refresh content even when enabling development mode and purge cache. The cache purges after many hours later.

Any origin cache like fastcgi, nginx, engintron, etc?

Maybe that particular plugin cannot flush the origin cache → configured by the hosting provider. Therefore, plugin only flushes the cached “page cache” .html document, which origin cache catches and overall the Cloudflare gets that version and serves it “as-is” by the web server :thinking:

1 Like


cache-control s-maxage=31536000, max-age=60
x-wp-cf-super-cache cache
x-wp-cf-super-cache-active 1
x-wp-cf-super-cache-cache-control s-maxage=31536000, max-age=60
x-wp-cf-super-cache-cookies-bypass swfpc-feature-not-enabled
x-fastcgi-cache HIT
cf-cache-status DYNAMIC
report-to {“endpoints”:[{“url”:“”}],“group”:“cf-nel”,“max_age”:604800}
nel {“success_fraction”:0,“report_to”:“cf-nel”,“max_age”:604800}
server Cloudflare


Response headers. Yes i have fast CGI but it was always enabled on my vps. Today after 24hours my website still has old content despite removing also page rule that plugin created.

Same problem here. Haven’t been able to single purge for 36 hours now. Both through API and when logging in on Cloudflare.

The only way I can reproduce this is if I use the API Token setup, as instructed in the configuration. Adding or updating a post does not purge my home page, the post itself, or its categories page, even though enhanced logging shows the purge request.

I am not using the Workers option.

Custom Purge in Dashboard per URL still works as expected.

Only if I use the Global API Key, does my home page and Category page update if I add a post.

One thing interesting thing is that I’ve set Logging to High, but I’m not seeing the API response, as shown in the Plugin Support thread at WordpressORG.