CloudFront custom error responses often send missing paths to an app shell with status 200. That may help client-side routes, but missing `.js`, `.css`, `.webp`, `.svg`, and `.map` assets need different status behavior than real app routes.
Use this for S3 and CloudFront frontends, React or headless WordPress sites, static builds, and sites where broken asset URLs return `text/html` instead of a missing asset status.
Quick answer
CloudFront Custom Error Missing JS CSS Soft 404 should be handled with a narrow evidence-first workflow: test missing assets, review error rules, separate extensions, then verify the result before making broader changes.
What to check first
- Request a missing `.js`, `.css`, `.webp`, `.svg`, and `.map` file and record status, content type, cache result, and body title.
- Review CloudFront custom error responses for 403 or 404 responses rewritten to `/index.html` with response code 200.
- Separate app routes from static asset extensions before applying an app-shell fallback.
- Check viewer request or origin response functions for rewrites that run before extension handling.
- Invalidate changed error paths, affected assets, `/blog`, and `/sitemap.xml` after updating 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 missing `.js`, `.css`, `.webp`, `.svg`, and `.map` file and record status, content type, cache result, and body title. | Missing static assets no longer return `text/html` app shell responses with 200 status. |
| Review error rules | Review CloudFront custom error responses for 403 or 404 responses rewritten to `/index.html` with response code 200. | Valid app routes and clean blog routes still work after the fallback change. |
| Separate extensions | Separate app routes from static asset extensions before applying an app-shell fallback. | Sitemap contains canonical URLs only and no stale asset paths. |
| Check functions | Check viewer request or origin response functions for rewrites that run before extension handling. | Search Console and monitoring can distinguish missing assets from valid pages. |
Why this usually happens
- A single custom error rule maps all missing origin keys to the app shell.
- Private S3 origins return 403 for missing objects, and CloudFront handles that like an app route.
- A SPA fallback was added before the site had SEO-sensitive prerendered routes and static assets.
- Monitoring only checks status code and misses the content type mismatch.
- Sitemap or rendered HTML contains stale asset URLs that now look like valid pages.
Field notes
- The fix is not always to delete the app-shell fallback. Keep it for real app routes and carve out assets.
- A missing `.css` file returning `text/html` is usually more actionable than the 200 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.css
curl -sS -I --max-time 10 https://example.com/assets/missing.js
curl -sS -I --max-time 10 https://example.com/images/missing.webp
# Static assets 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
- Review error rules
- Separate extensions
- Check functions
- Invalidate paths
What to tell the client or owner
Tell the owner which URL classes changed and show before and after headers for missing CSS, JS, images, and valid app routes.
Production verification checklist
- Missing static assets no longer return `text/html` app shell responses with 200 status.
- Valid app routes and clean blog routes still work after the fallback change.
- Sitemap contains canonical URLs only and no stale asset paths.
- Search Console and monitoring can distinguish missing assets from valid pages.
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 app-shell and technical SEO issues.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
- CloudFront missing asset returns app shell 200 fix
- CloudFront origin response vs viewer response SEO debug
- CloudFront custom error app shell 404 SEO fix