A soft 404 is a page that returns success while telling users—or algorithms—that useful content is absent. Common examples are empty search results, broken database templates, and removed posts rendered inside a normal shell.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: return truthful HTTP status codes for missing content and repair thin/error pages that incorrectly return 200.

What the symptom narrows down

  • A custom 404 template or redirect plugin returns 200 for missing URLs.
  • Removed URLs redirect to an irrelevant home/category page.
  • Critical content fails to render while the surrounding template still returns success.

The branches are ordered to protect the strongest evidence around this possibility: a custom 404 template or redirect plugin returns 200 for missing URLs. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Crawlability, indexability, and canonical selection are separate; a crawler may discover a URL it cannot fetch, fetch a URL marked noindex, or index a different canonical than the publisher prefers; test the live HTTP response and rendered document before interpreting a report label; in this guide, the practical goal is to return truthful HTTP status codes for missing content and repair thin/error pages that incorrectly return 200.

Evidence to collect before the fix

  1. Use curl -I on known good, deliberately missing, removed, and redirected URLs.
  2. Inspect the rendered body in Search Console URL Inspection.
  3. Check templates and plugins that intercept 404 handling.
  4. Find internal links and sitemap entries pointing to the affected URLs.

The sequence moves from observation toward intervention. Preserve the result of the final check—find internal links and sitemap entries pointing to the affected URLs—because it provides a useful comparison after the repair.

Build a four-URL status truth table

Compare a valid page, a deliberately missing URL, a removed URL, and a known replacement. The status and redirect target should match the content outcome.

for path in /valid-page/ /definitely-missing-7f9a/ /removed-page/ /replacement-page/; do
  curl -sS -o /dev/null -w '%{http_code} %{redirect_url} %{url_effective}\n' \
    "https://example.com${path}"
done

Interpretation and safety: A missing page should not return 200 or redirect generically to home. Use 301 only for a genuinely equivalent replacement.

A bounded staging experiment

Begin with the first plausible cause: a custom 404 template or redirect plugin returns 200 for missing URLs. Before changing state, write down what would confirm it and run the first read-only check: use curl -I on known good, deliberately missing, removed, and redirected URLs.

If the result supports that cause, try one bounded repair on staging: return 404 or 410 when content has no equivalent replacement. If evidence from “Use curl -I on known good, deliberately missing, removed, and redirected URLs” points elsewhere, keep this layer unchanged and move to the next check. That small decision log is far easier to audit than several simultaneous edits.

Apply fixes in the safest order

  1. Return 404 or 410 when content has no equivalent replacement.
  2. Use 301 only when a genuinely equivalent page exists.
  3. Repair blocked resources or application failures when a valid page was misread as empty.

Before applying “Return 404 or 410 when content has no equivalent replacement,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can missing URLs return a real 404 with useful human navigation; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Prove recovery

  • Missing URLs return a real 404 with useful human navigation.
  • Replacement URLs make one redirect and the target returns 200.
  • Sitemaps and internal links no longer list removed URLs.

One successful refresh is not closure. Keep the incident open until you can also replacement URLs make one redirect and the target returns 200, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

When escalating, include the exact canonical URL, response chain, robots rules result, meta and X-Robots-Tag values, canonical annotation, sitemap entry, and Search Console live-test date; search changes require recrawling; they are not instant configuration toggles; include the result of this first observation: use curl -I on known good, deliberately missing, removed, and redirected URLs.

State what was tested, including the result of “Use `curl -I` on known good, deliberately missing, removed, and redirected URLs,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

  • Do not redirect all 404s to the home page.
  • Do not put a noindex tag on an error page while continuing to return 200 as the primary fix.

Incident handoff

ScopeFix WordPress Soft 404s Without Redirecting Everything to Home · URL · role · first/last occurrence
EvidenceStatus · request ID · first relevant log entry
ChangeOne action · backup/rollback point · operator
ProofOriginal reproduction · adjacent paths · monitoring window

Primary references

Editorial note: The scenario above illustrates how to approach “Return 404 or 410 when content has no equivalent replacement”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.