When WooCommerce shows stale content such as an old price, missing product, outdated stock level, or incorrect upsell, first open the affected page in a private browser window. If the content is correct there, the problem is probably limited to your browser or logged-in session. If it remains stale, work through the cache layers below instead of repeatedly editing the product.
Save the affected URL and note what should appear before changing anything. Test the same URL while logged out and, if possible, from another device or network. This gives you a consistent way to check each fix.
Clear the caches in the right order
A WooCommerce request can pass through several independent cache layers. Clear one layer at a time and reload the affected URL after each step. This helps identify the actual cause.
1. Rule out the browser cache
Perform a hard refresh, then test the page in a private window.
If the private window shows the current content, clear cached files for the site in your normal browser. Also disable browser extensions that modify pages, block scripts, or optimize shopping activity while testing.
A browser cache is unlikely to explain stale content that appears on multiple devices.
2. Purge the WordPress caching plugin
Use the purge or clear-cache option provided by your caching or performance plugin. The control may appear in the WordPress toolbar, the plugin settings, or both.
After purging, check the exact product, shop, category, cart, or account URL that was stale. Clearing a plugin's page cache does not necessarily clear a CDN, hosting cache, or object cache.
Avoid broad database cleanup options unless you have a current backup. Deleting cache files and deleting database records are different operations.
3. Purge the hosting cache and CDN
Managed hosts often apply caching outside WordPress. Purge that cache from the hosting dashboard, then purge your CDN if you use one.
If temporarily bypassing the CDN makes the latest content appear, review its cache rules before enabling it again. Do not leave the CDN disabled as a permanent fix unless its provider or your host recommends it.
4. Check for a persistent object cache
Redis, Memcached, and similar services can retain cached database results independently of the page cache. Check your hosting dashboard and active plugins for an object-cache service or plugin. Your host may manage it without displaying a normal WordPress plugin.
Use the provider's Flush object cache or equivalent control, then test the affected URL again. Do not restart or disable Redis or Memcached at the server level unless you administer the server and understand which sites or applications share it.
Sites with WP-CLI access can flush the WordPress object cache with:
wp cache flushThis command clears cached objects, not WooCommerce products or orders. On a busy store, run it during a quieter period because requests may temporarily place more load on the database while the cache is rebuilt. See the official wp cache flush documentation for command details.
If flushing the object cache fixes the problem only briefly, contact the cache plugin vendor or host. Repeatedly flushing it masks an invalidation or configuration problem rather than resolving it. WordPress explains how persistent object caching works in its performance documentation.
Keep dynamic WooCommerce pages out of full-page cache
Cart, checkout, and account pages depend on the visitor's session. Serving a previously cached copy can cause symptoms such as:
- An empty cart after adding a product
- Another cart state appearing briefly
- Old totals, shipping methods, or payment options
- Account content that does not update
- Checkout fields or notices disappearing
Check that your page-cache, server-cache, and CDN rules exclude the current WooCommerce cart, checkout, and My Account URLs. WooCommerce's caching guidance identifies these as dynamic pages and also documents the session cookies that caching systems need to respect.
Stores with translated pages or custom slugs need exclusions for every active version of those URLs. Also review rules that cache pages for logged-in users or ignore WooCommerce cookies and query strings. Use the documentation for your specific cache plugin, host, or CDN rather than copying exclusions written for another product.
After changing an exclusion, purge all affected cache layers and test in a new private window. Add a product to the cart, change its quantity, visit checkout, and confirm that totals and notices update normally.
Check whether the stored product data is current
A cache purge cannot fix incorrect source data. Open the product in WordPress and confirm that its status, price, stock, visibility, categories, upsells, and cross-sells are saved correctly.
For linked products, verify the settings on the product where the recommendation should appear. The storefront location and layout of upsells and cross-sells can vary by theme or template, so missing recommendations do not automatically prove that cached data is being served.
Update the product once without making an unrelated change, then check it while logged out. If the product editor contains the new value but every uncached storefront request shows the old one, continue with conflict testing.
Check scheduled WooCommerce work
Some WooCommerce extensions process imports, stock synchronization, reports, subscriptions, and other updates through scheduled tasks. A delayed or failed task can look like a caching problem because the underlying data has not been updated.
Open WooCommerce > Status > Scheduled Actions and look for failed or overdue actions related to the affected extension or feature. WooCommerce documents these tasks in its Scheduled Actions administration guidance.
Do not run every pending action at once on a live store. A large queue may indicate a cron, extension, or server problem. Record the failed action details and investigate the associated plugin before retrying it.
Sites with command-line access can inspect upcoming WordPress cron events without changing them:
wp cron event list --fields=hook,next_run_relative,recurrenceLook for WooCommerce or extension-specific hooks that remain overdue. The WP-CLI cron event documentation explains the available inspection and execution commands.
Test for a plugin or theme conflict
If purging every cache layer does not help, the stale output may come from a theme template, product-filter plugin, page builder, search index, feed integration, or optimization plugin.
Create a backup or staging copy before conflict testing. Then:
- Temporarily switch to a default WordPress theme or WooCommerce's Storefront theme.
- Disable caching and optimization plugins.
- Disable other plugins in small groups, leaving WooCommerce active.
- Purge the remaining server, object, and CDN caches after each change.
- Retest the same URL in a new private window.
WooCommerce provides a detailed conflict-testing procedure designed to reduce disruption. On a live store, use troubleshooting mode or a staging site whenever possible.
When the current content returns, reactivate components one at a time until the problem reappears. This identifies the conflicting component more reliably than leaving several plugins disabled and guessing.
Rebuild only the affected integration
Search, filtering, multilingual, inventory, and product-feed extensions may maintain their own indexes or generated data. Their rebuild or synchronization controls are separate from page and object-cache purges.
Use the affected extension's documented rebuild function only after confirming that its output is stale. Take a database backup first if the operation rewrites product metadata, lookup tables, translations, or inventory.
Do not repeatedly flush permalinks for an old price, stock value, or product recommendation. Rewrite rules control URL routing; they are not a general WooCommerce content cache.
Restore service if a change makes the store worse
If new cache exclusions slow the site significantly or expose private content, restore the previous rules and purge the cache again.
If conflict testing causes checkout or layout problems, reactivate the disabled plugin or original theme immediately. Keep the identified component disabled only when the store remains functional without it. Otherwise, restore its previous version from a known backup or contact its vendor with the affected URL, reproduction steps, and WooCommerce status information.