WooCommerce Cart Empties at Checkout? Causes & Fix
The cart has three items, the customer clicks through to checkout, and it's suddenly empty. WooCommerce hasn't lost the order — it's lost the session, and there are only a few things that do that. Here's how to find yours.
Last updated: 16 Jul 2026 · ~7 min read
The most common cause is full-page caching serving the cart or checkout page, so the wp_woocommerce_session_ cookie is never set or never honoured and WooCommerce can't tell whose cart is whose. Exclude cart, checkout and my-account from every cache layer. Second suspect: cart runs on one hostname and checkout on another (www vs non-www, or http vs https), so the browser never sends the cookie back.
What's actually being lost
A WooCommerce cart isn't stored in the page. It's stored server-side against a session, and the browser holds a wp_woocommerce_session_ cookie that says which session is theirs. Cart contents follow that cookie. Break the cookie — don't set it, don't send it back, don't match it — and the cart looks empty even though the data is sitting in the database.
That's why this so often looks random. It works for you as an admin (you're logged in and usually bypassing the cache), and it fails for logged-out shoppers on exactly the page where you can't afford it.
The most common causes (most likely first)
- Full-page caching is serving cart or checkoutA caching plugin, host-level cache or CDN is caching pages that must never be cached. Tell: it happens to logged-out visitors but not to you as admin, and one visitor sometimes briefly sees another's cart count. Check that cart, checkout and my-account are excluded from every cache layer you run.
- The session cookie is split across hostnamesCart on
www., checkout on the bare domain — or a mix of http and https. The cookie was set on one host, so the browser won't send it to the other. Tell: the address bar changes host or protocol between cart and checkout. Check WordPress Address and Site Address underSettings → Generaland make sure they match, then redirect the other version. - Something is stripping or blocking the cookieA reverse proxy, CDN or edge cache removing Set-Cookie headers to make responses cacheable — or a cookie-consent plugin classing the session cookie as non-essential and refusing it until the visitor consents. Tell: no
wp_woocommerce_session_cookie exists in the browser at all. - The session store isn't persistingA broken or shared object cache, or a database issue, so the session data written on the cart page isn't there on the next request. Tell: the cookie is present and correct, but the cart is still empty — the browser held up its end.
- The session simply expired, or they switched deviceWooCommerce sessions don't last forever. A cart left overnight, or a link opened on a phone after building the cart on a laptop, has no session to find. Tell: only affects long gaps, and can't be reproduced in one sitting.
Where to look first
- Reproduce it in an incognito window on the live domain. If it only breaks logged-out, you're looking at a caching or cookie problem (cause 1 or 3), not a WooCommerce problem.
- Watch the address bar from cart to checkout. Does the hostname or protocol change — www to non-www, http to https? That's cause 2, and
Settings → Generalis where you fix it. - Open DevTools → Application → Cookies while the cart has items. Is there a
wp_woocommerce_session_cookie, and is it on the same host as your checkout page? Missing means cause 3; wrong host means cause 2. - Cookie present and correct but the cart is still empty? That's server-side — the session isn't persisting (cause 4). Check your object cache and your host's caching layer.
- Only happens after a long gap? That's an expired session (cause 5) and it's WooCommerce working as designed.
How would you even know this was happening?
A cart that empties at checkout doesn't raise an error, doesn't create a failed order, and doesn't email anyone — the customer just leaves. DiagnosticIQ's free dashboard watches the buying funnel and flags the steps that shut, so a session that stops surviving the trip to checkout shows up as a signal rather than as a quiet drop in orders. The Checkout Guard add-on names which step broke and why, and tells you the day it happens.
Get the free plugin →Made by Prima Digital — the team behind this guide. Free forever; no card to install.
How to know you fixed it
In a fresh incognito window on the live domain, add a product and go to checkout — the items are still there, and DevTools shows a wp_woocommerce_session_ cookie set on the same hostname as the checkout page.
Frequently asked
Am I losing sales to this?
Yes, silently. There's no error and no failed order — the customer sees an empty cart, assumes the store is broken, and leaves. It's one of the most expensive faults per hour it stays live.
Why does it work for me but not for customers?
You're logged in, and most caching layers bypass the cache for logged-in users. You're testing a different code path from the one your shoppers hit.
Will clearing the cache fix it?
Only until the pages are cached again. The fix is excluding cart, checkout and my-account from caching, so those pages are never served from cache in the first place.
Should I disable caching altogether?
No. Cache everything else — the fault is caching the three pages that carry a session, not caching as such.