Help and troubleshooting

Diagnose POM Cache by following the response from its source to the browser:

WordPress content → POM Cache HTML or JSON → PHP/Apache origin → CDN → browser

Prove each layer before moving to the next. Clearing every layer at once may make the symptom disappear, but it also removes the evidence needed to find the cause.

Choose the symptom

Generation or WordPress configuration

• Pages are not cached: an anonymous route never creates or reuses HTML.
• advanced-cache.php is not loaded: the drop-in or wp-config.php status needs manual work.
• Progressive JSON does not update: a progressive archive is missing, dynamic, or stale.

Delivery layers

• Apache rules do not match: PHP caching works but direct static delivery does not.
• CloudFront still serves old content: the origin is current but the edge is not.
• WebP is not served: the optional same-folder image rewrite keeps returning the original image.

Freshness, privacy, and capacity

• Content remains stale: locate the stale copy across HTML, JSON, origin, edge, and browser.
• Check for logged-in content leakage: emergency containment and evidence collection for suspected shared private output.
• The cache grows too large: investigate variants, invalidation, old paths, and disk capacity.

Asking for help

• Prepare safe support information: collect useful evidence without sharing keys, cookies, private bodies, or credentials.

First five checks

Before changing configuration:

1. Confirm the exact site, hostname, public URL, and affected representation.
2. Test the origin in a private browser window with a clean GET request.
3. Open Settings → POM Cache → Advanced → WordPress configuration and review every status row.
4. Compare Cache Contents and Progressive JSON Cache Contents before and after the request.
5. Inspect response status, content type, cache headers, CDN headers, and cookies.

If private content may have been shared, stop normal diagnosis and follow the leakage guide immediately.

Do not use these as generic fixes

• Do not enable 404 caching to make an error URL produce a file.
• Do not mark meaningful query parameters as tracking data.
• Do not weaken cookie or Accept checks.
• Do not recursively delete an unverified cache root.
• Do not edit advanced-cache.php, wp-config.php, or .htaccess without a backup.
• Do not invalidate the CDN before confirming that the origin holds the correct response.

After resolving a fault, repeat the anonymous hit, authenticated bypass, content-change invalidation, and CDN tests. A working cache must be fast, current, and safe.