CloudFront custom error responses can make a missing CSS, JavaScript, image, or static file return the app shell with status 200. That helps single-page app routing, but it can create confusing crawl signals and hide real broken assets.
Use this for React, headless WordPress, S3 static hosting, CloudFront distributions, and sites where unknown asset paths return index.html instead of a real missing-asset status.
Quick answer
CloudFront Missing Asset Returns App Shell 200 Fix should be handled with a narrow evidence-first workflow: test missing assets, separate route classes, adjust error responses, then verify the result before making broader changes.
What to check first
- Request a known missing CSS, JS, image, and blog URL with headers only and record status, content type, and cache result.
- Separate app routes that should fall back to index.html from static asset extensions that should return 404 or 410.
- Review CloudFront custom error responses for 403 and 404 mapping to index.html with response code 200.
- Check whether origin access, S3 website behavior, or a function rewrite changes the request before the error response.
- Invalidate only the affected asset paths, app route paths, and sitemap after changing error behavior.
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 |
|---|---|---|
| Test missing assets | Request a known missing CSS, JS, image, and blog URL with headers only and record status, content type, and cache result. | Missing static assets return an expected missing status and correct content type behavior. |
| Separate route classes | Separate app routes that should fall back to index.html from static asset extensions that should return 404 or 410. | Valid app routes still render the application or prerendered page. |
| Adjust error responses | Review CloudFront custom error responses for 403 and 404 mapping to index.html with response code 200. | Sitemap URLs are clean canonicals and do not include stale asset or .html variants. |
| Review rewrites | Check whether origin access, S3 website behavior, or a function rewrite changes the request before the error response. | Search Console inspection does not see a soft 404 or app-shell page for important URLs. |
Why this usually happens
- A single custom error rule sends every missing key to index.html with a 200 status.
- S3 returns 403 for missing private objects, and CloudFront treats it like an app route fallback.
- A viewer request function rewrites paths before asset extension checks run.
- The sitemap or internal links contain stale asset paths that now look like HTML pages.
Field notes
- Do not remove SPA fallback blindly. Keep it for real app routes and carve out static assets.
- Check content type. A missing .webp that returns text/html is a stronger clue than the status alone.
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 10 https://example.com/assets/missing-file.css
curl -sS -I --max-time 10 https://example.com/images/missing-image.webp
curl -sS -I --max-time 10 https://example.com/blog/real-clean-url
# Asset paths should not return text/html app shell with 200.
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.
- Test missing assets
- Separate route classes
- Adjust error responses
- Review rewrites
- Invalidate precise paths
What to tell the client or owner
Tell the owner which URL classes changed: assets, app routes, blog routes, and sitemap. This avoids breaking the app while cleaning SEO signals.
Production verification checklist
- Missing static assets return an expected missing status and correct content type behavior.
- Valid app routes still render the application or prerendered page.
- Sitemap URLs are clean canonicals and do not include stale asset or .html variants.
- Search Console inspection does not see a soft 404 or app-shell page for important URLs.
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 and technical SEO issues.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
- CloudFront origin response vs viewer response SEO debug
- CloudFront custom error app shell 404 SEO fix
- Duplicate SEO tags in prerendered WordPress HTML