Skip to content
Rescue 404
Rescue

Website Caching & CDN

Website Cache Will Not Clear

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

When a website cache will not clear, another layer is usually still serving the old response — CDN edge, host server cache, object cache, or the browser — even though the WordPress plugin’s “Purge All” button already ran, so identify which layer answered the request from response headers and purge that layer explicitly.

“Clear cache” in one dashboard rarely means every copy of the page is gone. This guide is for when purge buttons appear to succeed but visitors (or you) still see stale HTML, CSS, or API responses. Work layer by layer with proof from headers and uncached requests, instead of disabling caching entirely on a live site.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • Cloudflare documents purge options (URL, hostname, everything) so edge-cached responses can be invalidated on demand. (Cloudflare purge cache)
  • WordPress performance docs treat page caching and object caching as separate layers that can each serve stale content. (WordPress performance optimization)
  • LiteSpeed Cache for WordPress documents its own purge controls for server-level cache independent of browser refresh. (LiteSpeed Cache docs)

What the error means

Caching is a stack, not a single switch. A page caching plugin writes static HTML; many hosts also run Varnish, NGINX FastCGI cache, or LiteSpeed’s server cache in front of PHP; a CDN keeps independent edge copies; Redis or Memcached may hold object-cache entries; and browsers keep their own disk cache. A purge that only hits the plugin leaves every other layer free to keep serving the old payload — which looks exactly like “cache will not clear.” Some CDNs also require a purge-everything vs purge-URL distinction, or they re-cache the stale object immediately if the origin is still returning an old copy from a deeper layer. The reliable approach is to ask each response which layer served it (CF-Cache-Status, X-Cache, X-LiteSpeed-Cache, Age, and similar headers), purge that layer, then re-check with a private window or curl — not to mash Purge until something feels different.

Common symptoms

  • Caching plugin or CDN dashboard reports a successful purge, but the live page is unchanged
  • Stale content persists in private/incognito windows, not only in your everyday browser
  • Different regions or devices show different versions after a “full” clear
  • HTML updates after purge but CSS, JS, or images stay old (or the reverse)
  • Logged-in admins see new content while logged-out visitors still get the old page
  • Response headers still show HIT / age increasing minutes after purge
  • Purge works briefly, then the old version returns within minutes without a new publish

Most likely causes

  1. 01 Only the WordPress page-cache plugin was purged; CDN or host server cache still holds the page
  2. 02 CDN purge targeted a single URL while related assets or the HTML variant under another URL remain cached
  3. 03 Object cache (Redis/Memcached) still serving stale query results after a page-cache flush
  4. 04 Browser or service worker cache masking a successful server-side purge during your own tests
  5. 05 Aggressive “cache everything” page rules re-caching the origin’s still-stale response immediately
  6. 06 Multiple caching plugins or a host panel cache plus a plugin fighting over who owns purge
  7. 07 Purge API credentials expired or the plugin’s CDN integration is disconnected, so “success” is local only
  8. 08 Load-balanced or multi-node hosting where purge did not propagate to every edge or web node

What changed before the problem started

  • CDN, host cache, or a second caching plugin was enabled without updating the purge workflow
  • Cache TTL or “cache everything” rules were increased or newly applied to HTML
  • Caching plugin, CDN, or host platform was updated and changed purge behavior or header names
  • Redis/Memcached object cache was added alongside an existing page cache
  • Site moved hosts or behind a new proxy where the old purge button no longer reaches the active layer

Troubleshooting steps

  1. 01

    Prove the page is still cached with headers, not vibes

    Load the URL in a private window with DevTools Network open, or run curl -I against the public URL. Note CF-Cache-Status, X-Cache, X-LiteSpeed-Cache, Age, and Cache-Control. Success signal: you know whether CDN, server cache, or origin served the response.

  2. 02

    Purge the WordPress page cache, then re-check headers

    Use the active plugin’s Purge All / Clear Cache, wait a minute, and request the URL again. If headers still show a CDN or host HIT, the plugin purge alone was never going to finish the job.

  3. 03

    Purge the CDN with a full cache clear, not only one URL

    In Cloudflare or your host CDN, run Purge Everything (or the equivalent) once for diagnosis. If that fixes it, tighten later to URL/tag purges — but first confirm the edge layer was the stuck copy.

  4. 04

    Ask the host to clear server-level cache

    If headers point at Varnish, NGINX, LiteSpeed, or a host “Dynamic Cache,” use the host panel purge or open a ticket. This layer is invisible inside wp-admin and is a common reason plugin clears “do nothing.”

  5. 05

    Retest from a clean client

    Use a private window, another device, or curl after each purge. Your normal browser may keep showing a local copy and make a successful server purge look like a failure.

  6. 06

    Confirm CDN/plugin purge integration is actually connected

    If the plugin claims to purge Cloudflare (or similar) automatically, open the CDN event/audit log and verify a purge API call landed. Expired tokens produce false confidence inside WordPress.

When to stop troubleshooting

Escalate if you have purged plugin, CDN, and confirmed host cache with header proof and the response is still a HIT of old content; if you lack CDN or host access to purge the layer that is actually serving; if purge API integrations are broken and traffic is high enough that guessing is risky; or if multi-node cache propagation needs the host’s operations team. Bring header screenshots and timestamps of each purge attempt.

Information to collect before requesting help

  • 01 Public URL that stays stale and what old vs new content should show
  • 02 Caching plugin name and whether a CDN sits in front of the domain
  • 03 Host confirmation of server-level cache (Varnish, NGINX, LiteSpeed, etc.)
  • 04 Response headers before and after each purge (CF-Cache-Status, X-Cache, Age, etc.)
  • 05 Whether private-window and curl tests match what you see in your normal browser
  • 06 Timestamps of WordPress edits vs each purge action
  • 07 Whether object cache (Redis/Memcached) is enabled
  • 08 CDN purge type used (single URL vs purge everything) and any API/auth errors

How a professional repairs the problem

We map every cache layer between the visitor and origin, read live response headers to see which layer still owns the HIT, and purge that layer directly — plugin, CDN, host, and object cache in a deliberate order. We verify with uncached clients and curl, then fix the ongoing purge path (API tokens, auto-purge on publish, sane TTLs, single owner for HTML) so the next content update does not require another emergency “purge everything.”

Frequently asked questions

Why does Purge All in WordPress not clear what visitors see? +
Because visitors may be served by a CDN or host cache that never received the purge. The plugin only controls its own store unless its CDN integration is connected and working.
Is this the same as “cache showing old content”? +
Closely related. That guide focuses on stale content after edits; this one focuses on purge actions that appear to succeed but do not actually empty the active layer. The diagnostic header checks overlap on purpose.
Will Purge Everything hurt my site? +
It causes a short rebuild period where first hits are slower. That is expected and usually safer than leaving wrong content or prices live. Prefer targeted purges once you know which layer and URL pattern were stuck.
Could my browser be the only problem? +
Sometimes — which is why private windows and curl matter. If those still show stale content with cache HIT headers, the problem is not local to your browser.
Should I turn caching off until this is fixed? +
Only briefly for diagnosis on low traffic, and preferably on staging. Leaving cache off on a busy production site creates load problems. Fix the purge path instead of disabling the stack.
Why does the old page come back after a successful clear? +
Often a deeper layer was still stale and the CDN re-cached it, or an object cache rebuilt HTML from old data. Clear origin and object cache first, then edge.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.