A missing page should normally return a clear missing-resource response such as 404 or 410. A soft 404 is a content/status mismatch: the server signals success or redirects, but the destination does not provide a useful page. A friendly error design is fine; the underlying response still needs to reflect the missing resource.
Test a made-up route deliberately
Choose a random path that cannot be a real page, such as a unique test string with the current date. Trace it with the redirect checker and open it in a browser. Read both the final HTTP status and the visible content. The full launch audit also samples missing-page behavior. Use a path outside any dynamic catch-all section so you do not mistake a legitimate application route for a missing document.
Look for fallback behavior
Single-page applications and static hosting can send index.html for every unknown path. That may support real client routes, but it can also make nonexistent routes look successful. Another common rule redirects all missing URLs to the homepage. Review the application's route inventory and the hosting fallback together. The correct fix may require the server or edge handler to distinguish known application paths from truly missing resources.
Keep the error page useful
A 404 page can offer navigation, search or links to popular destinations while returning a 404 status. Make the message clear enough that a visitor knows the requested page was not found. Avoid automatically sending them elsewhere without explanation unless there is a specific appropriate replacement. A friendly visual page does not require a successful HTTP response, and a missing page should not imitate a normal product or article.
Use redirects when there is a real replacement
An old page with a closely related successor can have a deliberate permanent redirect. Check that the replacement serves the same intent and that internal links now use it directly. If there is no replacement, a genuine missing response is often clearer than an unrelated homepage. Keep a record of page-move decisions so later site cleanup does not replace a thoughtful mapping with a broad catch-all rule.
Check a few different route shapes
Test a root-level made-up path, a nested path and a retired URL with an extension if those shapes exist on your site. Some servers handle them differently. Also check that an error page does not declare a canonical to a real public article while presenting missing content. The checker shows the response path; the rendered browser review tells you whether the message and navigation help a person recover.
Verify the production response
After changing fallback rules, recheck real pages as well as invented ones. A broad fix can accidentally break client-side routes that should work. Confirm status and content on both cases, and keep a small release record of the tested paths. Search Console's classification can reflect an earlier crawl, so compare its timestamp with your deployment and fresh response. A current 404 is evidence of your fix, not proof that every old index record has already changed.
A practical action checklist
- Request a unique made-up path.
- Compare final HTTP status with the visible page.
- Review hosting fallbacks and application route ownership.
- Use specific redirects only where a suitable replacement exists.
- Retest real and missing paths after deployment.
NewSiteCheck workflow and examples. Review important production decisions against the applicable official documentation.