Headless WordPress and React frontends can return an app shell for missing URLs. If the response is 200 with generic metadata, Google may treat a missing page as a soft 404 or a low-quality duplicate.
Use this for WordPress frontends that use CloudFront, S3, React Router, Next.js, Lambda prerendering, or SPA fallback behavior.
Quick answer
WordPress App Shell 404 Status Code Checklist should be handled with a narrow evidence-first workflow: sample url classes, record status and metadata, fix missing fallback, then verify the result before making broader changes.
What to check first
- Fetch a real post, missing post, tag archive, service page, and random URL with curl.
- Record HTTP status, title, canonical tag, robots meta tag, and body signals for each URL.
- Return a real 404 or noindex fallback for missing content instead of a valid article shell.
- Keep intentionally client-routed pages out of the sitemap until they have crawlable metadata.
- Inspect one missing URL and one real URL in Search Console after changes.
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 |
|---|---|---|
| Sample URL classes | Fetch a real post, missing post, tag archive, service page, and random URL with curl. | Real pages return 200 with page-specific metadata. |
| Record status and metadata | Record HTTP status, title, canonical tag, robots meta tag, and body signals for each URL. | Missing pages return 404 or noindex fallback behavior. |
| Fix missing fallback | Return a real 404 or noindex fallback for missing content instead of a valid article shell. | Fallback shells do not self-canonical as valid articles. |
| Clean sitemap | Keep intentionally client-routed pages out of the sitemap until they have crawlable metadata. | The sitemap contains only intended canonical URLs. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sSI https://example.com/blog/real-post
curl -sSI https://example.com/blog/missing-post
curl -sS https://example.com/blog/missing-post | grep -Ei '<title>|canonical|robots|404'
curl -sS https://example.com/sitemap.xml | grep 'missing-post'
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.
- Sample URL classes
- Record status and metadata
- Fix missing fallback
- Clean sitemap
- Inspect in GSC
Production verification checklist
- Real pages return 200 with page-specific metadata.
- Missing pages return 404 or noindex fallback behavior.
- Fallback shells do not self-canonical as valid articles.
- The sitemap contains only intended canonical 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 app shell SEO behavior.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.