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.
What this symptom actually tells you
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.
Capture evidence before changing anything
- 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.
Most common causes
- 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.
Safe diagnostic and repair sequence
- 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.
How to choose between the likely causes
Do not treat Cached cart or checkout and Cookie domain mismatch as interchangeable. A shared cached response ignores the visitor’s private cart. By contrast, the cart belongs to www, non-www, HTTP or another subdomain. Use two checks to separate them: Record the cart and checkout URLs, host, scheme and redirect chain; and inspect WooCommerce session and cart cookies before and after the transition. Those observations usually show whether the next safe move is to exclude cart, checkout, account and WooCommerce AJAX routes from full-page caching or to preserve the current state and widen the investigation.
On a live store, reproduce the issue with a controlled test order and follow the same payment, stock, tax and notification path used by customers. Avoid changing several checkout components at once because that changes the application state and can obscure the original sequence of events needed to attribute the failure. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not disable every cache layer permanently. Identify which layer caches private state and keep safe caching elsewhere.
How to verify the repair
- 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.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.