Why Is My WooCommerce Site Showing Stale Data?

Why This Happens

Each caching layer exists independently and serves its own purpose — a page cache stores full rendered HTML, an object cache stores database query results, a CDN caches assets and sometimes full pages at the network edge, and a browser caches assets locally on the visitor's device. A change made in WordPress needs to propagate through, or be explicitly cleared from, every layer that might be holding an outdated version, and it's easy to clear the obvious one (the page cache plugin) while forgetting the CDN or object cache sitting alongside it.

Common Causes

• A page caching plugin cleared, but a separate CDN layer in front of it still serving its own cached copy of the same page.
• An object cache (Redis/Memcached) holding stale database query results even after page cache is cleared, since it operates at a different layer entirely.
• Browser caching on the specific device being used to check the change, showing an old locally cached version even though the server is now serving fresh content.
• A hosting-level cache (some managed WooCommerce hosts run their own additional caching layer) that isn't controlled by any WordPress-side plugin at all, requiring a separate clear through the hosting control panel.

How to Clear Every Layer

1. Clear the WordPress-level page caching plugin first, if one is active.
2. Clear any object cache (Redis/Memcached) separately, since page cache clearing doesn't always also flush this.
3. Purge the CDN cache if one is in use, through its own dashboard or control panel.
4. Check the hosting control panel for any additional server-level caching specific to that host.
5. Test in a private/incognito browser window to rule out local browser caching as the final check.

Finding which layer is holding the old version

1. Check from another device and network. Open the page on a phone using mobile data. If it still shows the old version, a server or CDN cache holds it. If only your own browser does, it is local.
2. Add a unique query string such as ?nocache=123. If the fresh version appears, a cache is serving a stored copy of the clean address. Some caches ignore query strings, so treat this as a hint, not proof.
3. Read the headers. Values such as age, cf-cache-status, x-cache and x-litespeed-cache show whether a layer served the page and how old its copy is.
4. Purge from the origin outwards: the page-cache plugin, the object cache, the host's cache, then the CDN, and last your browser.

Make it routine

Write down where each cache lives and who controls it. Configure automatic purging so updating a product clears the related pages, and the question of which layer to clear stops being a guess each time.

Need a caching setup properly configured and documented for your team? See WordPress speed optimization.