Which caching layer is responsible for stale WooCommerce product data after an update?

The short answer

It depends on how the update was written. If the price or stock was changed through the WooCommerce admin, REST API, or any code path that uses the product CRUD objects, WooCommerce fires its invalidation hooks (for example woocommerce_update_product and stock-change hooks), which delete product transients and bump the products cache group. In that case the origin is almost always fresh, and the stale layer is the page cache or CDN edge cache.

If the value was written directly to postmeta — a SQL import, a stock-sync plugin that bypasses CRUD, or a manual database edit — those hooks never fire. Then the stale layer is the persistent object cache and versioned product transients, and often the wc_product_meta_lookup table as well.

Pinpointing the layer

One test is decisive: request the product URL with a random query string appended (or view it logged in as admin, which most page caches bypass).

• Fresh value with the cache-buster, stale without it → the page/CDN cache is the culprit. Confirm by checking response headers on the stale response: cf-cache-status: HIT, x-cache: HIT, x-litespeed-cache: hit, or a large age value.
• Stale value even with the cache-buster → the origin is stale: object cache, transients, or the lookup table. Compare the Store API/REST product JSON against the rendered HTML and the actual wp_postmeta and wc_product_meta_lookup rows to see which disagree.

Note that with a Redis or Memcached drop-in active, transients are stored in the object cache rather than the options table, so "stale transient" and "stale object cache" are usually the same problem. WooCommerce keys product price transients by a group version, so a version bump invalidates them without deleting anything. Use wp cache get, wp transient list, or your object-cache plugin's diagnostics to inspect the keys, and check Site Health's Drop-ins section to confirm which object-cache.php is actually loaded.

Safe invalidation order

1. Fix the source first. Re-save the product through CRUD, or call wc_delete_product_transients( $product_id ). If the write path bypasses hooks, purging caches is pointless until that's corrected.
2. Rebuild the lookup table only if it disagrees with postmeta — via WooCommerce → Status → Tools ("Regenerate product lookup tables"), which runs as a background job rather than a blocking flush.
3. Purge page cache and CDN last, per-URL or per-cache-tag for the affected products only, so the edge refetches from an already-fresh origin. Warm the top product URLs afterward to absorb refetch load.

Avoid wp cache flush and "purge everything" on a busy store: mass expiry is what causes stampedes. Targeted purges and version bumps regenerate only the touched items. Purging before fixing the origin just re-caches stale data.

Tools and caveats

WooCommerce provides wc_delete_product_transients(), WC_Cache_Helper::invalidate_cache_group( 'products' ), and the Status → Tools actions for clearing transients and rebuilding lookup tables — none require a full object-cache flush. HPOS does not change product caching (products still live in posts/postmeta; only orders moved). Cart, checkout, and account pages must stay excluded from page and CDN caching regardless.

Hook names, tool labels, and lookup-table behavior vary across WooCommerce versions, and third-party cache plugins add their own purge layers — verify function names against your installed version before scripting anything.