Content remains stale

Stale content means that at least one layer still holds an older representation. Determine which layer before clearing anything.

Identify the affected representation

Record the exact URL and decide whether the old value appears in:

• the initial HTML;
• a progressive JSON request loaded after the page;
• both;
• only the CDN/public hostname;
• only one browser or session.

Use the browser Network panel to inspect the request that actually contains the old value. Do not assume that visible archive content came from the initial HTML.

Compare source and origin

1. Confirm that WordPress itself contains the intended published value.
2. Request the origin without a CDN, using a private window.
3. Compare an anonymous response with an authenticated response that bypasses shared caching.
4. Inspect HTML and JSON response headers.

If the authenticated origin is current but the anonymous origin is stale, the POM Cache artifact or direct Apache path is the likely layer. If both are stale, investigate the source, template, database, or application integration before the cache.

Clear the correct origin store

Use:

• Delete Cache under Cache tools for HTML only;
• Delete Progressive JSON Cache for JSON only;
• the admin-bar Delete Cache shortcut for both current-site stores.

Then request the affected route once to regenerate it and again to verify reuse. On multisite, confirm that you cleared the intended site's cache.

If a normal edit should have cleared it automatically, review the corresponding post, term, translation, or settings purge switch. A manual clear restores freshness but does not repair missing invalidation.

Check old and new paths

Slug, permalink, locale, host, and cache-key changes can leave a file under the previous path. Verify both URLs:

• the old URL should redirect, disappear, or show its intended current response;
• the new URL should generate a new artifact;
• copied Apache rules must map each route correctly.

For progressive JSON, a key-format change can leave obsolete locale, post-type, pagination, or filter directories until the current-site JSON store is cleared.

Correct the edge only after the origin

If the origin is current but CloudFront is stale:

1. identify the exact viewer URL and cache-key variants;
2. submit the required invalidation;
3. wait for completion;
4. request with the same host, path, and query;
5. inspect edge status and age headers.

Clearing POM Cache does not notify CloudFront. See CloudFront still serves old content.

Exclude the browser

Test in a new private session with the browser cache disabled. Service workers, application storage, and client-side state can also render old data. If only one browser is stale while origin and edge are current, clear that client layer rather than repeatedly purging the server.

Repair the invalidation contract

After locating the layer, reproduce a harmless change:

1. warm the relevant route;
2. edit the source;
3. observe which origin store is removed;
4. regenerate and verify;
5. invalidate the edge if required.

Document the event that owns invalidation. Custom database updates, imports, or external synchronizers must call the public POM Cache helpers at their logical commit point.