What matters first: The product was added, but the session used by checkout does not contain the same cart. The break is usually cookie scope, full-page caching, object-cache inconsistency or a domain/scheme change.
Prove where the cart session disappears
Refreshing settings can mask the issue briefly, but the browser cookies and server session key show whether the customer changed identity between cart and checkout.
Cookies, host and redirect evidence to capture
- Record the cart and checkout URLs, host, scheme and redirect chain.
- Inspect WooCommerce session and cart cookies before and after the transition.
- Test logged out with page/CDN cache bypassed.
- Check object-cache, load-balanced nodes and database session storage.
Cache and session-layer failure modes
- Cached cart or checkout: A shared cached response ignores the visitor’s private cart.
- Cookie domain mismatch: The cart belongs to www, non-www, HTTP or another subdomain.
- Object-cache inconsistency: Different nodes or prefixes return different session state.
- Aggressive cookie rules: Consent or optimisation code removes WooCommerce cookies.
Restore one canonical checkout path
- Exclude cart, checkout, account and WooCommerce AJAX routes from full-page caching.
- Align canonical domain and HTTPS redirects to one stable host.
- Verify shared session storage and cache prefixes across every web node.
- Repeat product-to-checkout journeys in clean desktop and mobile sessions.
Cached response or cookie-domain mismatch?
A cached checkout and a cookie-domain mismatch can both present as an empty cart, but they leave different traces. If the browser keeps the same WooCommerce session cookie while the response ignores it, inspect page/CDN caching and shared session storage. If the cookie changes or disappears across www, non-www, HTTP/HTTPS or a subdomain redirect, fix host and cookie scope first.
Follow the customer journey, not an isolated page. If the request fails before the item enters the cart, start with Add to cart diagnostics. If the cart survives checkout but the final confirmation fails after payment, move to the order-received endpoint. This keeps session faults separate from later payment and rendering failures.
Avoid the all-cache-off workaround
Do not disable every cache layer permanently. Identify which layer caches private state and keep safe caching elsewhere.
Test the repaired session journey
- A logged-out cart persists through cart, checkout and payment selection.
- Cookies remain scoped to the canonical host and secure scheme.
- Separate visitors never receive each other’s cart state.
The repair is proven when a logged-out cart survives cart, checkout and payment selection on the canonical host, separate visitors never share private cart state, and the relevant WooCommerce cookies remain stable across the full journey.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Refreshing settings can mask the issue briefly, but the browser cookies and server session key show whether the customer changed identity between cart and checkout.
- 1
Record the cart and checkout URLs, host, scheme and redirect chain.
- 2
Inspect WooCommerce session and cart cookies before and after the transition.
- 3
Test logged out with page/CDN cache bypassed.
- 4
Check object-cache, load-balanced nodes and database session storage.
What must be verified
- A logged-out cart persists through cart, checkout and payment selection.
- Cookies remain scoped to the canonical host and secure scheme.
- Separate visitors never receive each other’s cart state.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If refreshing WooCommerce settings temporarily fixes an empty cart, is the issue resolved?+
No, refreshing settings can mask the symptom briefly without addressing the cause. The real test is comparing browser cookies and the server session key between the cart and checkout steps to see whether the customer's identity actually changed between the two.
Does switching from www to non-www (or HTTP to HTTPS) really explain a lost cart?+
Yes. WooCommerce cart and session cookies are scoped to a specific host and scheme, so if the cart page and checkout page are served from different domains, subdomains or protocols, the cart cookie set on one won't be visible on the other, effectively emptying the cart.
Should full-page caching be disabled site-wide to fix this?+
No, this is flagged as the wrong fix. Disabling every cache layer permanently is unnecessary; instead identify which specific layer is caching private cart or checkout state and exclude only cart, checkout, account and WooCommerce AJAX routes from full-page caching, keeping safe caching everywhere else.
Could a cookie-consent or optimization plugin be the actual cause rather than caching?+
Yes. Aggressive cookie rules from consent-management or optimization tools can remove WooCommerce's own session and cart cookies, producing the same symptom as a caching or domain problem, which is why it is listed as one of the distinct root causes to check separately.