How to invalidate CloudFront cache after WordPress changes
CloudFront can continue serving an older WordPress page, redirect, stylesheet, script, or media object even after the origin is already corrected. A targeted invalidation removes the stale edge object so the next request is forced back to the origin instead of waiting for the cached response to expire naturally.
CloudFront invalidates objects by distribution-relative path, so the important input is the exact public path that is stale, not the filesystem path on the web server. For WordPress, that usually means a changed file under /wp-content/, a cached redirect for a post or page URL, or a generated asset such as an optimization bundle or page-builder stylesheet. When the same static asset changes often, versioned filenames remain the cleaner long-term approach because they avoid repeated invalidation requests and also bypass stale copies outside CloudFront.
Use invalidation only after the WordPress origin is already returning the correct response. Invalidation paths are case sensitive, AWS CLI requests require a leading slash, and wildcard paths must be quoted with the wildcard at the end of the path. If the cache key includes query strings, invalidate each cached query-string variant or use a wildcard path that matches them.
Steps to invalidate CloudFront cache after WordPress changes:
- Record the exact public URL path that is still stale through CloudFront.
$ curl -I https://www.example.com/wp-content/uploads/2026/03/logo.png HTTP/2 200 cache-control: public, max-age=31536000 age: 1842 x-cache: Hit from cloudfront content-type: image/png
Capture the path that viewers request, not the origin server path. Age and X-Cache: Hit from cloudfront confirm that CloudFront is still serving a cached edge response for that object.
- Choose the smallest invalidation scope that matches the stale WordPress objects.
Use an exact file path such as /wp-content/uploads/2026/03/logo.png when one object is stale, a quoted wildcard such as "/wp-content/uploads/2026/03/*" when a regenerated folder needs to be refreshed, or "/*" only when stale responses are widespread.
Paths are case sensitive and must start with a leading slash in the AWS CLI. When CloudFront caches query-string variants for a file, invalidate the specific variants such as /wp-content/uploads/2026/03/logo.png?ver=1 or use a wildcard path such as /wp-content/uploads/2026/03/logo.png*.
- Submit the invalidation request and note the returned invalidation ID.
$ aws cloudfront create-invalidation \ --distribution-id E123EXAMPLE \ --paths '/wp-content/uploads/2026/03/logo.png' '/wp-content/themes/example/style.css' \ --query 'Invalidation.{Id:Id,Status:Status,Paths:InvalidationBatch.Paths.Items}' { "Id": "I2J0I21PCUYOIK", "Status": "InProgress", "Paths": [ "/wp-content/uploads/2026/03/logo.png", "/wp-content/themes/example/style.css" ] }Add --profile production-cdn when the shell default is not already the correct AWS account for the site's CloudFront distribution.
- Wait for CloudFront to finish the invalidation request.
$ aws cloudfront wait invalidation-completed \ --distribution-id E123EXAMPLE \ --id I2J0I21PCUYOIK
The built-in waiter polls the invalidation status until CloudFront reports success, which is usually simpler than manually listing recent invalidations in a loop.
- Check the completed invalidation record before retesting the site.
$ aws cloudfront get-invalidation \ --distribution-id E123EXAMPLE \ --id I2J0I21PCUYOIK \ --query 'Invalidation.{Id:Id,Status:Status,Paths:InvalidationBatch.Paths.Items}' { "Id": "I2J0I21PCUYOIK", "Status": "Completed", "Paths": [ "/wp-content/uploads/2026/03/logo.png", "/wp-content/themes/example/style.css" ] }This confirms that the request finished and that the submitted path list matches the objects that were meant to be refreshed.
- Request the public WordPress URL again and confirm that CloudFront now fetches the corrected origin response.
$ curl -I https://www.example.com/wp-content/uploads/2026/03/logo.png HTTP/2 200 cache-control: public, max-age=31536000 x-cache: Miss from cloudfront content-type: image/png
A first Miss from cloudfront after the invalidation is the expected sign that the edge had to fetch a fresh copy. If the same bad redirect, 404, or wrong asset body returns again after the invalidation is complete, the WordPress origin, generated asset, or redirect rule still needs to be fixed.