Which pages can be cached

POM Cache is designed for complete, public WordPress HTML that can be reused for anonymous visitors. A route does not become eligible merely because it returns status 200; both the incoming request and the finished document must pass the cache checks.

Typical candidates

The normal WordPress page families recognized during rendering include:

• the static front page;
• the posts page;
• published pages and single posts;
• category, tag, author, date, post-type, and other archives;
• paginated archive paths;
• custom public post types routed through standard WordPress conditionals.

A search routed through a clean pretty-permalink path can be recognized as a WordPress page type, but a conventional search that depends on ?s=... has meaningful query state and bypasses. Evaluate whether search results are truly stable enough for the site before extending any policy around them.

Request requirements

For ordinary static HTML, the candidate should be:

• requested with GET or HEAD;
• on the canonical public hostname;
• represented by a clean URL path;
• free of authentication, password, comment-author, session, and cart bypass cookies;
• outside WordPress administration and internal PHP routes;
• unrelated to the Customizer or preview;
• requested as HTML rather than JSON or linked data.

Tracking-only parameters recognized by POM Cache can be removed in the PHP path. Any other query value means the request remains dynamic.

Response requirements

After WordPress renders, the result must:

• belong to a known frontend page type under the default policy;
• contain non-empty output;
• include a recognized document-ending marker, normally </html>;
• avoid a fatal PHP error;
• avoid a tracked redirect, REST, feed, sitemap, or robots state;
• not be an ordinary 404;
• remain permitted by DONOTCACHEPAGE;
• still have caching enabled when the write occurs.

These checks make eligibility a property of the final request, not just the URL.

Public does not always mean cacheable

A publicly reachable page may still vary by:

• geolocation;
• consent state;
• A/B test assignment;
• currency;
• membership status;
• browser-provided headers;
• a third-party session;
• live inventory or pricing.

POM Cache cannot infer every application invariant. If output varies but the difference is not part of the host-and-path key, the integration should define DONOTCACHEPAGE, set an appropriate bypass before cache delivery, or keep the route outside direct server caching.

Client-side enhancement is different: a common public HTML shell can be safe if private data is fetched after load through a properly protected API and never embedded in the static document.

POM Tweaks Country pricing zones uses this model when its universal HTML safety check is good. POM Cache then permits one host-and-path file whose WooCommerce prices, sale badges, actions, variation state, and compatible POM Faceted Search preload remain neutral. The browser resolves the current zone through non-cacheable requests. If the check is not ready or becomes unsafe, the whole current-site HTML cache bypasses until the condition is corrected.

Evaluate a new route

Before adding it to a warm-up list:

1. compare the signed-out HTML in two clean browser sessions;
2. repeat with login, password, commerce, consent, and localization states used by the site;
3. identify every query parameter and header that can change content;
4. confirm the canonical hostname and permalink;
5. generate one file and inspect it for private or session-specific markup;
6. verify the chosen post/term/manual invalidation path;
7. test the same route through Apache and the CDN, not only through WordPress.

If you cannot state why one stored document is valid for all matching anonymous requests, leave the route dynamic.

Use Which requests are excluded as the negative checklist.