Your Add-to-Cart Button Works, but the Cart Stays Empty—How to Fix It
The button animates, a confirmation flashes, and the shopper assumes the item was added. Then the cart opens with a zero. This failure is expensive because the interface reports success while the commerce system records nothing.
I diagnose this by following the item from the product page to the cart service, not by changing random design settings. The quickest fix depends on where the handoff breaks: product configuration, the browser request, the cart response, session storage, or the cart interface.
Start with the symptom, not the platform
Before changing code, reproduce the problem on the published store and write down the smallest pattern that explains it. A useful test takes one product, one selected variant, one browser, and one clean session.
One product fails, but others work: inspect that product’s required options, variant availability, inventory, purchase limits, and custom fields.
Every product fails for everyone: suspect a theme or site-code error, a broken app integration, a platform incident, or a failed cart endpoint.
The cart count rises and immediately returns to zero: inspect the session cookie, domain changes, redirects, and cached cart responses.
A private window works: compare cookies, local storage, extensions, consent choices, and cached JavaScript.
Desktop works but mobile fails: look for an invisible overlay, double-tap behavior, a cart drawer that opens off-screen, or a mobile-only script error.
The item is added but disappears after navigation: the add request may succeed while the next page loses the session.
Do not clear every cache before collecting evidence. That can hide the condition you need to understand. Capture the failing product URL, variant, device, browser, time, consent choice, and a short screen recording first.
A ten-minute diagnostic that separates UI bugs from cart bugs
1. Confirm the product can actually be purchased
Select every required option before clicking. Test an in-stock simple product with no personalization, subscription, bundle, or minimum-quantity rule. If that product works, add complexity back one condition at a time.
A common configuration failure looks like a button problem: the page displays a default image and price, but no valid variant ID is selected. The visual layer can react to the click even though the commerce request has nothing purchasable to send.
2. Watch what the browser sends
Open developer tools, choose the Network panel, preserve the log, and click Add to Cart once. Filter for cart, line item, checkout, or fetch/XHR requests. You are looking for four facts: did a request leave, what product or variant identifier did it carry, what status came back, and did the response contain the expected line item?
No request: the click handler did not run, another element intercepted it, or JavaScript failed earlier.
A 4xx response: the request is invalid, unauthorized, blocked by policy, or refers to an unavailable item.
A 5xx response: the commerce service, customization, or integration failed server-side.
A successful response with no cart update: the bug is likely in session persistence or the cart drawer/page rendering.
Also inspect the Console for the first error, not the twentieth. Later errors are often consequences of the first missing object, blocked script, or incompatible customization.
3. Verify the cart session survives
Shopping carts commonly depend on browser state. MDN explains that cookies are used for session management, including cart contents, and that Domain, Path, Secure, and SameSite attributes control when those cookies are sent. If the product page and cart use different hosts, protocols, or embedded contexts, a cookie can be set but not returned where the cart expects it.
In the browser’s Application or Storage panel, compare the cart/session cookie before and after the click. Check whether it appears, changes, and remains present after opening the cart. Then test the exact path customers use: landing page, product page, cart, and checkout.
Force one canonical HTTPS hostname so shoppers do not bounce between www and non-www sessions.
Remove redirect chains between product and cart pages.
Do not classify essential cart storage as optional analytics storage in a consent tool.
If the cart is embedded or crosses domains, review SameSite and Secure behavior with the platform or integration owner.
Test with privacy extensions disabled, but do not tell customers to disable protections as the permanent fix.
4. Isolate theme, app, and custom-code conflicts
Cart failures often begin after a theme edit, app installation, optimization change, or consent-banner update. Test from a copy or staging environment where possible. Disable one variable at a time and keep a written result.
For Shopify, follow the platform’s theme troubleshooting process: reproduce the issue, compare another theme, and identify whether the problem belongs to the theme, an app, or store configuration. Pay special attention to cart drawers, app blocks, accelerated buttons, bundle apps, and custom product forms.
For WooCommerce, first confirm that its cart cookies are present as documented in WooCommerce’s cookie reference. Then use a staging copy, switch temporarily to a standard compatible theme, and deactivate nonessential plugins in controlled groups. Re-enable them one by one until the failing request returns. Review WooCommerce status logs and browser errors at the same time.
For Wix Stores, test the published site rather than only Preview. Confirm that the product is visible and in stock, all required choices are selectable, and the store pages are connected. Temporarily remove recent custom code, third-party widgets, or overlapping elements from a duplicate page, then publish and retest. If a clean product page works, compare its elements and code with the failing page.
5. Treat cache as a suspect only when the evidence points there
A stale script can call an old cart function after the storefront has been updated. Purge the site or CDN cache after deployment, make sure versioned assets change URLs, and exclude dynamic cart endpoints and fragments from full-page caching. Test the response headers and the actual script URL rather than repeatedly refreshing.
If different visitors see different versions, use the layer-by-layer process in Webcurry’s website cache diagnosis. If the failure is isolated to Safari, compare it with the Chrome-versus-Safari troubleshooting guide.
6. Check consent and security tools without weakening protection
A consent manager should not block code required to create and preserve a cart. A web application firewall should not challenge normal cart requests. Review blocked requests, Content Security Policy reports, bot rules, and script order. Fix the classification or allow the precise required endpoint; do not broadly disable the security layer.
This matters for international stores because a banner can behave differently by region. Test at least one US session and each market with materially different consent rules, currency, language, or domain routing.
Platform-specific recovery checklist
Wix Stores
Publish recent store and product-page changes, then test the live URL.
Use a simple in-stock product to rule out variant and custom-field configuration.
Check for custom code, lightboxes, sticky bars, or overlays intercepting the button.
Compare a clean product page with the failing design and restore components incrementally.
Retest cart persistence across the site’s preferred domain and checkout path.
Shopify
Duplicate the current theme before editing.
Test the same product in an unmodified or known-good theme preview.
Disable recent app embeds and cart-drawer customizations one at a time.
Confirm that the product form submits the selected variant and selling-plan data correctly.
Retest the cart page even if only the drawer appears broken; this distinguishes stored cart data from presentation.
WooCommerce
Back up the site and reproduce the problem on staging.
Review WooCommerce status, fatal-error logs, and the browser console.
Exclude cart, checkout, and account pages from page caching.
Run a controlled theme/plugin conflict test.
Verify that the WooCommerce session and cart cookies persist through navigation.
Do not let analytics report a sale path that never existed
A front-end click is not proof that an item entered the cart. Fire an add-to-cart analytics event only after the commerce platform confirms the line item, and include a non-personal product identifier, quantity, value, and currency where appropriate. Then compare analytics events with server-side cart or checkout records.
If traffic reports cannot connect shoppers to confirmed leads or transactions, use the GA4 lead-attribution repair guide. For wider friction beyond the cart, the website conversion audit helps separate traffic quality, message clarity, speed, and interaction problems.
A safe order for deploying the fix
Preserve evidence from the failing session.
Reproduce the issue with the simplest product and a clean browser.
Identify whether the request, response, session, or interface is wrong.
Apply the smallest fix on a duplicate theme or staging site.
Test guest and signed-in users on desktop and mobile, including a US location and other priority markets.
Verify the cart after navigation, quantity changes, discounts, login, and the first checkout step.
Confirm analytics only records successful cart additions.
Deploy, monitor errors and abandoned checkouts, and keep a rollback point.
The key is to stop treating “Add to Cart” as one button. It is a chain: product state, click handler, request, response, browser session, cart rendering, and checkout handoff. Test each link once, in order, and the empty cart becomes a diagnosable failure instead of a mysterious conversion drop.
If the problem crosses theme code, caching, consent, and analytics, ask Webcurry for a focused ecommerce website review. Bring one failing product URL, a screen recording, and the browser/network evidence; that is usually enough to start at the right layer.
Comments