POM Cache diagnostic checklist

Use this checklist after installation, a deployment, a permalink change, or a report that caching has stopped. Follow the order: configuration first, generation second, delivery third, and invalidation last.

1. Confirm the test context

• [ ] You are administering the intended site and host.
• [ ] The public test uses a private window or a clean client.
• [ ] The request is GET or HEAD.
• [ ] The URL has no preview, Customizer, or meaningful query parameter.
• [ ] The request does not contain login, cart, password, comment-author, or other bypass cookies.
• [ ] You know whether the symptom concerns HTML, progressive JSON, Apache, a CDN, or WebP.

2. Check WordPress prerequisites

• [ ] WordPress uses a non-empty custom permalink structure.
• [ ] The relevant HTML or progressive JSON master switch is enabled.
• [ ] The requested route is public and appropriate for shared caching.
• [ ] The response is not an administration, REST, robots, feed, sitemap, redirect, or JSON-like request when testing HTML.
• [ ] A 404 is not being used as the main test unless 404 caching was intentionally enabled by code.

3. Review the early configuration

Open Settings → POM Cache → Advanced → WordPress configuration.

• [ ] Drop-in is marked OK and matches the plugin-provided source.
• [ ] POM_CACHE_HOME has the expected value.
• [ ] WP_CACHE is defined as true.
• [ ] If generated settings files were suspect, General → Cache tools → Configuration → Fix Configuration completed successfully.

Remember that Fix Configuration does not repair the drop-in or wp-config.php.

4. Prove generation

• [ ] You cleared only the relevant current-site store.
• [ ] The first anonymous request returned a successful, complete response.
• [ ] The HTML response contains a recognized completion marker, such as the closing HTML document tag.
• [ ] The JSON response is valid, non-empty, within the configured size limit, and marked cacheable by its producer.
• [ ] The cache location is writable and has sufficient disk space.
• [ ] Refreshing the settings screen shows the expected HTML or JSON file count.

5. Prove reuse

• [ ] A second identical origin request returns the same public representation.
• [ ] PHP hit headers appear when PHP performs the read.
• [ ] If Apache serves directly, server-level evidence proves the static-file path.
• [ ] A logged-in or personalized request is still handled safely.

See Verify a cache hit for the header values and limitations.

6. Check Apache and CDN layers

• [ ] Copied Apache rules match the actual document root, host, cache location, and route shape.
• [ ] Rules appear before the normal WordPress rewrite block.
• [ ] Direct rules require the expected method, clean query, safe cookies, and existing file.
• [ ] The origin is correct before any CDN invalidation.
• [ ] CDN cache keys and compression negotiation preserve the required variants.

7. Check freshness

• [ ] The appropriate automatic purge switch is enabled for the content change being tested.
• [ ] Editing a public item removes the expected current-site store.
• [ ] The next request regenerates the updated representation.
• [ ] Progressive JSON and HTML are cleared independently when only one changed.
• [ ] A CDN invalidation covers the exact public objects after origin correction.

Preserve useful evidence

Before repeatedly clearing caches, save:

• the exact sanitized URL and reproduction steps;
• relevant response headers and status;
• HTML and JSON counters;
• the WordPress configuration status;
• whether the origin and CDN differ;
• product, WordPress, PHP, and web-server versions.

Never share license keys, cookies, authorization headers, private response bodies, credentials, or unnecessary absolute server paths. If the checklist identifies a specific symptom, continue with the matching guide in Help and troubleshooting.