Never cache a personal basket as though it were a public product page. Specifically exclude basket, checkout and account context from page caches and CDN storage, while still serving static files and public catalogue pages quickly. This prevents visitors from seeing outdated quantities or even data from another session.
“Turn off caching” for the entire store is not a good answer either. It makes safe pages unnecessarily slow and conceals which components actually depend on a session. The right approach starts with a map of routes, cookies, AJAX actions and fragments that read or write personal state.
Map the boundaries of personal content
The basket page and checkout are obvious exceptions, but there are other boundaries. Consider a basket-restoration link, a saved-baskets page in My account, dynamic quantities in the header and an endpoint that shares a selection. Even an empty HTML shell can receive personal information through a later request. Document not only URLs, but also which source determines the visible state.
| Component | Desired caching behaviour | Check |
|---|---|---|
| Public product page | Cacheable, with a carefully managed dynamic basket fragment | Price and stock rules match the source |
| Basket and checkout | No shared page cache | Sessions and users remain separate |
| My account lists | Private caching, with no shared cache | Logging out clears visible personal state |
| Sharing or restoration action | No-store for the action’s result | The back button does not show an old sensitive page |
| Static CSS and JavaScript | Long-lived caching with a file version | A new release gets a new URL |
Use several layers of protection
Send explicit cache headers with personal responses, exclude relevant paths at the hosting layer and respect cookies indicating an active basket or logged-in session. No layer is sufficient on its own. A reverse proxy may interpret application headers differently; a CDN rule may change later; a plugin may add a new path.
Pay attention to cache keys too. Using only the URL is unsafe when language, currency, customer group or session affects the response. Putting everything in the key can instead create an explosion of variations. Decide for each component: public variants may be cached in a controlled way, while personal content should arrive through a private request or remain entirely uncached. In a broader integration architecture, Yindle Connect helps keep responsibilities clear between the store and underlying systems.
Browser caching needs its own check. A no-store response prevents a sensitive restoration or checkout page from reappearing through back navigation, but may affect the user experience. Test it deliberately. For requests that change data, avoid a GET link that silently performs an action; have the link open an overview first, then replace or save only through a protected POST action. This separates sharing from the personal change.
Fictional example: a restoration link shows the wrong header
Wholesaler Kade shares project baskets with business customers. After an optimisation round, the restoration page is cached. The product lines are reloaded, but the header contains a previous visitor’s basket total. No names leak, yet trust is immediately damaged: the recipient sees an amount that does not belong to their selection.
Kade splits the page. The public explanation and styling are cacheable; basket contents, quantities and actions are retrieved from the user’s own session. The restoration response gets no-store, account paths are excluded in both hosting and application, and static assets receive a version in the filename. Two employees then test simultaneously using different browsers and incognito windows.
After each release, Kade runs a small smoke test from a cold cache. This matters: a developer with a logged-in administrator cookie often bypasses the cache and misses the problem. The test therefore runs as a guest, as a customer and through the public hostname. The route map is also checked again after changes to the CDN, cookie banner or optimisation plugin.
A practical cache-safety test
- Create two accounts with clearly different baskets.
- Alternate between opening the basket, checkout, My account and a shared restoration link.
- Repeat in a normal window, incognito and on a second device.
- Check response headers and the behaviour of the CDN or host cache.
- Use the back and forward buttons after logging in, logging out and restoring a basket.
- Test header quantities, the mini-basket, coupons, language and customer group.
- Clear only the central cache and check whether the problem returns.
- Include new personal routes in the release checklist.
Assign one owner to the route map. Performance work, checkout development and marketing plugins can all introduce new cache boundaries. For complex stores, a periodic technical review is often cheaper than investigating an unexplained session error afterwards. At custom software you can read how process and technology can be designed together.
Have Yindle check the cache boundaries of your WooCommerce flow.