A customer signs in to check an order. The page loads quickly—but the greeting, cart, or account details belong to someone else. That is not an acceptable trade-off for a faster website.

Caching saves a copy of content so a website does not have to rebuild everything for every visit. It is useful for public information. Problems arise when a shared cache treats customer-specific information as something everyone should receive. The goal is not to switch caching off everywhere. It is to draw a reliable boundary between public pages and private responses.

Start with the pages that know who the customer is

Ask your website team to list the places where content changes according to the visitor. Start with account details, order history, saved addresses, carts, checkout, invoices, private downloads, and customer-specific quotes or pricing.

Do not stop at the pages in your navigation. An account dashboard may load private information from a separate data request. A public product page may include a personalized greeting or negotiated price. Those responses need the same review as the visible page.

For WooCommerce, the official caching configuration guidance identifies Cart, Checkout, and My Account as pages that need to remain dynamic. Check your actual page assignments and customized URLs rather than assuming the default paths cover every private feature.

Check every layer, not just the WordPress plugin

A store can have a caching plugin, hosting-level page cache, and a content delivery network (CDN) at the same time. A correct plugin setting does not prove that the hosting or CDN configuration is also correct.

• Page and edge caches: Confirm that private pages and customer-specific data responses bypass shared caching.
• Sessions: Verify that the cache respects the platform’s customer-session and login signals. A guest with items in a cart has a session too.
• Custom features: Review quote tools, membership areas, invoice viewers, and B2B pricing separately from standard store pages.
• Rule overrides: Ask whether any broad “cache everything” rule overrides application instructions or newer exclusions.
• Responsibility: Record who manages each layer and who can correct and purge it when necessary.

Managed commerce platforms may control parts of this for you. Focus your review on the settings, apps, storefront customizations, and external services your team actually controls.

Know what the technical instructions mean

Your developer may discuss the Cache-Control response header. Two distinctions matter: private tells shared caches not to store a response, while still permitting browser caching; no-store tells caches not to store it. Despite its name, no-cache can allow storage, but requires validation before reuse. MDN’s Cache-Control reference explains these differences.

Have the developer select and verify the appropriate policy for each sensitive response. Headers are not a substitute for access controls: the application must still check that the signed-in customer is allowed to view the requested order, invoice, or file. Likewise, hiding a page from search engines does not make it private.

Run a two-customer check with synthetic data

Use an authorized test environment and two test customers with clearly different, invented names, addresses, and carts. Never use real customer records to demonstrate a suspected exposure. A staging pass is useful, but production may use different CDN or hosting rules, so arrange a controlled production check with the site owner as well.

1. Use two separate browser profiles or devices so the customers do not share cookies. Two private windows in the same browser may share one private session.
2. Sign in as test customer A and visit the account, cart, and other private areas in scope. Repeat a visit so the test is not limited to an empty cache.
3. Visit the same areas as test customer B. Confirm that names, addresses, order information, prices, and cart contents belong only to B.
4. Check the signed-out experience in a separate clean session. Private pages should require the intended authorization and should not display another customer’s information.
5. Ask the developer to inspect the associated data responses and cache behavior, not just screenshots. Keep browser developer tools’ “disable cache” option off for this representative check.

This is a focused smoke test, not proof that every privacy or authorization issue is absent. Repeat it after changing caching rules, hosting, account features, or the storefront theme.

If another customer’s information appears, stop testing

Do not browse additional records to see how widespread it is. Notify the responsible technical and privacy contacts, record the affected URL and time without copying unnecessary personal information, and restrict the affected feature if appropriate. The team should preserve relevant evidence, correct the caching or authorization problem, purge affected cached copies, and retest before restoring normal access.

A purge alone is not a fix: an incorrect rule can store the next private response again. Have the incident owner assess the scope and any notification obligations. Our guide to who can pause checkout during a security incident can help establish that decision-making responsibility before it is needed.

A small Phase 1 with a clear finish line

Start with account, cart, checkout, and your most sensitive custom feature. Request a short record of the relevant URLs and data endpoints, the cache layers checked, the synthetic test results, and the person responsible for future changes. Keep public pages fast while treating private information differently.

Nexus Box can help review these boundaries as part of ecommerce maintenance or a focused website improvement project. The useful outcome is simple: customers get their own information, the store remains responsive, and the team has a repeatable check—not another complicated system to manage.

Featured photo: Sadi Hockmuller via Pexels, used under the Pexels License. Illustrative stock photography.