Coordinate POM Cache clearing with CDN invalidation

Deleting an origin file does not send a purge request to CloudFront or another CDN. An edge can continue returning its stored response without contacting the corrected origin.

Use this order:

correct source
→ purge affected POM Cache store
→ verify origin
→ invalidate affected viewer paths
→ verify public edge

Decide what changed

Identify the smallest public scope that is actually stale:

• one page;
• an archive and its pagination;
• all pages that include a shared header/menu/footer;
• a Progressive JSON route;
• one image URL with original/WebP variants;
• a whole site after a global template change.

POM Cache’s automatic post and term purges can clear the current site’s complete HTML tree. That does not mean the CDN must always receive a distribution-wide wildcard.

Clear the correct origin store

Under POM Cache → General:

• Cache tools → Delete Cache removes current-site HTML.
• Progressive JSON tools → Delete Progressive JSON Cache removes current-site JSON.

The admin-bar Delete Cache shortcut clears both for the current site.

After the purge, request the affected origin URL through an approved edge-bypass method and confirm WordPress generates the corrected response. Do not invalidate the CDN first and let it immediately refill from a stale origin file.

Use viewer paths, not filesystem paths

A CloudFront invalidation targets the URL path seen by viewers:

/about/
/news/*
/wp-json/pom/v1/progressive-archive/archive/product/<context-hash>/page-2-ppp-12.json

It does not target:

wp-content/cache/pom-cache/example.com/about/index.html

Paths are relative to the distribution. AWS API requests require a leading slash. A wildcard must be the final character.

AWS documents path rules in What you need to know when invalidating paths.

Account for variants

CloudFront invalidates header and cookie variants associated with an invalidated file path. Query-string variants require additional care:

• if query strings are not part of the public cache key, invalidate the canonical viewer path;
• if they are forwarded and cached, include the specific query variants or use a final wildcard such as /page/* only when it matches the intended scope;
• if a viewer-request function rewrites the URI, invalidate both the viewer path and rewritten path as required by the distribution design.

For non-standardized trailing slash behavior, cover both forms or canonicalize them before caching.

Create the invalidation

In CloudFront:

1. open the correct distribution;
2. select Invalidations;
3. choose Create invalidation;
4. enter one reviewed path per line;
5. confirm the scope;
6. submit and wait for completion.

AWS states that an invalidation cannot be cancelled after it starts. Prefer exact paths and narrowly reviewed trailing wildcards.

Verify completion

1. request the public URL with a clean viewer request;
2. confirm the response content is current;
3. observe the expected initial edge miss/refill;
4. request again and confirm a current edge hit;
5. repeat for Brotli/Gzip or image-format variants when applicable;
6. check a second site or host was not unintentionally affected.

If public content is still old, compare the viewer URL, redirect target, query behavior, host, cache behavior, and any edge-function URI rewrite with the invalidation path.

Prefer versioned asset URLs where appropriate

For immutable CSS, JavaScript, fonts, and generated assets, a new versioned filename can be more reliable than repeatedly invalidating the same path.

HTML and stable public page URLs normally cannot use filename versioning, so targeted invalidation remains part of their publishing workflow.

See Distinguish the origin cache from the CDN cache before invalidating a broad scope.