When an item appears in the mini-cart but vanishes after navigating, WooCommerce is either losing the customer’s session or showing two different representations of it. The mini-cart may be updated in JavaScript while the next page loads stale HTML, or the next request may genuinely create a new session.
Keep one failing browser session intact. Clearing cookies first removes the evidence needed to tell those cases apart.
Mark a controlled cart journey
Use one simple in-stock product and record the URLs visited from product to cart, another content page and checkout. Note whether the cart count, cart page and checkout agree at each step.
Test from a new private window as well as the affected browser. Compare mobile and desktop only after establishing a repeatable transition.
Do not use a real customer account or publish session identifiers in screenshots.
Distinguish stale display from lost state
Open the cart page directly after the mini-cart looks empty. If the product remains in the actual cart, the defect is likely fragment refresh, cached markup or theme JavaScript.
Inspect the browser Network panel for WooCommerce cart-fragment or Store API requests. A failed or cached response may leave the header count wrong even though the server session is healthy.
Record for each page:
visible cart count
server cart page contents
response cache status
WooCommerce session-cookie presenceThis prevents a cosmetic mini-cart problem being treated as database loss.
Follow the session cookie
Inspect wp_woocommerce_session_* and the cart hash/items cookies across requests. Confirm their domain, path, Secure flag and expiry remain consistent.
Navigation between www and non-www, HTTP and HTTPS, or a separate shop subdomain can leave the cookie behind. Choose one canonical host and correct links and redirects at their source.
Do not copy cookie values into logs; they can identify an active customer session.
Check server-side session writes
WooCommerce guest sessions are stored in the database. Look for database errors or failed writes at the add-to-cart timestamp. A read-only database node, full disk, locked table or inconsistent object cache can make the next request load older state.
If the site uses Redis or another persistent object cache, verify all web nodes share the intended configuration and cache groups. Bypassing one node temporarily may help prove a cluster inconsistency, but it is not the final repair.
Do not truncate the session table during diagnosis.
Inspect page and fragment caching
Product and content pages may be cached, but personalised cart fragments must be refreshed correctly. Cart, Checkout and My account require explicit bypass rules at the host, WordPress and edge layers.
Read response headers instead of relying on a cache plugin’s dashboard. A page served from Cloudflare or a host cache can remain cached even when the WordPress plugin says it is excluded.
After correcting rules, test twice: once cold and again after public cache is populated.
Review add-to-cart customisation
AJAX add-to-cart scripts, product bundles and quantity extensions can update the browser before the server confirms the change. Inspect the add request response and any PHP error at the same time.
Custom code should not call WC()->cart->empty_cart() outside a narrow, intentional flow. Search site-owned plugins and the child theme for cart reset hooks, especially those tied to login, currency or language changes.
Repair the broken handoff
Standardise the host and HTTPS scheme, correct cookie scope, repair database/object-cache consistency or fix the fragment/custom-code path proven by evidence. Clear only relevant caches and preserve unrelated carts.
Test add, remove, quantity change, back/forward navigation, login transition and checkout. Confirm the same cart survives each page and that another private browser receives a separate session.
Recurring care should monitor session-write errors and run a cart-persistence journey after cache, domain and WooCommerce updates. Cart continuity is a transaction prerequisite, not a cosmetic feature.