By platform
WooCommerce cart not updating: find why
The shopper changes the quantity, and the total or the header count stays put. Simulated visitors make the same change and show which part of the cart did not refresh.
Why is my WooCommerce cart not updating when a shopper changes the quantity?
A WooCommerce cart stops updating when the change request fails, when the cart page is served from a stored copy taken before the change, or when the script that sends the change never runs on the cart page. The header count and the cart total are separate pieces, so one can refresh while the other stays the same. Check whether the change request reaches the server and what it returns, whether the cart page comes from a cache, and whether the cart script loads. A simulated visitor changes the quantity the way a shopper does and reports which of these the page shows.
What this looks like in a report
“I typed three, but the total still shows one bar and the header says one. Did the change save? I will reload to see, and if it is still wrong, I will buy from another shop.”
The fix. Exclude the cart page from page caching, then check that the quantity request returns a success response with the new totals. Change a quantity in a private window and confirm the header count and the cart total both update together, without a reload.
An illustration. Run a test to see your own.See a real sample report
The server holds the new total while the page shows the old one
Changing a quantity sends a request to the server, which recalculates the cart and returns new numbers. The page then swaps the old totals for the new ones. If the request fails, the old numbers stay on screen and nothing tells the shopper that the change was refused. If the request succeeds but the page is served from a stored copy, the shopper sees the old total while the server holds the right one. A refresh may then show the correct value, which makes the fault look random, and a shopper who does not refresh simply leaves.
- Change a quantity, then read the total. Does it change without a full page reload?
- Compare the header count with the number on the cart page after a single change.
- Open the network list and check the request sent on each change, and its status.
- Look at the cart page's response headers for a cache marker that says the page came from storage.
- Check the console for a script error that appears at the moment you change a quantity.
The change, the request and the copy on screen
A quantity change touches three things: the request that tells the server, the server's new totals, and the copy of the cart that the page shows. Each can succeed or fail on its own. A stored copy of the cart page can hold the old numbers for a shopper even though the server has moved on. A header piece that counts the items can refresh on its own schedule, so the count and the total may disagree on the same screen.
Read them in order. Did the request leave the browser, and what status came back? Did the response carry new totals? Then look at what the page displays. A request that fails with a message points at the store. A request that succeeds while the page shows old numbers points at the copy, and that difference decides where you fix it.
Why a refresh hides the fault
A refresh asks the server again, which is why the numbers suddenly look right. That makes the owner's test pass. When you test as the owner, you are usually signed in, and the caching setup may skip the stored copy that a signed-out shopper receives. The test that finds the fault is a signed-out change in a private window, followed by a look at the total without reloading the page first.
Telling the causes apart by what stays stale
If the total stays and the request returns an error, the request or the script is the fault. If the total is right after a reload but wrong straight after the change, the page copy is stale. If the header count and the cart total disagree while both are otherwise right, the header piece is refreshing on its own. Write down which one you see, because each is repaired in a different place, and fixing the wrong one changes nothing.
Mimiq is independent and not affiliated with the platforms it names. Names belong to their owners.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A header cache can show a count the cart does not match
The header count and the cart page can be cached on different schedules, so a plugin update or a new cache rule can split them again. After each update, run the same simulated shoppers through two quantity changes, and compare the header count and the cart total at each step. Protected previews need a site password in the run, which is part of paid credits. A saved run shows which step drifted first.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Will clearing my browser cache fix it for shoppers?
Only for you. Shoppers use their own browsers, and the stored copy sits on your server or in a cache service, which clearing your browser does not touch. Clear the page cache for the cart, then check a signed-out change in a private window.
Why does the total update after I refresh?
A refresh asks the server again, and the server has the right total. The page you saw before the refresh came from a stored copy or from a failed request. The gap between the two is the fault, so a refresh is a symptom, not a fix.
Does the simulated shopper see what I see?
It loads the cart the way a signed-out visitor does, so a stored copy that visitors receive can appear in the walk. It records the request, the header count and the total at each step. It does not tell you whether a shopper will complete the purchase after the change.
Is this a theme problem or a plugin problem?
The test narrows it to the request, the stored copy or the header piece. A theme can change how the cart is drawn, and a plugin can hold the request. Switch off one suspect at a time, ideally on a copy of the site, and run the same visitors after each change.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.