Verify a cache hit

A fast response is not proof of a POM Cache hit. The browser, a CDN, Apache, PHP, or another cache can each return a response quickly. Verify the delivery layer and the content together.

Prepare a controlled request

Choose a public URL that is expected to be cacheable. Then:

1. Open a private browser window or use a client with no WordPress cookies.
2. Use GET or HEAD.
3. Remove preview, Customizer, and non-tracking query parameters.
4. Request the URL once to allow generation.
5. Request the identical scheme, host, path, and query again.

Keep the browser's Disable cache option enabled while testing if you want to exclude the browser's own HTTP cache. That option does not disable the site's origin or CDN cache.

Identify a PHP-served HTML hit

Inspect the response headers in the browser's Network panel. An early PHP HTML hit reports:

X-POM-Cache: Served static cache from PHP; phase=early

This means the POM Cache drop-in found and served the static HTML file before a normal WordPress render.

Identify a PHP-served JSON hit

An early progressive JSON hit reports:

X-POM-Cache: Served static JSON cache from PHP; phase=early

When POM Theme obtains a progressive archive payload through its WordPress fallback, a cached result can instead report:

X-POM-Progressive-Archive-Cache: hit

Dynamic generation can report generated-cacheable or generated-dynamic. These values describe the fallback path and should not be confused with the earlier drop-in response.

Understand Apache direct delivery

Optional Apache rules can serve a file before PHP executes. In that case, PHP cannot add an X-POM-Cache header. Absence of the header therefore means “not proven by this header,” not necessarily “cache miss.”

To verify direct delivery:

• first prove that PHP delivery works with the direct rule disabled;
• enable the copied rule and request the same safe anonymous URL;
• inspect web-server access logs or tracing that distinguishes a static file from PHP;
• confirm that the correct cached file exists and that the rule's host, path, query, method, and cookie conditions match;
• compare an origin response without the CDN.

Do not add a permanent diagnostic header in a way that weakens or bypasses the rule's safety conditions.

Separate the CDN

A CDN hit proves only that the edge reused an object. It does not prove that POM Cache served the original response. Record CDN-specific status and age headers supported by your provider, then repeat against the origin.

The useful chain of evidence is:

1. source content is current;
2. an eligible origin request generates the intended artifact;
3. a second origin request reuses it safely;
4. the CDN receives and caches that correct origin representation.

Confirm safety, not just speed

Repeat the URL while logged in and while using a session that could show personalized content. The response must not reuse another visitor's private state. Also check a cart or password-protected flow when the site provides one.

Finally, edit a harmless public value, run the expected invalidation, and verify that the following request shows the update. A cache is healthy only when both hits and freshness work.