404 Errors: When to Fix, Redirect or Ignore
404 errors are the “page not found” response a server returns when a requested URL doesn’t exist, and most of them need no action: you fix a 404 when the page should exist, redirect it when a close replacement exists, and ignore it when neither is true. The mistake is treating every line in a report as a defect. The skill is sorting them fast.
This guide is for anyone staring at a Search Console list or crawl export of 404 errors. It gives you a triage tree, the rules for when a 301 earns its place, the difference between 404, 410 and soft 404, and a routine you can repeat. For the redirect mechanics themselves, see redirects SEO; this page is about deciding which URLs deserve one.
On this page
- Are 404 errors bad for SEO?
- Where do 404 errors come from?
- The triage: fix, redirect or ignore
- When a 404 deserves a 301 redirect
- 404 vs 410 vs soft 404
- A repeatable 404 triage routine
- Getting 404 handling right on your site
Are 404 errors bad for SEO?
Not by themselves. Google’s Page indexing report documentation says 404 responses are not necessarily a problem when a page has been removed without a replacement. Google also says URLs that return a 4xx status are not indexed, and ones already indexed are removed. In its HTTP status code documentation, that is the intended behavior: a missing page leaves the index.
So a 404 is information, not a penalty. Our technical SEO issues guide lists the audit warnings that matter most and files “404 for a removed page” under the ones to skip. The cost of a 404 shows up in three narrower places:
- Lost link value. An external page linking to a URL that now returns 404 sends visitors and authority nowhere.
- Broken paths for visitors. Your own menu, body links or sitemap pointing at dead pages waste clicks and crawling.
- Pages that should exist. A product, service or article returning 404 by accident is lost traffic, however the error got there.
Everything else on the list is noise. The rest of this post is about telling the three costly cases from the noise.
Where do 404 errors come from?
Most 404 errors come from five places, and the source decides the fix. Knowing the source is half the triage, because the same dead URL can be harmless in one report and urgent in another.
| Source | Typical cause | Where you see it | Default action |
|---|---|---|---|
| Your own links | Page deleted or renamed, links not updated | Site crawl, Search Console | Fix the link |
| Your sitemap | Removed pages still listed | Search Console sitemap and page indexing reports | Regenerate the sitemap |
| Other sites | Mistyped or outdated links, old campaigns | Backlink tools, server logs | 301 if the link has value |
| Past URL changes | Migration or redesign without a map | Search Console, crawl of the old URL list | 301 to the equivalent |
| Random requests | Typos, scanners, made-up paths | Server logs | Ignore |
First, note what each tool actually shows. Search Console reports what Google discovered and tried to fetch, which can include URLs from years ago. A crawler only finds what your current pages link to, so it catches broken internal links but not old external ones. Server logs show everything requested, including noise. You need at least two of the three to see the whole picture; our Google Search Console guide explains how to read the indexing reports.
The diagram below shows what each source can and cannot see.
Scroll the diagram sideways to see all of it.
The triage: fix, redirect or ignore
Work down four questions in a fixed order, and stop at the first yes. The diagram below shows the order. It matters because the cheapest correct fix usually sits at the top: restoring a page or correcting a link beats adding a redirect that papers over the problem.
Scroll the diagram sideways to see all of it.
Question one catches the expensive mistakes: a CMS setting, a rewrite rule or a deploy that broke a page that should be live. Question two catches the most common waste. If your own navigation or sitemap points at a dead URL, redirecting it hides the symptom and keeps the bad link. Fix the source and the 404 stops being requested by your own site.
Google’s documentation adds a useful limit here: it suggests concentrating on 404s for URLs you link to yourself or list in a sitemap. Everything else is Google revisiting URLs it remembers.
When a 404 deserves a 301 redirect
A 404 deserves a 301 when the dead URL still receives something worth keeping and a page exists that answers the same need. “Something worth keeping” means backlinks from other sites, referral or organic visits, or bookmarks and email links people still click. “Answers the same need” is the hard part, and it is where most redirect work goes wrong.
Google’s site move guidance says not to redirect many old URLs to a single irrelevant destination such as the home page, because it confuses users and can be treated as a soft 404. The exception it gives is consolidation: if several old pages were merged into one new page, redirecting them all there is fine.
Use these checks before writing a rule:
- Is there a real match? An old pricing page can go to the new pricing page. An old blog post about a discontinued product usually has no match.
- Does the target satisfy the same intent? If the visitor would be surprised by the destination, it is not a match.
- Does it justify the maintenance? Every rule is a line someone has to carry through the next migration. Google recommends keeping redirects for as long as possible, generally at least a year.
To check link value, export the 404 URLs and compare them against your backlink data and analytics. The 404s with no links and no visits are your ignore pile. Our what are backlinks guide covers what a link is worth, and the website migration SEO checklist shows how to build the redirect map up front so you never accumulate a pile in the first place.
Check internal linking too: a page that loses its only internal links is often orphaned long before anyone deletes it.
404 vs 410 vs soft 404
Use a real 404 for missing pages, a 410 for pages removed on purpose, and never serve a “not found” page that returns a 200. These are three different signals, and only the first two are healthy.
Google treats 404 and 410 alike. Its HTTP status documentation says all 4xx errors except 429 are handled the same way: the content is reported as not existing. MDN’s 404 reference draws the semantic distinction: a 404 does not say whether the absence is temporary or permanent, and servers should send a 410 for a permanent removal. For search, you gain little by switching. For other clients and for your own records, 410 is cleaner.
A soft 404 is the one to fix. Google’s page indexing documentation defines it as a page that shows a “not found” message to people but doesn’t return a 404 status. Google’s HTTP status documentation adds that Search Console also flags a soft 404 when a page’s content looks like an error or is empty.
| Status | What it tells clients | Search outcome | Use it when |
|---|---|---|---|
| 404 | Not found, permanence unstated | URL leaves the index | Default for removed pages |
| 410 | Gone for good | URL leaves the index | You deleted it deliberately |
| 301 | Moved permanently | Target replaces the old URL | A close equivalent exists |
| 200 with “not found” text | Page exists | Flagged as soft 404 | Never |
To test a suspected soft 404, run the URL through Search Console’s URL Inspection live test and compare what Google renders with what you expect. Redirecting dead URLs to the homepage creates the same problem from the other direction, as covered above.
A repeatable 404 triage routine
Treat 404 review as a recurring check, not a cleanup project. A routine keeps the list short enough to read, and it stops one-off noise from burying the URLs that matter. The diagram shows the five steps; the paragraphs below add the detail for each.
Scroll the diagram sideways to see all of it.
Collect from three places. Export the Not found (404) and Soft 404 lists from Search Console, crawl your current site for broken internal links, and pull 404 requests from your server logs. If you run a large site, the crawl budget guide explains why soft 404s and dead URLs in sitemaps cost crawling.
Group by pattern. Ten thousand 404s are often three patterns: an old directory, a retired file type, a tracking parameter. One rule or one decision handles a group. Do not review URLs one by one.
Score the groups. For each pattern, ask whether it has external links, search traffic or internal links. A group with none of the three goes to the ignore pile immediately.
Act in tree order. Fix sources first, redirect the valuable groups, leave the rest. If your XML sitemap still lists dead URLs, that fix is overdue regardless of anything else.
Verify. Re-crawl the fixed sections and test a sample of redirects with URL Inspection. Because Google keeps retrying remembered URLs, the Search Console list will not clear on your schedule. Judge success by what you chose to act on, not by an empty report.
Getting 404 handling right on your site
The right outcome is a short, boring 404 report: no broken internal links, no dead URLs in the sitemap, valuable old URLs redirected one to one, and a real 404 status wherever a page is truly gone. Everything else in the report is Google remembering your past.
Three habits keep it that way. Build a redirect map before any URL change, as laid out in our website redesign SEO guide. Re-run the triage after every migration or big content prune. And run the broader technical SEO audit checklist so 404s are judged alongside the issues that do block indexing.
If your site’s URL structure keeps producing 404s, the cause is usually how the site was built: routes tied to page titles, no redirect layer, a CMS that deletes without asking. We design those foundations into every build through our web development service, with URL rules and a redirect map in place before launch.
Frequently asked questions
How do I get rid of a 404 error?
It depends on why it exists. If the page should exist, restore it or fix the server rule that hides it. If a link or sitemap entry points at a dead URL, correct that source. If the page moved, 301 redirect it to the closest equivalent. If it was removed for good and nothing replaces it, leaving the 404 in place is a valid outcome.
Why am I getting so many 404 errors?
Usually for one of four reasons: a migration or URL change without redirects, internal links and sitemap entries pointing at removed pages, other sites linking to URLs that never existed or have since changed, and visitors or bots requesting made-up URLs. Group the URLs by pattern before judging. A few patterns usually explain most of the list.
Do 404 errors hurt SEO?
A 404 on a page that was removed with no replacement is not a problem in itself, and Google says so in its Search Console documentation. The damage comes from 404s on URLs that carry backlinks or traffic, from broken internal links, and from pages that should exist but return an error.
Should I redirect all 404 errors to the homepage?
No. Redirecting many dead URLs to the homepage gives visitors no answer, and Google's site move guidance warns it can be treated as a soft 404. Redirect a URL only when a close equivalent exists. Otherwise let it return a real 404 or 410.
Should I use a 404 or a 410 for deleted pages?
Either works for search. Google treats 404 and 410 the same way: both tell it the content does not exist, and URLs returning them are dropped from the index. MDN notes that a 404 does not say whether the absence is permanent, so a 410 is the more precise signal for content removed for good.
How long will Google keep crawling a 404 URL?
For some time, with decreasing frequency. Google's Search Console documentation says it keeps trying known URLs that return 404, and there is no way to permanently tell Googlebot to forget a URL. That is why a 404 report never fully empties, and why it is not a to-do list.