Why Does Caching Break WooCommerce Subscriptions Pages?
Why This Happens
Full-page caching works by serving an identical, pre-rendered copy of a page to every visitor, which is exactly wrong for a page whose content depends on who's logged in. WooCommerce's own guidance, and most caching plugins built with WooCommerce in mind, automatically exclude cart, checkout, and My Account — but that exclusion depends on the caching layer correctly recognizing those specific URLs, which isn't guaranteed for every hosting setup, CDN configuration, or customized page URL.
Common Causes
- A CDN or server-level cache configured independently of the WordPress caching plugin, not aware of WooCommerce's page-exclusion rules at all — a common gap when caching is layered (WordPress plugin plus a separate CDN) without coordinating the exclusion rules between them.
- A custom My Account page URL that doesn't match what the caching plugin expects to exclude by default, if the page was moved or renamed from WooCommerce's standard setup.
- Object caching (Redis/Memcached) misconfigured to cache user-specific session data across requests, a different and rarer issue from full-page caching but with a similarly confusing symptom.
- A logged-out visitor's cached version of a page bleeding into a logged-in view if the cache doesn't correctly vary its cached copy based on login state.
How to Fix It
- Confirm cart, checkout, and My Account are explicitly excluded in every caching layer involved — the WordPress plugin and any separate CDN or server-level cache, not just one of them.
- Test as two different logged-in customers (two different browsers or private windows) loading My Account back to back, checking for any cross-contamination of content.
- If the My Account page URL was customized, confirm the caching exclusion rules were updated to match, rather than still referencing the default URL.
- Treat any confirmed instance of one customer's data appearing to another as urgent — this is a real data-exposure issue, not just a display bug, and needs immediate investigation and a fix, not just a cache-clear.
See caching & CDN setup for a WooCommerce-aware caching configuration done correctly, or WooCommerce fixes if this has already caused a real data-exposure incident.