WordPress CloudFront Sitemap Cache Invalidation Checklist
Sitemaps, prerendered HTML, and clean blog URLs often move through several cache layers. If CloudFront serves stale XML after publishing, Search Console may not discover new WordPress URLs even though the API and origin are correct.
Use this for WordPress, headless WordPress, S3, CloudFront, Lambda prerendering, or any setup where sitemap XML is generated and cached outside WordPress itself.
Quick answer
WordPress CloudFront Sitemap Cache Invalidation Checklist should be handled with a narrow evidence-first workflow: compare origin and edge, invalidate paths, check canonicals, then verify the result before making broader changes.
What to check first
- Fetch the sitemap through the public domain and from the origin path when possible.
- Invalidate `/sitemap.xml`, `/blog`, and the new clean post paths after publishing.
- Check whether `.html` and clean URLs share the same canonical target.
- Confirm cache headers and CloudFront behavior for XML, HTML, and image assets.
- Resubmit the sitemap and inspect a sample URL in Search Console.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|---|---|
| Compare origin and edge | Fetch the sitemap through the public domain and from the origin path when possible. | The public sitemap includes the new clean URL. |
| Invalidate paths | Invalidate `/sitemap.xml`, `/blog`, and the new clean post paths after publishing. | The clean URL returns article HTML and a matching canonical tag. |
| Check canonicals | Check whether `.html` and clean URLs share the same canonical target. | CloudFront no longer returns the old sitemap object. |
| Review cache headers | Confirm cache headers and CloudFront behavior for XML, HTML, and image assets. | Search Console accepts the sitemap with no errors or warnings. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS --max-time 15 https://example.com/sitemap.xml | grep new-post-slug
curl -sS -I --max-time 15 https://example.com/sitemap.xml
aws cloudfront create-invalidation --distribution-id EXAMPLE --paths '/sitemap.xml' '/blog' '/blog/new-post-slug'
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Compare origin and edge
- Invalidate paths
- Check canonicals
- Review cache headers
- Resubmit sitemap
Production verification checklist
- The public sitemap includes the new clean URL.
- The clean URL returns article HTML and a matching canonical tag.
- CloudFront no longer returns the old sitemap object.
- Search Console accepts the sitemap with no errors or warnings.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WordPress sitemap cache problems.