Skip to content
Rescue 404
Rescue

Website Caching & CDN

WordPress Cache Showing Old Content

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

A WordPress site showing old content almost always means a cache layer between the visitor and your live database still holds a stale copy of the page — this can be the page cache plugin, the browser, a CDN edge node, or the host's own server-level cache, and sometimes two or three of these at once. The fix is to clear each layer in order, from closest to WordPress outward to the CDN, rather than guessing at one and assuming it worked.

Because a single page can be cached in up to four separate places, clearing only one of them often looks like "the fix didn't work" when really the other three are still serving the old copy. This guide walks through identifying which layer is stuck, purging them in the right order, and confirming the fix with a real, uncached request instead of another cached page load.

Intermediate

Key facts

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

  • WordPress performance guidance treats caching as a primary lever for faster responses, which also means stale HTML can keep serving after you edit content until caches are purged. (WordPress optimization)
  • Cloudflare Instant Purge can clear cached edge content immediately; purge by URL is the recommended option when only specific pages are stale. (Cloudflare purge cache)
  • WordPress advanced administration documents layered optimization—including caching, compression, and database tuning—so stale content may sit at plugin, host, or CDN layers at once. (WordPress performance optimization)

What the error means

When you save changes in WordPress, the update only lands in the database and the underlying files immediately — it does not automatically reach every cached copy sitting between the database and the visitor. A page caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache) may have already generated a static HTML snapshot of that page and will keep serving it until it expires or is purged. If a CDN sits in front of the site (Cloudflare, a hosting-provided CDN, or a dedicated edge network), it holds its own separate copy at edge locations around the world, independent of the plugin cache. Many hosts also run a server-level cache (Varnish, NGINX FastCGI cache, LiteSpeed's built-in LSCache) that caches responses before WordPress even finishes rendering. Finally, the visitor's own browser caches pages and assets locally and may keep showing an old version from its own disk cache regardless of what the server sends. Because these layers are independent, clearing the plugin cache alone frequently does nothing if the CDN or browser cache is the one actually serving the stale page.

Common symptoms

  • Content, prices, or images were updated in WordPress but the live site still shows the old version
  • The change appears correctly when logged into wp-admin or previewing, but not on the public page
  • The page updates correctly in an incognito/private window but not in your regular browser
  • Clearing the caching plugin's cache does not change what visitors see
  • Different visitors in different locations report seeing different versions of the same page
  • A hard refresh (Ctrl+F5 / Cmd+Shift+R) temporarily fixes it, but the old content returns after some time
  • Old content persists specifically for logged-out visitors while logged-in admins see the update immediately

Most likely causes

  1. 01 Page caching plugin has not regenerated its cached copy of the specific URL that changed
  2. 02 A CDN (Cloudflare or a host-provided CDN) is serving an edge-cached copy that was never purged
  3. 03 A server-level cache (Varnish, NGINX FastCGI, LiteSpeed LSCache) sits in front of WordPress and was not cleared
  4. 04 The visitor's own browser cache is holding a locally stored copy of the page or its assets
  5. 05 Cache TTL (time-to-live) is set very long, so the stale copy will not expire naturally for hours or days
  6. 06 An object cache (Redis or Memcached) is caching database query results, not just the rendered page
  7. 07 The edit was made to a template, widget, or menu that is cached separately from the page content itself
  8. 08 A "cache everything" or aggressive full-page cache rule is caching content that should have been excluded, such as account pages or dynamic widgets

What changed before the problem started

  • A caching plugin was installed or its settings (cache lifespan, exclusions) were changed recently
  • A CDN or "always online"/proxy feature was newly enabled in front of the domain
  • The hosting plan or server was upgraded or migrated to one with a different built-in caching layer
  • Cache lifetime/TTL settings were increased to reduce server load, extending how long stale content persists
  • A new page builder, theme, or plugin changed how a section of the page is rendered or cached
  • An object cache (Redis/Memcached) was added to speed up the database layer

Troubleshooting steps

  1. 01

    Confirm the change actually saved in WordPress first

    Open the page or post in wp-admin and verify the edit is really saved there — check the "Last modified" timestamp. If it is not saved correctly in the database, no amount of cache clearing will show it on the front end, so rule this out before touching any cache.

  2. 02

    Clear the page caching plugin's cache

    If you use WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, or a similar plugin, use its "Clear Cache" or "Purge All" button in the WordPress admin bar or plugin settings. Purge the entire cache rather than just the single URL the first time, to rule out related cached fragments (menus, widgets).

  3. 03

    Purge the CDN cache if one is in use

    If the site sits behind Cloudflare or a hosting-provided CDN, log into that dashboard and run a full cache purge, not just a purge of one URL. CDN edge caches are separate from your WordPress plugin cache and will keep serving old content even after the plugin cache is cleared.

  4. 04

    Ask your host to clear any server-level cache

    Many hosts run Varnish, NGINX FastCGI caching, or LiteSpeed's server-level LSCache in front of WordPress, invisible from inside wp-admin. If clearing the plugin and CDN cache does not fix it, ask your host to confirm whether a server-side cache exists and purge it.

  5. 05

    Test in a private/incognito window, not your regular browser

    Your everyday browser may be showing its own cached copy of the page. Open a private/incognito window (or a different browser you rarely use) and load the URL directly to see what a fresh visitor actually receives, separate from your local browser cache.

  6. 06

    Add a cache-busting query string to force a fresh check

    Load the page with `?nocache=1` or `?v=2` appended to the URL. This bypasses most page and browser caches (though not all CDN configurations) and gives you a quick read on whether the underlying content has actually updated on the server.

  7. 07

    Check for exclusion rules if only one page type is affected

    If dynamic content like a shopping cart, account page, or a widget consistently shows stale data, check the caching plugin's exclusion/exception list — that URL pattern or cookie-based rule may need to be added so it is never cached in the first place.

When to stop troubleshooting

Escalate to a professional or your host if you have purged the plugin cache, CDN cache, and confirmed with incognito/curl testing but old content still appears; if you do not have access to the CDN dashboard or server-level cache to purge it yourself; if the site uses a caching setup you did not configure and do not fully understand; or if purging caches risks slowing down a high-traffic site and you want it done carefully during low-traffic hours.

Information to collect before requesting help

  • 01 The exact URL showing old content, and what the old vs. new content should be
  • 02 Which caching plugin (if any) is active, and its cache lifespan/TTL setting
  • 03 Whether a CDN (Cloudflare or other) is in front of the domain
  • 04 Whether your host confirms a server-level cache (Varnish, NGINX, LiteSpeed) is running
  • 05 Results of testing the URL in an incognito window and with a cache-busting query string
  • 06 Response headers from `curl -I` or DevTools showing `X-Cache`, `CF-Cache-Status`, or `Age`
  • 07 Whether the issue affects all visitors or only specific ones (logged-in vs. logged-out, specific regions)
  • 08 Timestamp of the WordPress edit and timestamp of when you last purged each cache layer

How a professional repairs the problem

A technician maps every cache layer sitting between the visitor and WordPress — browser, CDN, server-level cache, page caching plugin, and object cache — before touching any settings, since each is cleared differently and in a different place. They inspect response headers to identify exactly which layer served a specific stale request, purge that layer directly, then verify with an uncached request rather than a second cached page load. Where the same issue keeps recurring, they configure auto-purge on content updates and set sane TTLs so future edits propagate without a manual purge every time.

Frequently asked questions

Why does clearing my caching plugin not fix stale content? +
Because a page can be cached in more than one place at once. If a CDN or a server-level cache (Varnish, NGINX, LiteSpeed) also holds a copy, clearing only the WordPress plugin's cache leaves those other layers still serving the old version.
Why do I see the update but visitors do not? +
Logged-in administrators are usually excluded from the page cache by default so they always see live content while editing. Logged-out visitors are served the cached version, which is why the update looks "live" to you but stale to everyone else until the cache is purged.
How long should I wait before assuming the cache is stuck? +
If your cache lifespan (TTL) is set to, say, 24 hours, stale content can persist that long on its own without a manual purge. If it has been longer than the configured TTL and content is still stale, treat it as stuck and manually purge every layer rather than waiting further.
Does a hard refresh (Ctrl+F5) fix this for good? +
A hard refresh only clears your own browser's local cache for that one visit — it does not touch the CDN, server, or plugin cache. Other visitors and even you on a different device will keep seeing the old content until the underlying cache layers are purged.
Could my hosting cache be the problem even if I don't use a caching plugin? +
Yes. Many hosts run their own server-level caching (Varnish or NGINX FastCGI caching, for example) independent of anything installed in WordPress. If you have no caching plugin active and content is still stale, ask your host directly whether server-side caching is enabled and how to purge it.
Will purging every cache slow my site down afterward? +
Briefly, yes — the first visitor to each page after a purge triggers a fresh, uncached page generation, which is slightly slower. This is normal and expected; the cache rebuilds automatically as pages are viewed again, and full purges are safe to run whenever content needs to update.

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.