Production cache checklist

Complete this review on staging or during a controlled launch window. A successful cache hit on one page is only the beginning; production approval must cover content safety, invalidation, multisite scope, progressive JSON, and the CDN boundary.

1. Configuration ownership

• [ ] wp-config.php, .htaccess, and wp-content/advanced-cache.php have current rollback copies.
• [ ] The team knows who is responsible for updating the drop-in and rewrite rules.
• [ ] No second page-cache plugin owns advanced-cache.php.
• [ ] POM Cache is active on the intended installation and network-active where multisite deployment requires it.
• [ ] The site or network license shows a valid status and the correct domain.
• [ ] Custom permalinks are active.

2. Environment status

Open POM Cache → Advanced and confirm:

• [ ] Drop-in shows OK.
• [ ] POM_CACHE_HOME shows OK and points to the deployed plugin directory.
• [ ] WP_CACHE shows OK.
• [ ] Cache Location is the intended persistent base.
• [ ] PHP can write the directory and Apache can read it.
• [ ] The HTML rewrite block appears before the standard WordPress rules.
• [ ] Host and path behavior has been reviewed for every domain-mapping pattern in use.
• [ ] Every origin node sees a consistent cache and invalidation state.

3. Decide the HTML invalidation policy

For Purge HTML on post changes, record whether the scope is Entire site, Edited post single only, or Disabled, and why. Record the enabled or disabled state of Purge HTML on term changes separately.

• [ ] Publishing, updating, trashing, and restoring representative public content produces the intended result.
• [ ] Editing a taxonomy term refreshes every affected public view when term purging is enabled.
• [ ] When automatic purging is disabled, editors have a documented manual-purge step.
• [ ] A current-site purge does not unexpectedly remove another subsite’s cache.
• [ ] A network-wide layout or shared-content change has a deliberate per-site or programmatic purge plan.

POM Cache does not expire files by age, so an undefined invalidation policy is a production blocker.

4. Test a route matrix

Use private and authenticated browser sessions. For each public cacheable route, confirm the first request creates a file and a later request reuses it.

• [ ] Home/front page.
• [ ] A standard page.
• [ ] A single public post or custom content item.
• [ ] A post-type archive.
• [ ] A taxonomy archive.
• [ ] A paginated archive.
• [ ] A mapped-domain or subdirectory subsite route.

Then confirm bypass or non-cache behavior where appropriate:

• [ ] WordPress administration and previews.
• [ ] Logged-in editorial view.
• [ ] Password-protected content.
• [ ] Search, feed, REST, redirect, and normal 404 behavior.
• [ ] URLs with functional query parameters.
• [ ] POST, PUT, and DELETE requests never receive a shared static page from PHP, Apache, or the CDN.
• [ ] Account, cart, checkout, membership, or other personalized routes.
• [ ] WooCommerce with an active session or non-empty cart.

Inspect the actual content as well as the hit indicator. A fast response is not acceptable if it belongs to another visitor, site, language, or host.

5. Decide whether progressive JSON is needed

If the site does not use compatible progressive archives:

• [ ] Progressive JSON cache remains disabled.
• [ ] No JSON rewrite rule has been added unnecessarily.

If it is required:

• [ ] The master switch and JSON writes are enabled intentionally.
• [ ] PHP early static serving and WordPress read fallback match the delivery design.
• [ ] Maximum JSON file size accepts real responses without allowing unreasonable files.
• [ ] JSON Cache-Control header matches the CDN freshness policy.
• [ ] Post, term, and translation purge switches match the content model.
• [ ] A first JSON response writes a file and a later request reuses it.
• [ ] Delete Progressive JSON Cache leaves HTML intact.
• [ ] The admin-bar Delete Cache action removes both layers for the current site.

6. Verify CDN and compression separately

• [ ] Origin behavior was proven before enabling or trusting the edge cache.
• [ ] CDN cache keys preserve the host, path, language, and query distinctions required by the site.
• [ ] Private cookies and responses are not shared at the edge.
• [ ] An origin purge is paired with edge invalidation where needed.
• [ ] Brotli or Gzip is supplied by the CDN/web server without duplicate compression.
• [ ] Cache-Control, Vary, content type, and status codes are correct for HTML and JSON.
• [ ] Existing same-folder WebP rewrites fall back to the original image when no alternative exists.

7. Rehearse rollback

The rollback order should be known before launch:

1. invalidate or bypass the CDN;
2. remove or disable the POM Cache Apache rewrite blocks;
3. delete current-site HTML and JSON files;
4. disable the corresponding POM Cache runtime switches;
5. restore the previous drop-in or server files only when the rollback plan requires it.

• [ ] The rollback was rehearsed without deleting unrelated files.
• [ ] The team understands that plugin deactivation alone can leave existing files reachable through Apache rules.
• [ ] A known uncached route remains available for comparison.

8. Record the launch baseline

Keep non-sensitive evidence for:

• [ ] plugin, WordPress, and PHP versions;
• [ ] enabled POM Cache switches;
• [ ] representative dynamic and cached response times;
• [ ] HTML and JSON file counts and sizes;
• [ ] response headers at origin and CDN;
• [ ] the last successful purge and regeneration test.

Do not record the license key, private account data, server credentials, or unredacted cookies.

The site is ready when every intentional cache route is reusable, every private route remains private, and editors can predict how a content change becomes visible.