CloudFront still serves old content

POM Cache clears origin files only. CloudFront can continue returning a previously cached object until it expires, is evicted, or is invalidated.

Prove the origin first

Before creating an invalidation:

1. confirm that WordPress contains the published value;
2. clear the correct POM Cache HTML or JSON store;
3. request the origin through an approved origin-testing method;
4. verify the regenerated response body and status;
5. verify a subsequent origin cache hit.

Do not expose a private origin or weaken its access controls for testing. Use the method provided by your infrastructure, such as a protected origin hostname or an authorized request with the correct host routing.

If the origin is stale, a CloudFront invalidation will only cause the edge to fetch that same stale response again.

Identify the exact viewer objects

CloudFront cache identity can include more than the path. Record:

• viewer hostname;
• path and trailing slash;
• query string and its cache policy;
• HTTP method;
• negotiated content encoding;
• headers or cookies included in the cache key;
• locale or progressive JSON variant.

Invalidate the actual viewer paths, not an origin filesystem path.

For a slug change, both the old and new viewer paths may require attention: the old one for its redirect or removal, and the new one for current content.

Submit and verify the invalidation

Use the CloudFront console, API, or your deployment process to invalidate the smallest complete path set. Then:

1. wait until the invalidation reports completion;
2. request the exact viewer URL in a clean client;
3. inspect CloudFront cache status and object age;
4. confirm the response body and headers;
5. repeat for every relevant variant.

A wildcard can be appropriate for a broad site deployment, but it increases origin traffic and removes useful warm objects. Prefer exact paths when the dependency set is known.

Check cache and response policies

If stale content returns again, inspect:

• CloudFront minimum, default, and maximum TTL behavior;
• origin Cache-Control and Expires;
• error-response caching;
• query/header/cookie forwarding;
• cache-key normalization;
• separate behaviors for HTML, JSON, media, and WebP;
• multiple distributions or host aliases;
• browser or service-worker caching after CloudFront.

POM Cache does not configure those CloudFront policies.

Coordinate future changes

For a deployment or content operation:

1. commit the source change;
2. clear or invalidate the relevant POM Cache origin store;
3. regenerate and verify the origin;
4. submit the CloudFront invalidation;
5. verify the viewer response.

For custom integrations, collect affected viewer paths during the operation and invalidate once at its commit point. Do not issue one invalidation per imported item.

CloudFront can also negotiate Brotli or gzip at the edge. Compression variants should return identical content; if only one encoding is stale, inspect the cache and response policy rather than POM Cache's origin file.