A Soft 404 is Google’s label for a URL that returns HTTP 200 but looks empty, generic, or like an error page. Your server thinks everything is fine. Search Console disagrees. The page may sit in Page indexing under Soft 404 while URL Inspection’s live test sometimes says the page can be indexed. Both can be true at once — the index tab reflects an older crawl; the live test sees today’s HTML.
\n\nThat mismatch is why I stopped trusting green checkmarks in Chrome and started with curl. Real 404 means not found. Soft 404 means “you sent a success status but gave me nothing worth indexing.” For a React journal on a prerender shell, the failure mode is subtle: correct canonical, correct title, hero image, meta description — and almost no article prose in the first HTML response.
After hydration, journal posts on briancrabtree.me look complete. The router mounted BlogPost. The public API returned full content. Headings, code blocks, internal links — all there. View source in a normal browser session often shows the hydrated DOM, not the bytes nginx served on first request.
Disable JavaScript or fetch the URL without executing the bundle:
\n\ncurl -sL \"https://briancrabtree.me/journal/my-post/\" \\\n | rg -i '<title>|prerender-post-summary|prerender-post-prose|<h2'Before this fix, that command showed title, hero, and a speakable summary paragraph — roughly 190 characters. No <h2>. No article body. Firestore and the public API still held six to seven kilobytes of HTML per post. Crawlers that do not wait for the client fetch saw a thin page. That is exactly the Soft 404 pattern Google warned me about in email when validation failed on earlier “fixes.”
I wrote about the earlier failure mode — missing per-slug shells and homepage canonical on every URL — in React SPA Crawled, Not Indexed: The Fix That Actually Moved GSC. Fixing canonicals and deploying one hundred two slug directories under /journal/ was necessary. It was not sufficient. The shell still hid the body behind JavaScript.
The prerender pipeline from injectJournalMetaCli.js already did the hard SEO work: per-post <title>, meta description from the summary file, canonical with trailing slash, Open Graph and JSON-LD, LCP hero preload, and a journal layout that mirrors the React article chrome. Live tests passed. Indexing requests went through — until Google re-crawled and decided the HTML was still too thin.
Two posts showed up repeatedly in my GSC notes: Everything Your Website Needs to Actually Succeed and Lab vs Field Data — When PageSpeed Scores Mislead You. Both returned 200 with correct head tags. Both had full content after hydration. Both triggered Soft 404 on stale crawl data, then failed validation when Google expected more substance in the initial response.
\n\nThe change is small and mechanical. At build and publish time, pass the same sanitized HTML stored in Firestore into buildJournalPostShellBody. Inject it after the speakable summary:
<div class=\"page-post-body prerender-post-prose\">\n …full post HTML from content/journal/{slug}.html…\n</div>sanitizeJournalShellHtml strips scripts, inline event handlers, and javascript: URLs. The shell stays aria-hidden=\"true\" — it is for crawlers and first paint, not duplicate interactive UI. React still hydrates and owns navigation, likes, and admin-driven updates. The shell is the crawl contract.
This is the same philosophy as Static Prerender Shells: SPAs That Paint Before JavaScript, pushed one level deeper: not just meta and hero, but the actual article prose Google uses to judge whether a 200 response is a real document or a placeholder.
\n\nWhen Search Console emails that Soft 404 fixes failed, do not spam Request indexing on thin URLs. That burns daily quota and trains nothing useful.
\n\ncurl — expect prerender-post-prose and multiple <h2> tags in the first response.npm run verify:edge so Cloudflare challenge does not poison live tests.Validation can take days. The Page indexing report may still show a last-updated date from weeks ago while live tests are already clean. That lag is normal. The email about failed validation means Google re-crawled and still did not like what it saw — which, for me, meant summary-only shells.
\n\n- [ ] curl slug URL — prerender-post-prose contains h2 + paragraphs\n- [ ] canonical and title match sitemap trailing-slash URL\n- [ ] public API /api/public/posts/{slug} returns content field\n- [ ] injectJournalMetaCli wrote dist/journal/{slug}/index.html\n- [ ] full deploy (not --no-build) — journal dir count >= 50\n- [ ] Soft 404 Validate fix submitted in GSC after prose deploy\n- [ ] indexing requests only after validation gate + verify:edgeFor performance discipline on the same stack — head order, CSS before module JS, prerender hero — see Website Performance Audit Checklist (2026), Why Your React Site Loads Unstyled, and Performance Checks Before Handoff. Soft 404 is an SEO crawl signal, not a Lighthouse score. Fix the HTML Google fetches first; then chase indexing quota.
\n\nIf Search Console shows Soft 404 on URLs that look fine in Chrome, send the production slug and the output of the curl command above at /contact. I will tell you whether you need prerender body injection, canonical repair, or something else entirely. See services for how I scope React SEO and deploy hygiene.
","tags":["google-search-console","soft-404","prerender","react-spa","technical-seo"],"views":36}