Enable caching and verify your first cached page

This test proves four separate facts: WordPress can generate an HTML cache file, POM Cache can find it again, an anonymous request can reuse it, and an authenticated request still bypasses it.

Use a simple published page with no account, cart, password, or visitor-specific output.

Establish the baseline

1. Open Settings → POM Cache → Advanced → WordPress configuration. On multisite, use Network Admin → Settings → POM Cache → Advanced when testing the network/main-site configuration.
2. Confirm Drop-in, POM_CACHE_HOME, and WP_CACHE all show OK.
3. Confirm the site uses a custom permalink structure.
4. Remain in General and leave Progressive JSON cache unchanged; this test concerns HTML only.
5. Under Runtime, select Disabled for Caching and save if it is not already disabled.
6. Under Cache tools, select Delete Cache.
7. Open the test URL in a private browser window with no query string.
8. Confirm the page is correct before caching.

The private window matters because WordPress login, password, comment-author, or WooCommerce session cookies can intentionally bypass static delivery.

Generate the first file

1. Return to General → Runtime.
2. Change Caching to Enabled.
3. Save the settings.
4. In the private window, request the test URL once.
5. Wait for the complete page to load.
6. Return to General → Cache tools and refresh the settings page.

Cache Contents should now report at least one cached page. The first request normally runs WordPress and writes the index.html file at the end of the response.

The first response is the dynamic response that generated the file. POM Cache keeps that visitor response separate from its stored buffer, so this first response is not required to contain the cache comment.

Prove reuse

1. Request the same URL a second time in the same private window.

2. View the second response’s source.

3. Locate a comment similar to:

   <!-- Cached page generated by POM-Cache on 2026-07-27 12:34:56 -->

4. Record its timestamp.

5. Request the URL a third time.

6. View the source again and confirm that the timestamp is unchanged.

The actual timestamp will differ. Its appearance on a later request proves that the stored file was served, and an unchanged timestamp proves that it was reused rather than generated again.

If PHP served the hit, the response headers also contain:

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

Direct Apache delivery skips PHP and does not need to add that header. For the Apache path, the unchanged cache comment and cache-file status are the portable evidence.

If a CDN sits in front of the site, verify the origin first through the deployment’s approved origin-testing method. An edge hit can otherwise make an origin problem look successful.

Verify the private bypass

1. Open the same page in a browser where you are logged in to WordPress.
2. Reload it without carrying over the private window’s cookies.
3. Confirm the public cached response is not served as a shared static hit.
4. If the page has editor-only controls or personalized content, confirm they remain correct.

Do not expect the anonymous cache count to decrease. The file can remain available for safe visitors while the authenticated request bypasses it.

Rebuild the page deliberately

1. Return to General → Cache tools.
2. Select Delete Cache.
3. Confirm the HTML cache count returns to zero for the current site.
4. Request the public test URL once to generate a replacement file.
5. Request it a second time.
6. Confirm the cached response contains a new cache comment with a later timestamp.

This completes the generation, hit, bypass, purge, and regeneration cycle.

If no file is generated

Check the following in order:

1. Caching is enabled for the intended site.
2. The request is an anonymous GET or HEAD.
3. The URL has no non-tracking query parameters.
4. The browser has no WordPress, password, comment-author, or WooCommerce bypass cookie.
5. The response is normal HTML and finishes with a complete HTML document.
6. The response is not a REST response, feed, redirect, preview, backend route, or normal 404.
7. PHP can write below Cache Location.
8. The cache path resolves inside the configured cache directory.

If the file exists but is not reused

• Recheck the deployed Apache rule and its position before the WordPress block.
• Confirm the hostname and multisite path match the stored file.
• Confirm advanced-cache.php is the expected POM Cache drop-in.
• Test without the CDN.
• Check whether the request carries a bypass cookie or query string.
• Do not remove safety conditions just to make the test pass.

After this controlled test succeeds, use the Production cache checklist for representative routes and invalidation.