Skip to content
Rescue 404
Rescue

WooCommerce Errors

WooCommerce Cart Is Empty After Adding Product (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

If Add to cart appears to work but the cart page stays empty, WooCommerce usually lost the session cookie, a cache served a stale empty cart, HTTPS/www mismatches split cookies across hosts, or the add-to-cart AJAX never persisted the item. Confirm cookies and cart/checkout cache exclusions first, then conflict-test — do not rebuild the theme until sessions stick for a guest in a private window.

This is WordPress Repair for a store that looks fine until money is on the line: the button responds, then Cart says it is empty. That pattern is almost always sessions, cookies, caching, or URL mismatches — not missing products. This guide separates “add never saved” from “add saved but cart page shows a cached empty state” so you fix the layer that dropped the basket instead of toggling unrelated plugins during a sale.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WooCommerce sets a `wp_woocommerce_session_` cookie (about two days) with a unique code so it can find that customer’s cart data in the database. (WooCommerce cookies)
  • WooCommerce caching guidance lists `woocommerce_cart_hash`, `woocommerce_items_in_cart`, and `wp_woocommerce_session_` among cookies to respect when configuring caches. (Configuring caching plugins for WooCommerce)
  • WooCommerce documents that payment gateways and customer trust expect HTTPS, and that WordPress/Site URLs should use the `https://` prefix after SSL is installed. (SSL, HTTPS, and WooCommerce)
  • Official conflict-testing docs recommend isolating theme and plugin conflicts with a default theme and minimal active plugins when storefront behavior breaks. (How to test for conflicts)

What the error means

WooCommerce keeps guest carts in a server-side session keyed by cookies such as `wp_woocommerce_session_…`, plus helpers like `woocommerce_items_in_cart` and `woocommerce_cart_hash`. Add to cart writes the session; the cart page (and mini-cart fragments) read it back. If cookies cannot be set (blocked, SameSite/HTTPS issues, http vs https, www vs bare domain), each request looks like a new shopper with an empty cart. Separately, full-page cache or a CDN that caches `/cart/` can show an empty cart HTML shell even when the session in the database already has items — which feels identical to customers. Performance plugins that delay cart-fragment AJAX make the empty state linger longer, but the root is still session identity or cache policy.

Common symptoms

  • Add to cart shows a success notice or spinner, but Cart / View cart lists zero items
  • Mini-cart count briefly increments then resets to empty on the next page
  • Works while logged into wp-admin but fails for guests, mobile, or private windows
  • Works on one hostname (www) and empties on another (bare domain) or http vs https
  • Cart fills correctly with caching plugins disabled or in a browser with cookies allowed
  • Browser Application/Storage shows missing or constantly rotating `wp_woocommerce_session_` cookies
  • Network tab shows a successful `wc-ajax=add_to_cart` (or form POST) yet the cart page HTML is still empty

Most likely causes

  1. 01 Full-page cache, host cache, or CDN caching cart, checkout, or my-account HTML for guests
  2. 02 WordPress Address / Site Address mismatch (www, HTTPS, or subdirectory) splitting session cookies
  3. 03 Browser or privacy tools blocking cookies; Secure/SameSite mismatch on non-HTTPS or mixed sites
  4. 04 Security or bot rules stripping cookies or blocking WooCommerce AJAX that updates the session
  5. 05 Aggressive “performance” settings delaying or breaking cart fragments and session cookies
  6. 06 Object/database cache incorrectly caching `_wc_session_` data across customers
  7. 07 Multiple overlapping add-to-cart or AJAX cart plugins fighting over the same session

What changed before the problem started

  • Caching, Cloudflare, or a performance plugin was installed or tightened
  • SSL was added, Force HTTPS changed, or the site URL switched between www and non-www
  • Security / bot fight rules started affecting storefront cookies or AJAX
  • Theme or page-builder cart/mini-cart template was updated
  • PHP, WooCommerce, or session-related mu-plugins changed around the same time

Troubleshooting steps

  1. 01

    Reproduce as a guest and note where the cart dies

    In a private window, add a simple product, then open Cart immediately. Note whether the success message appears, whether the mini-cart count changes, and whether only the cart page is empty. Screenshot before changing plugins.

  2. 02

    Confirm Site URL and WordPress URL match how you shop

    Under Settings → General, WordPress Address and Site Address should match the exact scheme and host customers use (`https` and www or non-www — pick one). A mismatch is a classic cause of “added but cart empty” because cookies are set for the wrong host.

  3. 03

    Exclude cart, checkout, and account from full-page cache

    In every caching plugin, host panel, and CDN, ensure Cart, Checkout, and My Account are never page-cached. Purge all layers, then retest as a guest. Many “empty cart” tickets are simply a cached empty cart page.

  4. 04

    Verify WooCommerce session cookies are set after add-to-cart

    In DevTools → Application → Cookies, confirm a `wp_woocommerce_session_` cookie appears after adding a product. If it never appears, fix HTTPS/cookies/security rules before editing theme templates.

  5. 05

    Inspect Network for add-to-cart vs cart page responses

    Watch `/?wc-ajax=add_to_cart` or the product form POST for a successful response, then load `/cart/`. If add succeeds but cart HTML is empty and cache headers show HIT, the cache layer is still serving a stale empty cart.

  6. 06

    Conflict-test caching and optimization plugins on staging

    Prefer staging. Disable page cache / optimize plugins first (not every business plugin), retest guest add-to-cart, then re-enable with cart/checkout exclusions and without deferring jQuery or WooCommerce cart scripts.

When to stop troubleshooting

Hand off if empty-cart reports continue after verified cache exclusions and matching HTTPS URLs, if session cookies are stripped by a host/CDN layer you cannot configure, if object cache corrupts sessions across customers, or if the store is mid-promotion and you cannot safely conflict-test. Provide guest repro steps, cookie screenshots, cache headers on `/cart/`, and a list of caching/security plugins.

Information to collect before requesting help

  • 01 Whether the failure is guest-only or also affects logged-in customers
  • 02 Exact site URL customers use vs Settings → General URLs
  • 03 Caching/CDN/performance plugins and whether cart/checkout are excluded
  • 04 Screenshot of cookies after add-to-cart (session cookie present or missing)
  • 05 Network result of add-to-cart AJAX/POST and cache HIT/MISS on the cart page
  • 06 Theme name and any AJAX cart / mini-cart plugins
  • 07 Recent SSL, www, or cache configuration changes
  • 08 WooCommerce and WordPress versions

How a professional repairs the problem

A technician proves whether the session never saves or the cart page is a cached empty shell, aligns site URLs and HTTPS, enforces cart/checkout cache exclusions across plugin/host/CDN, restores session cookies past WAF/optimize rules, and only then touches theme cart templates. They retest as a guest on mobile and desktop before calling the storefront healthy.

Frequently asked questions

Why does the cart work for me but not for customers? +
You are often logged in (different cookies) or viewing a purged cache. Guests hit full-page cache and cookie rules you never see while administering the site — always retest in a private window logged out.
Is this the same as Add to cart not working? +
Related but not identical. A dead button never starts the add; an empty cart after a success message usually means the add ran but the session or cart page display failed. Fix sessions/cache before rewriting the button.
Can a caching plugin really empty the cart? +
It can display an empty cart even when the session has items, if `/cart/` was cached for anonymous users. WooCommerce expects cart and checkout to stay dynamic.
Do I need to disable all plugins? +
Start with cache, CDN, and script-optimization layers. Only widen the conflict test if sessions still will not stick after cart pages are uncached and URLs match.
Could HTTPS cause this right after installing SSL? +
Yes. If product pages still land on `http://` or the opposite host from cart, browsers will not share the session cookie. Make WordPress/Site URLs and redirects consistently `https://` on one hostname.
Will clearing WooCommerce transients delete orders? +
No. Clearing customer sessions/transients can empty active guest carts, but it does not delete completed orders. Take a backup first if you use any bulk session-clean tools on production.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.