Verify the actual cart separately from its badge. A display-update failure and an incorrectly shared cart response require different fixes.
Reproduce with isolated visitor sessions
Use two test browser profiles on staging. In the first, add a product and note the badge, mini-cart and full cart contents. Keep the second empty. Repeat after navigation and a normal reload. This shows whether the badge fails to update locally or whether customer-specific content is leaking between responses. Do not test with genuine customer accounts or saved payment data.
Identify the cart component in use
Find whether the theme uses a block-based cart component, a classic fragment integration or a custom mini-cart. Their update paths differ. Inspect Network and Console during add-to-cart to see which request and script owns the refresh. Avoid copying a fragment-specific exclusion into a block-based implementation without confirming that it applies.
Compare the response with the display
If the update response contains the correct count but the badge stays old, inspect component initialization, event handling and JavaScript errors. If the response itself is wrong, investigate session cookies, endpoint caching and exclusions. If a reload corrects the badge, that is a clue about the update path, not proof that the full cart is safe to cache.
Test a targeted optimization exception
On staging, restore the required cart-update dependency or exclude the specific dynamic response according to the component and provider documentation. Change one layer at a time. Blanket disabling all optimization hides the responsible interaction and removes useful benefits from unrelated pages. Also verify that the public header is not embedding another visitor’s personalized count in shared HTML.
Check the complete cart journey
Add two different products, change quantity, remove an item and navigate back to a public page. Repeat in the empty second profile. Confirm the full cart and header remain consistent, including after consent changes if scripts are gated. Restore the earlier configuration if session isolation fails. Keep a record of the cart implementation and exact failing update path.
Symptom-to-cause worksheet
| What you observe | What to investigate | Next check |
|---|---|---|
| Full cart correct, badge old | Client update failure | Inspect update response and console |
| Badge fixes after reload | Update event or dependency problem | Trace add-to-cart refresh |
| Second session sees first cart | Personalized response reused | Stop affected shared caching rule |
Worked investigation scenario
This is an illustrative case, not a measured Velonic result. Imagine add-to-cart updates the full cart correctly but the header count remains zero. The update response contains the new count, and a console error appears in the theme’s badge component. Restore that component’s required dependency on staging before changing server cache rules. Then test removal and quantity changes plus an empty second session. The fix must keep the display synchronized without introducing customer-specific content into shared page HTML.
Put it into practice
- Identify the cart component before changing rules.
- Test badge and full cart independently.
- Verify isolation between two test sessions.
AI-assisted educational content prepared for the Velonic resource library. How these guides are prepared.