Test the first add to basket in a clean browser before trusting a shop’s cache policy. A new visitor can load a shared product page successfully, then lose their first item if a cookie guard prevents the application from establishing a session. I check the transition from anonymous browsing to a persistent basket.
Incoming cookies describe the previous state
A new visitor arrives without basket cookies. That is useful information when deciding whether a plain product-page view can use a shared cache. It does not mean the entire request must remain anonymous and stateless.
A form submission can change the situation during that request. Once the application has accepted an item, it needs to create or update the shopper’s session and send the necessary cookie. A guard which only looks at the incoming cookie jar can miss that transition.
Let the application establish the session
I check that the successful add can send the session cookie the next request needs. I then repeat an ordinary guest page view to check that the change has not started unnecessary sessions across the rest of the shop.
Understand the commerce platform’s own session lifecycle before intercepting it. Avoid creating unnecessary sessions, but do not suppress a session the shopping workflow has just made necessary.
Check every route into the basket
A product form, a composite-product form and a JavaScript-driven add button can reach the application differently. A successful test through one route does not prove the others work. I include ordinary form submissions as well as the asynchronous routes.
I include the store’s actual basket and account paths in the cache policy rather than relying solely on a few default URL names. The early cache and the application cache must agree about where a live response is required.
Old sessions can hide the problem
A developer who is signed in or already has basket cookies may never see a first-visit fault. Another plugin can mask it too by starting a session earlier than necessary. Removing that behaviour later can expose the original mistake without being the underlying cause.
I therefore start the regression check in a clean browser context. I add one item, navigate to the basket, refresh, change quantity and revisit a product. I inspect the session transition without copying cookie values or customer data into the report.
Keep the response boundary clear
WooCommerce’s cache guidance distinguishes customer-specific pages and session cookies from ordinary shared content. I verify that a successful add is not stored as a reusable public page and that later requests recover the correct basket.
For the customer-facing side of the check, my companion note covers testing the whole first-add journey. The server needs to preserve the basket, and the interface needs to make the result clear.