Inicio - Documentación - POM Cache - 04 Apache and web server - Verify that Apache serves cached pages

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

  1. Bypass or invalidate the CDN using the deployment’s approved origin-testing route.
  2. Open POM Cache → General → Cache tools.
  3. select Delete Cache for the current site.
  4. In a clean private browser, request a simple published trailing-slash URL once.
  5. 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:

  1. keep the canonical page cached;
  2. request the clean URL and record the origin behavior;
  3. request the same URL with a recognized tracking-only parameter;
  4. 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:

  1. confirm the exact index.html exists;
  2. compare its host and path with SERVER_NAME and the requested URI;
  3. confirm the URL has the expected trailing slash;
  4. confirm the query string is empty;
  5. inspect bypass cookies;
  6. verify mod_rewrite and AllowOverride FileInfo;
  7. confirm the block precedes the WordPress rewrite;
  8. 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.