WooCommerce Cart Showing the Wrong Items? Check These Cache Settings

If one shopper appears to see another shopper's cart items, stop testing with real customer accounts or personal data. A stale cart can be a display problem, but repeatable cross-session cart contents can indicate that a shared cache is serving shopper-specific responses.

Reproduce the symptom safely with two new private browsing sessions and a simple test product. Label them Shopper A and Shopper B. Keep the test controlled: do not submit checkout, place an order, or use live customer information.

A full-page cache is designed to reuse a response across visitors. A WooCommerce cart is designed to be private to one shopper. Those goals conflict when a cache stores personalized cart HTML or cart JSON and later serves it to a different session.

WooCommerce uses session cookies for classic cart flows. Cart and Checkout Blocks use the Store API, where a Cart-Token can identify a cart for headless or token-based requests. If an intermediate layer ignores those boundaries, strips Set-Cookie, or caches a personalized Store API response under a shared key, shoppers can receive stale or incorrect state.

A cache HIT on a public catalog page may be expected. A shared-cache HIT on Cart, Checkout, My Account, or a personalized Store API cart response deserves investigation.

Start with the smallest standard page exclusions. WooCommerce's caching guidance says Cart, Checkout, and My Account should not be cached because they display customer-specific information.

• Cart: the assigned cart page and any localized or custom cart URL.
• Checkout: the assigned checkout page, including checkout endpoints.
• My Account: the account page and its endpoints.

Enter the real paths used by the store, not assumptions such as /cart/. Confirm assignments in WooCommerce settings and account for translated URLs, subdirectory installs, or custom slugs. Do not disable caching across the whole site unless testing proves a broader rule is necessary.

Stores using Cart and Checkout Blocks rely on WooCommerce's Store API. Bypass shared caching for the cart endpoint and its child operations under:

/wp-json/wc/store/v1/cart*

This pattern covers reading the cart and operations such as adding, updating, or removing items. If your CDN, reverse proxy, host cache, or optimization layer has a separate API-cache feature, check it independently; a page exclusion may not cover REST routes.

After changing the rule, confirm that two anonymous sessions receive independent cart state. Do not expose or paste live Cart-Token values into tickets, screenshots, or public logs.

Where your cache supports cookie-based bypass or variation, review these WooCommerce cookie patterns:

• wp_woocommerce_session_*
• woocommerce_items_in_cart
• woocommerce_cart_hash

The exact control varies by provider: some bypass when a cookie exists, some vary the cache key, and others expect WooCommerce-aware defaults. The objective is consistent—the response for a shopper with active cart state must not become a reusable public object.

Cookie rules complement route exclusions; they do not replace them. Also confirm that no proxy or performance feature removes a required Set-Cookie header.

A corrected rule does not necessarily remove objects already stored. Purge the relevant cache layers in order: WordPress cache plugin, managed-host cache, reverse proxy or CDN, and finally the test browser's stored site data.

1. Open two fresh private sessions.
2. Add the test product only in Shopper A.
3. Load the cart in Shopper B without sharing links, cookies, or tokens.
4. Repeat after a hard refresh and after navigating through a public catalog page.
5. Inspect page and Store API responses for unexpected cache hits or shared cart contents.

If the symptom remains, capture which layer produced the response and ask the cache or hosting provider to review the exact URL, headers, and timestamp. Redact session identifiers first.

CacheSafe for WooCommerce runs controlled anonymous A and B cart sessions against public store surfaces. It checks page headers, cookie behavior, Store API Cart-Token isolation, and cross-session cart evidence, then reports sanitized findings with remediation guidance.

Run Preflight first, using a simple published test product. Then run a live scan, save the check IDs that report FAIL or WARN, make the smallest cache change, purge, and scan again through the same natural request path. Compare the same findings rather than relying on a changed overall impression.

CacheSafe does not place orders, change cache settings, inspect provider dashboards, send telemetry, or issue a numeric safety score. A clean scan is bounded evidence from that run—not a guarantee that every route and future configuration is safe.

Install CacheSafe free from WordPress.org →

Watch the companion troubleshooting video →

• Use controlled anonymous sessions; never test with customer data.
• Record the URL, time, response headers, and responsible cache layer.
• Exclude Cart, Checkout, and My Account using the store's actual paths.
• Bypass shared caching for /wp-json/wc/store/v1/cart*.
• Review WooCommerce session-cookie bypass or variation rules.
• Purge WordPress, host, edge, and browser caches.
• Retest Shopper A versus Shopper B and compare the same evidence.
• If cross-session contents persist, restrict the affected cache path and escalate with redacted evidence.

Do not treat one successful refresh as closure. Verify both the classic cookie flow and Store API flow used by your storefront, then monitor after cache, CDN, theme, and WooCommerce changes.