A customer opens an account page and sees someone else's name. The login may be working as designed. A shared cache may have saved the wrong page and sent it to the next visitor.
Caching makes faster by reusing work. But a page built for one person needs different rules from a public blog post. This guide shows how to check that boundary without turning off every speed feature.
Map the caches your site uses
Start with the browser, then the CDN, hosting cache, page-cache plugin and object cache. A CDN is a network that serves content close to visitors. An object cache stores data used by the app; it is not the same as a saved full page.
Write down who owns each layer. Two tools can both look correct in isolation while one broad rule overrides the other. A “cache everything” rule deserves close review on a store or membership site.
Our covers the performance side. Add a privacy check to the same work so speed gains do not hide a data leak.
Decide which responses must stay private
List pages that show names, orders, addresses, private downloads, account details or custom prices. Include the API calls that load this data after the page opens.
Cart, checkout and account pages often need shared-cache bypass rules. So do authenticated responses and pages that depend on a private session. Check the actual routes used by your plugins; a custom account page may have a different URL.
A public page can still load a private widget. For example, the page shell may be safe to cache while its order summary is not. Inspect the response that contains the private data, not just the address bar.
Use our to include account and checkout flows in the review.
Understand three useful cache directives
The Cache-Control header tells compatible caches how to handle a response. “Private” excludes shared caches but can allow a browser cache. “No-store” tells caches not to retain the response. “No-cache” allows storage but requires validation before reuse. It does not mean “never save this.”
These meanings and provider-specific behavior are documented in Cloudflare's cache-control guide. Check your host and CDN rules as well. A header alone is not proof of what the whole stack does.
For sensitive pages, use a deliberate policy for both browser and shared caches. Then test the response. Keep authentication checks in place: cache headers cannot decide who may view an order.
