WordPress cache layers: page cache, object cache, CDN and browser cache

Map the request path first

Document whether traffic passes through a CDN, proxy cache, web server, WordPress page-cache plugin, PHP-FPM, object cache, and database. Determine which layer answers a cached page before adjusting TTLs.

Use response headers and cache-plugin diagnostics to confirm cache hits and misses.

Keep personalized and write paths out of shared page cache

Cart, checkout, account, admin, previews, form endpoints, REST writes, and pages varying by authentication/cookies usually need bypass rules. WooCommerce and membership plugins may publish recommended exclusions.

Never cache responses containing user-specific data across visitors.

Define invalidation for content changes

Publishing/editing posts, changing menus/widgets, updating products, or purging plugin state should invalidate the right URLs. A long TTL without purge logic can keep errors visible even after the origin is fixed.

Avoid global purge storms if targeted invalidation is supported.

Measure origin performance too

A fast cache hit can hide an origin that takes seconds on every miss. Test both warm and bypassed requests, then tune PHP/database/application work so cache failure or expiry does not become an outage.

• Map every cache layer.
• Bypass personalized paths.
• Test invalidation.
• Benchmark cache hit and origin miss.