CloudFront can cache content based on origin headers and cache behavior settings. Prerendered WordPress HTML changes when titles, meta descriptions, canonicals, body content, and sitemap entries change, so it needs a different cache strategy than immutable image files.
Use this for headless WordPress, S3-hosted prerendered pages, Lambda prerender workflows, CloudFront distributions, and SEO-sensitive blog publishing.
Quick answer
CloudFront Cache-Control for Prerendered WordPress HTML should be handled with a narrow evidence-first workflow: compare headers, separate asset cache, invalidate html, then verify the result before making broader changes.
What to check first
- Compare Cache-Control headers for images, sitemap XML, clean HTML URLs, and direct `.html` URLs.
- Use long-lived immutable cache only for versioned static assets.
- Keep HTML and sitemap paths easy to invalidate after publishing or metadata updates.
- Use ETag or Last-Modified validators where they help crawlers revalidate changed pages.
- Verify CloudFront behavior does not serve stale canonical, title, or meta description tags.
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 headers | Compare Cache-Control headers for images, sitemap XML, clean HTML URLs, and direct `.html` URLs. | Images can use long-lived immutable cache while HTML remains refreshable. |
| Separate asset cache | Use long-lived immutable cache only for versioned static assets. | A post metadata update appears in clean URL and `.html` output after invalidation. |
| Invalidate HTML | Keep HTML and sitemap paths easy to invalidate after publishing or metadata updates. | The sitemap updates without waiting for a long edge TTL. |
| Use validators | Use ETag or Last-Modified validators where they help crawlers revalidate changed pages. | Googlebot receives the current title, canonical, and meta description. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -I --max-time 15 https://example.com/blog/post-slug
curl -sS -I --max-time 15 https://example.com/blog/post-slug.html
curl -sS -I --max-time 15 https://example.com/sitemap.xml
aws cloudfront create-invalidation --distribution-id EXAMPLE --paths '/blog/post-slug' '/blog/post-slug.html' '/sitemap.xml'
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 headers
- Separate asset cache
- Invalidate HTML
- Use validators
- Verify metadata
Production verification checklist
- Images can use long-lived immutable cache while HTML remains refreshable.
- A post metadata update appears in clean URL and `.html` output after invalidation.
- The sitemap updates without waiting for a long edge TTL.
- Googlebot receives the current title, canonical, and meta description.
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 CloudFront caching for WordPress SEO.