404 Errors: When to Restore, Redirect, or Leave a Page Removed
Published:
Last Updated:
Category: Content Marketing
Authors: Shusaku Yosa
A 404 Not Found response means that the requested location has no current representation, or that the server is unwilling to disclose one. Visitors should check the address and the site's official navigation. Website owners should decide whether to restore the page, redirect it to a relevant replacement, or keep an appropriate 404 or 410 response.
Redirecting every missing URL to the home page is not a universal solution. Neither is replacing an error with a normal-looking page that returns success. Start with what the URL is supposed to do. If the message is Forbidden rather than Not Found, use the separate 403 access troubleshooting guide.
404, 410, and soft 404 are different
The 404 definition in RFC 9110 does not establish whether the situation is temporary or permanent. A 410 Gone response communicates that a resource is no longer available and the condition is likely permanent. The status alone does not explain the editorial or technical decision behind a removal.
Type | Meaning | Practical implication |
|---|---|---|
404 Not Found | No current representation is found, or existence is withheld | Can be appropriate for removed content and unknown paths |
410 Gone | The resource is unavailable and likely permanently gone | Can express an intentional removal, without promising faster search removal |
Soft 404 | Google classifies a page as an error-like result | Can involve a success response with an error message or empty, insufficient content |
301 redirect | A permanent move to another URL | Use a relevant destination, not an arbitrary landing page |
Google's HTTP status documentation treats 4xx responses other than 429 alike. Changing 404 to 410 does not guarantee quicker removal from search. A soft 404 is a search-engine classification, not simply another HTTP code. A page that appears normal to a person can still be classified as error-like.
What a visitor should check
- Check for a truncated address, extra punctuation, or an obvious copying error.
- Use the site's official home page, article listing, or internal search to find the content.
- Record whether only an old bookmark fails or current official links fail too.
- For restricted content, use the service's intended login route and authorized account.
- Send the URL, time, and preceding action to the site owner when the content cannot be found.
Repeated refreshes cannot restore an intentionally deleted page. Do not enter sensitive information on a similarly named site or guess identifiers in private links. An external link may be outdated even when the destination website is operating correctly.
If a 404 follows a purchase or application, check the confirmation and account history before resubmitting. A missing confirmation page does not prove that processing failed. Ask support to establish the transaction's outcome when it is uncertain.
For owners: restore, move, or remove?
A mistakenly deleted article and an expired campaign with no replacement need different responses. Decide what a visitor to that address should receive before changing routing rules. Low traffic by itself is not a reason to merge, redirect, or delete content.
Situation | Likely action | Verification |
|---|---|---|
A page intended to stay public disappeared | Restore it at the original address | Successful response, intended content, assets, and access |
The same content permanently moved | Redirect to its corresponding new URL | Relevant final page, success response, no loop |
The content was removed with no equivalent replacement | Keep an appropriate 404 or 410 | Helpful explanation and correct HTTP response |
The requested path never existed | Return 404 | Avoid a blanket redirect to unrelated content |
A temporary service outage prevents delivery | Use the response appropriate to the outage | An administrator may consider 503 under the actual operating conditions |
Consider a fictional example. An introductory analytics article moves to a new address with substantially the same purpose. A permanent redirect from the old article to the new one is a reasonable candidate. An ended, one-off promotion with no equivalent offer is different: sending every old promotion link to the home page may frustrate visitors and obscure the fact that the offer ended.
A canonical tag is not a redirect
A redirect sends the browser or crawler to another address. A canonical signal identifies a preferred representative among duplicate or similar pages; it does not move the visitor. Adding a canonical reference to a missing page does not restore the content or repair an incorrect response.
A permanent redirect is a strong canonicalization signal to Google, but it is not a guarantee that every ranking or evaluation transfers unchanged. Use the 301 and 302 redirect guide for move decisions and the canonical settings guide for representative-URL decisions.
Collect evidence before prioritizing repairs
Maintain separate records for URLs intended to be public, moved URLs, and deliberately removed URLs. Inspect internal links, XML sitemaps, server logs, and Search Console where available. Each source observes different activity and may update at a different time. Absence from a Search Console table is not proof that a URL does not exist or has never been crawled.
- Is a current product, application, or important article affected?
- Do present navigation or body links send visitors to the missing page?
- Does a template generate the same incorrect address across many pages?
- Are external links or search results bringing people to it?
- Does the response match the recorded removal or migration decision?
Restore important pages that should be available and fix current internal links first. Random nonexistent paths in a log do not require creating a page for every address. Also, standard GA4 tracking does not automatically provide the HTTP response code for every page. A page title containing “404” is a useful clue only if the implementation and collection conditions have been verified.
Design and test a helpful error page
A useful custom error page explains what happened, links to the home page or an appropriate listing, and offers a working search or support route where relevant. Let visitors choose a sensible next step. The page may use the site's usual branding, but its appearance and its HTTP response are separate things to verify.
Test a live URL, a deliberately removed URL, an invented nonexistent path, and an old URL with a known replacement. An administrator should inspect the response status, final destination, and delivered content, not only the visible message. A polished “page missing” screen that returns 200 can create a soft-404 problem.
Some hosting or application routers send unknown paths to a shared entry point. Do not diagnose that architecture from appearance alone: check what the server actually returns for a nonexistent article. Compare signed-in and public behavior when relevant, and make sure any difference matches the intended publication rules.
Follow up on links, sitemaps, and search reports
After a migration, update internal links to the new address instead of leaving every visit dependent on a redirect. Keep the XML sitemap aligned with public canonical URLs. The XML sitemap creation and verification guide explains the distinction between submitting a file and confirming an individual URL's indexing status.
An old 404 entry in Search Console can remain after the live response has changed. Compare the last crawl date with the current response before assuming a repair failed. Conversely, a deliberately removed page can correctly remain a 404. The goal is consistent publishing intent, responses, and navigation, rather than an error count of zero.
Keep a change record containing the affected URL, decision, relevant destination, owner, verification date, expected response, and observed result. If traffic or enquiries improve later, separate that observation from a claim of causation. Other releases, campaigns, seasonality, and search changes may also contribute.
