Verify that Apache serves cached pages
Apache delivery does not use the POM Cache PHP hit header, so verification needs a controlled origin test. Absence of X-POM-Cache alone proves nothing: the response could be Apache, WordPress, or a CDN.
Prepare one known file
- Bypass or invalidate the CDN using the deployment’s approved origin-testing route.
- Open POM Cache → General → Cache tools.
- select Delete Cache for the current site.
- In a clean private browser, request a simple published trailing-slash URL once.
- Confirm Cache Contents reports the generated file.
The first request is the WordPress render. POM Cache adds generation comments to the stored copy, not to that original response buffer.
Observe the repeat request
Request the identical URL again without cookies or a query string. View its source and find:
<!-- Page generated in 0.123 seconds. -->
<!-- Cached page generated by POM-Cache on 2026-07-27 12:34:56 -->
<!-- pom cache -->
The numbers above are examples. Record the timestamp and request the page again. It should remain unchanged until the file is regenerated.
Now inspect the headers:
- an early PHP hit has
X-POM-Cache: Served static cache from PHP; phase=early; - a direct Apache hit does not add that PHP header;
- a CDN may add its own edge-cache evidence and must be excluded from this origin test.
Use Apache access or tracing facilities available to the site owner to confirm that the request maps to wp-content/cache/pom-cache/.../index.html and does not reach the PHP handler. A fast response or missing PHP header is not sufficient evidence by itself.
Compare a PHP-only route
Recognized tracking parameters provide a useful contrast when the edge is bypassed:
- keep the canonical page cached;
- request the clean URL and record the origin behavior;
- request the same URL with a recognized tracking-only parameter;
- confirm the content and stored generation timestamp are unchanged.
The supplied Apache HTML rule requires an empty query string, so the tracking request should fall through. The PHP runtime can normalize the known tracking parameter and may return the same file with phase=early.
Do not use a content-changing parameter for this comparison. It should remain dynamic.
Test non-matches
The test is incomplete until Apache declines unsafe requests:
| Variation | Expected result |
|---|---|
No corresponding index.html |
Fall through to WordPress |
| Logged-in cookie | No direct public-file delivery |
| Post-password cookie | Bypass |
| WooCommerce session/cart cookie | Bypass |
| Meaningful query string | Fall through |
POST, PUT, or DELETE |
Never receive static HTML |
| Non-canonical or malformed path | Redirect or fall through according to site policy |
| Another mapped site | Use that site’s own branch |
Check the response body as well as its status. A 200 with another visitor’s page is a failed test.
Verify HEAD
Send a HEAD request to the cached URL. A correct read path returns headers for the same resource without a body. Confirm the effective server policy allows this safe method without broadening access to state-changing methods.
If Apache does not serve
Work from the file outward:
- confirm the exact
index.htmlexists; - compare its host and path with
SERVER_NAMEand the requested URI; - confirm the URL has the expected trailing slash;
- confirm the query string is empty;
- inspect bypass cookies;
- verify
mod_rewriteandAllowOverride FileInfo; - confirm the block precedes the WordPress rewrite;
- check whether a proxy changed the host or document root.
Do not remove cookie, method, or path checks to make a benchmark pass. Use Apache rules do not match for further diagnosis.