Is this different from checkout not working?

Yes. A cart that won't update happens before checkout even starts — quantities, totals or the mini-cart icon stay wrong while the customer is still shopping. Checkout failures happen at the final payment step. They can share a root cause, most often page caching, but they are different symptoms and a fix for one does not automatically fix the other.

Will clearing my browser cache fix a stuck cart for customers too?

It only fixes it for you, in your own browser. If customers are seeing the same problem, the cause is server-side — page or object caching not excluding the cart, or a broken cart fragments request — and needs a server-side fix, not something each visitor can clear on their own.

Why does the mini-cart in the header lag behind the actual cart page?

The header mini-cart and the full cart page update through slightly different mechanisms — the mini-cart typically relies on WooCommerce's cart fragments AJAX call, while the cart page itself reloads its content directly. If only the header count is wrong, the fragments request is the specific thing to check first.

Can a stock or inventory plugin cause this?

Yes, if it hooks into the same cart update process WooCommerce uses. A plugin recalculating stock, applying custom pricing rules, or adjusting quantities on the fly can interfere with or slow down the same AJAX call the cart depends on to refresh correctly.

Is a stuck cart actually costing sales?

Very likely, yes. A customer who updates a quantity and sees no change, or sees a total that doesn't match what they added, tends to assume the store is broken and leaves rather than troubleshooting it themselves. This is exactly the kind of quiet, low-visibility bug that erodes conversion without ever showing up as an obvious error.

Do I need to rebuild my cart page to fix this?

Almost never. This is a caching or plugin-conflict problem in the overwhelming majority of cases, not a template or design issue. Rebuilding the page is rarely the right first move — isolating the actual cause usually is faster and leaves the existing design untouched.

WooCommerce Cart Not Updating (Stuck Quantities or Totals)

What is the problem?

WooCommerce's cart is designed to update without a full page reload — changing a quantity, removing an item, or applying a coupon fires an AJAX request in the background that refreshes the totals and the header mini-cart in place. When that update fails silently, the customer sees stale numbers: an old quantity, an old total, or a mini-cart icon that still shows what was in the cart five minutes ago, even though the underlying cart data on the server may actually be correct.

Quick answer: this is caching in the large majority of cases — specifically, a page or object cache serving a stale, cached version of the cart or a cached copy of the AJAX response instead of a fresh one. Confirm the cart and checkout pages are fully excluded from caching before looking anywhere else.

The key diagnostic question is whether this happens for you alone or for real customers too. If it clears in an incognito window but persists for actual visitors, the cause is server-side caching or a plugin conflict, not your own browser.

Common symptoms

Changing item quantity on the cart page doesn't update the line total or the cart subtotal without a manual page refresh
The header mini-cart icon shows an item count that doesn't match what's actually in the cart
Removing an item leaves it visually in the cart until the page is reloaded, even though it's genuinely gone from the order
Applying or removing a coupon code doesn't recalculate the total shown, though the discount may still apply correctly at checkout
The problem is inconsistent — it works for you as an admin but is reported by multiple customers, or the reverse
It started right after installing a caching plugin, a new theme, or a plugin that touches pricing or stock

Why does this happen?

WooCommerce relies on a mechanism called cart fragments — small, reusable pieces of HTML (the mini-cart, the cart count) that get refreshed via an AJAX call every time the cart changes, so the rest of the page doesn't need to reload. If a page-caching plugin caches that AJAX response the same way it caches a normal page, every visitor gets served the same stale fragment regardless of what's actually in their individual cart. Object caching can cause a related but distinct version of this, where the cart session data itself is cached longer than it should be.

Plugin conflicts are the second most common cause: any plugin that hooks into cart totals, stock levels, or custom pricing logic can interfere with the same update cycle WooCommerce's own AJAX call depends on, either slowing it down past a timeout or overwriting part of the response before it reaches the browser.

Common technical causes

Page caching not excluding cart, checkout and account pages — these must always be excluded from full-page caching since their content is different per visitor and per session
The cart fragments AJAX endpoint itself being cached, either by an aggressive caching plugin or a CDN caching POST/AJAX responses it shouldn't
A plugin hooking into woocommerce_cart_updated or pricing filters that fails silently, breaking the fragment refresh partway through
JavaScript errors from an unrelated plugin or theme script preventing WooCommerce's own cart-update JavaScript from running at all
Session or cookie problems, particularly on multi-domain, staging, or recently migrated setups where session cookies aren't scoped correctly
A minification plugin combining or altering WooCommerce's own JavaScript, breaking the specific script responsible for the AJAX cart refresh

How to diagnose it

Run the free WooCommerce Store Health Checker for an instant read on caching configuration and plugin bloat that commonly causes exactly this.
Test in a private/incognito window with an empty cart. If the problem still happens there, it's affecting every visitor, not just cached sessions in your own browser.
Open DevTools' Network tab, filter for requests to admin-ajax.php, and change a quantity. Check whether the request actually fires, what it returns, and whether it's being served from a cache (look for cache-related response headers).
Confirm your caching plugin's exclusion list explicitly includes the cart, checkout and my-account pages, not just relies on WooCommerce's own default exclusions, which some caching plugins don't automatically respect.
Deactivate all non-WooCommerce plugins on staging and retest, reactivating one at a time to isolate a specific conflict if the caching exclusions were already correct.

How to fix it, step by step

Explicitly exclude the cart, checkout and my-account pages from your caching plugin's page cache, and separately confirm any CDN in front of the site isn't caching admin-ajax.php requests.
Clear both page cache and object cache after changing exclusions, then retest in a private window with an empty cart.
If a specific plugin was isolated as the conflict, check for an update first — many cart-fragment conflicts get patched quickly once reported. If no fix is available, look for a lighter alternative plugin covering the same feature.
Check for JavaScript console errors on the cart page specifically, and resolve any script conflicts blocking WooCommerce's own add-to-cart.js or cart-fragments script from running.
If a minification setting was combining WooCommerce's scripts incorrectly, exclude WooCommerce's own JS files from that setting rather than disabling minification sitewide.
Test the full flow again as a genuine customer would — add an item, change quantity, apply a coupon, remove an item — not just a single isolated action, since some conflicts only show up across a sequence of cart changes.

When this needs professional help

Checking and adjusting your caching plugin's exclusion list is realistic to do yourself. It's worth bringing in a developer when:

The cart fragments request looks correct in DevTools but the totals still don't update, pointing to a deeper theme or plugin conflict
You need to isolate a conflicting plugin on a live store without risking downtime during business hours
The issue is intermittent and hard to reproduce reliably, which usually means it's load- or session-related rather than a simple, consistent conflict
You've confirmed caching exclusions are correct and the problem persists

How I can help

A stuck WooCommerce cart is one of the quieter revenue leaks I get called in for, precisely because it doesn't throw an obvious error — it just makes the store feel untrustworthy at the exact moment someone is deciding whether to buy. I check the AJAX request and response directly, confirm caching exclusions are genuinely correct rather than assumed, and isolate any plugin conflict without breaking the rest of the checkout flow.

WooCommerce Cart Stuck or Not Updating? Here's the Actual Cause.