A shop’s cache needs to notice purchases, refunds and stock imports as well as edits in the product screen. I trace each route which changes availability or pricing, then check that the affected pages and reusable data are refreshed. Waiting for a long expiry can leave customers looking at information which has already changed.
List the things that change the answer
An order, a refund, a stock import and a scheduled sale can all affect information shown on a product page. They do not necessarily pass through the same sequence as an editor saving a post. I start by listing those routes and checking which application events each one emits.
I prefer the commerce platform’s stock and product events to guessing from database writes. The event carries useful meaning: a variation changed, stock was reduced or the product was updated. It also gives a clearer place to test the integration.
Follow a variation back to its page
A variation may have its own stock record while shoppers view it through the parent product page. Clearing an imaginary public page for the variation would leave the real page untouched. I resolve the parent before invalidating that page’s stored output.
The first fix was deliberately narrow: clear the affected product page instead of emptying the whole site cache on every order. A busy shop should not repeatedly send all of its unrelated catalogue pages back to a cold render.
Keep the dependency work honest
That narrow action does not automatically refresh every product grid, filter count or “in stock” listing elsewhere. Those are separate dependencies. If a cached collection changes membership when an item sells out, it needs a collection-level invalidation rule as well.
The same distinction applies to a product assembled from other products. A component price can change while the parent’s modification date stays the same. I do not treat a parent timestamp as proof that all of the data beneath it is unchanged.
Check the actual basket routes too
I make the early cache layer use the store’s configured transaction-page paths. A cache which only recognises the default English slugs can miss a renamed basket or account page.
WooCommerce’s caching guidance keeps basket, checkout and account pages dynamic because their contents depend on the customer. That rule must apply before an early page cache responds, as well as later when WordPress renders the page.
Use a real stock transition
My useful check starts with a warm public product page. I change stock through the supported commerce workflow, then inspect the next anonymous response and its cache status. I repeat it for a variation and verify that an unrelated product can keep its warm entry.
For a test order or refund I use a controlled test environment and suitable payment test mode. The point is to exercise the path that changes stock, then prove the public page catches up without causing an unnecessary site-wide rebuild.