Pages are not cached

If Cache Contents remains at zero or the same URL never produces a verified hit, find the first failed condition in this sequence.

1. Use an eligible test request

Start with an ordinary published page and request it twice from a private browser window.

The request should:

• use GET or HEAD;
• have no request body;
• use the site's canonical host and permalink;
• have no preview or Customizer parameter;
• contain no meaningful query string;
• contain no WordPress login, WooCommerce session/cart, password, or comment-author bypass cookie;
• ask for HTML, not a JSON-like media type.

POM Cache removes only configured tracking-only parameters. Any other query parameter keeps the HTML request dynamic. Do not classify a parameter as tracking data unless it can never alter the public response.

2. Confirm WordPress prerequisites

Open Settings → Permalinks and make sure the site has a non-empty custom permalink structure. POM Cache reports Permalink structure error when it cannot use the required URL mapping.

Then open Settings → POM Cache → General and confirm that the static HTML cache runtime is enabled.

On multisite, verify that you are configuring and testing the same site and host.

3. Review early configuration

Open Settings → POM Cache → Advanced → WordPress configuration. All of these must be correct:

• the detected drop-in matches the POM Cache source;
• POM_CACHE_HOME has the expected path;
• WP_CACHE is defined as true.

General → Cache tools → Configuration → Fix Configuration repairs the generated POM Cache settings files, but it does not modify the drop-in or wp-config.php. Follow advanced-cache.php is not loaded for manual changes.

4. Make sure the route is appropriate

POM Cache rejects HTML caching for:

• WordPress administration and internal PHP routes;
• REST requests;
• feeds, sitemaps, and robots responses;
• redirects;
• previews and Customizer requests;
• JSON-like Accept headers;
• unknown page contexts by default;
• 404 responses by default;
• requests where DONOTCACHEPAGE is defined;
• responses following a fatal PHP error.

Use a normal successful singular page for the first test. Once that works, diagnose special routes separately.

5. Check the completed response

The response must be non-empty and contain a recognized completion marker. Normal HTML should reach its closing document tag. A PHP fatal, interrupted render, or early exit can display partial content in a browser but still be correctly rejected for caching.

Inspect:

• HTTP status;
• Content-Type;
• complete response body;
• PHP and web-server logs;
• unexpected redirects;
• plugins or theme code that defines DONOTCACHEPAGE.

6. Check storage

Refresh Settings → POM Cache → General after the first request. If the HTML count remains unchanged:

• confirm the configured cache location exists or can be created;
• verify that PHP can write there;
• check filesystem space and inodes;
• check that path filters have not made the early and WordPress phases disagree.

Do not fix permissions by making the cache tree globally writable. Use the ownership and permissions recommended by your hosting environment.

7. Prove reuse

After generation, request the identical URL again. A PHP-served hit can show:

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

An Apache direct hit will not necessarily have that header. See Verify a cache hit.

If files are generated but never reused, inspect the request's cookies, host, path, direct-server rule, and cache-location mapping. If the origin hits correctly but the public hostname does not, diagnose the CDN separately.