Soft 404, 404 and server errors: choose the right fix
Read the conclusion first
Choose the response according to the page's real business state. Restore an accidentally broken page, redirect a moved page to its equivalent, or return a genuine removal response when no replacement exists. A 200 response with an empty or error body does not restore the reader's task.
Applicable conditions
Applies to broken links, empty product pages, redirects, and server errors.
Before you open the report
The old URL, a possible equivalent replacement, response status, redirect chain and public rendering.
Use one concrete URL or report first. Keep account credentials and private visitor data out of shared notes.
Steps and verification
Capture the complete request outcome
For a failing URL, save request time, initial and final statuses, redirect destinations and the delivered body. Test without an administrator session and on the affected device. A challenge, empty template or ‘not found’ message can arrive with 200 and still fail the user.
Compare GSC's reported crawl time with current delivery. Intermittent 5xx requires logs and repeated observations around the failure window; one successful request cannot establish availability. Check the origin and proxy paths to locate where the response was produced.
Decide between restoration, replacement and removal
An important existing page accidentally returning 404 should be restored. A permanently moved page needs an appropriate permanent redirect to its genuine equivalent. A deliberately removed item with no useful replacement can retain 404 or 410 while its internal links and sitemap are corrected.
Do not send every missing article to the homepage. For temporarily unavailable products, decide whether the useful information and business state justify keeping the page. If a soft error is caused by missing data, fix the data/rendering path rather than changing only the status code.
Treat server failures as availability incidents
Inspect application, upstream, database and infrastructure errors corresponding to the failed requests. Preserve the relevant release and configuration before correcting or rolling back the fault. Record evidence rather than naming a database or capacity problem without logs.
After recovery, retest original failing paths and important user actions, then check error rates across a meaningful interval. Update links or sitemap only where the URL's intended state changed. Later crawl/indexing recovery is separate from the server repair, and a normal intentional 404 does not need to become a 200.
Common mistake: Only change status code to 200
If the content is still empty or wrong, the user problem is not solved and it may still be identified as a Soft 404.
How to decide when you encounter different situations
Match your actual observation to a row before changing the page. If it does not match, collect the missing evidence first.
| What you see | Next step | How to confirm |
|---|---|---|
| Deleted with no replacement | Return a true removal status | Clean up entry points and sitemap |
| Has an equivalent new page | Use a reasonable permanent redirect | Target is healthy and the chain is short |
| 200 with error body | Fix status or real content | Avoid Soft 404 |
The response must match what happened to the page
Teaching scenario. Names, URLs and numbers illustrate the method; they are not customer or measured site results.
- What you observe
- Example: a deleted product page returns 200 with “not found” text. Every deleted URL is redirected to the homepage.
- What it establishes
- The first case can be a soft 404. The second hides the absence of equivalent content and gives users an irrelevant destination.
- What to do next
- Use a genuine deletion response when no replacement exists. If an equivalent page exists, redirect to it and update links. For transient 5xx, investigate the application and host instead of converting it into a successful empty page.
What counts as a checked result
Test GET responses and the final body, not only HEAD. Keep a short redirect chain and ensure the destination serves the intended task.
If a required check fails, keep the error and return to the matching decision branch. A blank record means unverified, not passed.
Leave with a checked result, not another vague instruction
- Your deliverable
- An exact request trace and a restore/replace/delete decision tied to the original task.
- Stop and resolve this first
- Do not declare recovery from a single 200 that returns an empty or unrelated page.
Record missing evidence in the worksheet below. An unresolved test is useful information; a blank field is not a pass.
Checklist for this page
Fill in your own check results, then decide the next step. Blank means not yet verified, not normal. Content is saved only in the current local session and is not submitted to the server or AI.
Frequently asked questions
Do all 404s hurt rankings?
A 404 for a normally deleted URL is a reasonable status; only unexpected 404s on important pages need fixing.
Can I hide a temporary server error behind an empty 200 page?
That changes the status without restoring the answer and can mislead monitoring and visitors. Diagnose the failure and return an appropriate response until useful content is restored.
Official materials and usage boundaries
This page provides operational judgment and checking methods, and does not show customer success cases. Calculation examples and request samples are teaching materials, not actual website metrics. Google's reports, conditions, and interfaces may change; please refer to the current official documentation.
Read the corresponding Google official documentationContinue with the relevant tool
Check a public HTTPS URL with the redirect tool before closing the repair. Confirm that the final page answers the original reader's task.
See how it works →