WooCommerce cart empty after adding product

The add step and the cart step are two separate requests. WooCommerce stores the cart on the server and gives each browser a session cookie, named wp_woocommerce_session plus a code. The add step saves the item under that session. If the cookie is missing, blocked, or set on a different address from the one the cart loads from, the cart reads as new and empty. If a cache answers the cart page for a visitor with no session, it shows an empty cart although the item is stored. If a script on the product page fails, the add request never reaches the server and nothing is stored.

• After you add an item, look for a cookie starting with wp_woocommerce_session in the storage panel for your domain.
• Open the cart page's response headers and look for a cache header, such as x-cache or cf-cache-status, that says HIT.
• Look for an add-to-cart request, usually with wc-ajax=add_to_cart or add-to-cart= in its address, and a success response.
• Read the console on the product page for script errors that appear at the moment you click Add to cart.
• Confirm the store answers on one address only, so the cookie is not set on www and read on the bare domain.

The shopper opens a product page and clicks Add to cart. The button might change to View cart, a notice might appear above the product, or the header count might go up. Then the shopper opens the cart from the header icon or a link in the notice. The cart says it is empty, or shows nothing, and the header count reads zero. Some shoppers click once more, then try checkout, which also reports an empty cart, and leave. Your server logs usually show no error. The cart simply did not get the item back on the next request.

A missing cookie, a cached cart page and a click script that never ran all end with an empty cart, so the symptom alone cannot tell them apart. A cookie problem shows in the browser's storage panel: after you add an item there is no wp_woocommerce_session cookie for your domain, or the cookie sits on www while the cart loads from the bare address. A cache problem shows in the cart page's response headers, where a cache reports HIT, and the cart looks empty while the item is stored. A script problem shows in the console when you click, or as no add-to-cart request in the network panel. Check them in that order.

A consent banner is a common reason the cookie is missing. Many banners block non-essential cookies until the visitor accepts, and a shopper who declines may never get a session. The banner often appears on the product page itself, so the first click may happen before the shopper has answered it. Test the cart once with the banner accepted and once declined, in a private window each time.

A simulated test sends visitors to the product page, has each one click Add to cart, and then has them open the cart. Each visitor works in a real browser, so the report shows the step where the cart went empty, a screenshot of that step, and the script errors and failed or slow requests recorded there. That tells you where the flow broke and what the browser saw. It does not say which cause is behind it, and a test browser does not carry your shoppers' cookie settings. Use the report to pick the step, then the checks above to pick the cause.

If the cart only empties after login, the test needs an account to sign in with. With paid credits, visitors can sign in with a test account you give them. A checkout test goes up to the payment step and stops there, because visitors cannot pay with a real card. Check the payment itself in your payment provider's test mode, with its published test card numbers.

A cart break comes back. A cache rule changes, a plugin updates, or a new consent banner blocks the session cookie. After each change, run the same visitors through Add to cart and the cart before the next ad campaign sends traffic. The second run shows whether the step that broke now works.