Why some requests must never be cached

A static page file has no knowledge of the next visitor. Once created, it can be delivered without PHP, user lookup, capability checks, or application logic. POM Cache therefore treats shared-cache safety as a requirement, not a performance preference.

The question every cache key must answer

Two requests may share one file only when every difference that can change the response is either:

• represented in the file path; or
• proven irrelevant to the public HTML.

POM Cache keys static pages by host and normalized URL path. It does not create separate page files for user IDs, roles, cart contents, passwords, devices, or arbitrary query values.

If any of those contexts changes the document, the request must bypass.

Private identity and permissions

WordPress login cookies signal that the response may contain:

• an admin bar;
• edit links;
• private or draft content;
• role-specific navigation;
• account details;
• personalized recommendations.

Serving that output from a public file could disclose information or show the wrong controls. Authenticated requests are excluded from early static delivery and cache generation.

Passwords, comments, and commerce state

POM Cache also treats the following cookie families as bypass signals:

• post-password cookies;
• comment-author cookies;
• WooCommerce session cookies;
• WooCommerce cart hash and item-count cookies.

The cookie value is not added to a filename. The whole request remains dynamic. This design avoids an unbounded collection of private variants and prevents one visitor’s state from becoming another visitor’s page.

Cart, checkout, account, and similarly stateful routes should remain protected at every upstream layer too. A CDN or custom Apache rule that ignores the bypass contract can reintroduce risk before POM Cache runs.

Country pricing and universal HTML

POM Tweaks Country pricing zones can share one product or catalog page across countries only while its complete universal HTML safety check is good. POM Cache stores that result per site so the early cache layer can make the same decision before WordPress loads. Only an anonymous public GET or HEAD request that is otherwise eligible for shared HTML may promote this stored state to safe. Administration, authenticated, REST, AJAX, cron, and WP-CLI requests can place the integration in a conservative pending state, but cannot certify the public proxy path.

When the check is good, cached product pages contain neutral loading markup rather than a visitor's regional amount. Prices, sale state, purchase actions, variations, and compatible POM Faceted Search results resolve through private requests after load. Country is deliberately not added to the page-cache key.

When the check is unavailable or reports any incompatibility, POM Cache neither serves nor generates shared HTML. This fail-closed state applies to the complete current-site page cache because product cards can appear outside conventional shop URLs.

During a migration from WooCommerce Price Based on Country, the same fail-closed rule applies while either legacy pricing plugin is active and while the new pricing rollout remains in cache-bypass mode. A successful technical check does not override an unfinished commercial rollout. POM Cache purges the site's static HTML and updates its early-serving sentinel whenever the approved rollout state changes.

Request state and representations

A path is not always the complete meaning of a request.

• ?s=coffee changes a page into search results.
• a preview parameter can expose unpublished changes;
• REST and linked-data Accept headers ask for a different representation;
• POST, PUT, and DELETE can change data;
• the Customizer uses request state that must not become public HTML.

POM Cache declines these cases rather than guessing whether they happen to look harmless on one visit.

Tracking-only parameters are a narrow exception in the PHP path. Recognized campaign identifiers can be removed so that they share the canonical public page. If any meaningful query value remains, the request bypasses.

Invalid output must not become a durable page

Request eligibility is only the first gate. After rendering, POM Cache rejects responses that indicate an unsafe or incomplete result, including:

• fatal PHP termination;
• DONOTCACHEPAGE;
• redirects tracked during the WordPress response;
• REST, feed, sitemap, or robots output;
• ordinary 404 pages;
• non-HTML content negotiation;
• empty output or a document without a recognized closing marker.

The current visitor still receives WordPress’s response. The rejection only prevents that response from being preserved for later visitors.

Safety extends beyond POM Cache

The full delivery chain must agree:

CDN policy
    ↓
web-server rewrite conditions
    ↓
POM Cache early checks
    ↓
WordPress final-response checks

A safer application check cannot undo an unsafe edge hit that happened before it. Review cookie, method, query-string, host, and route rules whenever the CDN or web-server configuration changes.

Test the boundary before production

Build a small matrix using the same public URL:

Check that the returned content is correct, not merely that the status is 200.

If an integration has a genuinely public exception, document the invariant and use the developer eligibility controls. Do not make a global rule broader just to improve a benchmark.