How to Fix 404 Errors in Google Search Console

← Google Search Console Indexing Statuses

In Google Search Console, "Not found (404)" means Googlebot requested a URL and got a 404 code back. Not every one needs fixing: a 404 on a spam URL you never created is normal. The right move isn't to fix everything, it's to triage: ignore it, return a 410, redirect with a 301, or restore the page.

In Google Search Console's Page Indexing report, "Not found (404)" looks like a list of errors to clear. It rarely is. Most 404s are fine, and some are exactly what Google wants: a deleted page should return a 404. As many rows as there are errors to fix, the intuition goes. That intuition is wrong.

So the hard question shifts. Which of these URLs actually deserves action? And for that one, should you redirect it, let it die cleanly, or restore it? And, most of all, why isn't the 404 that costs you the most traffic even in the 404 report?

The job isn't the list, it's the triage. The hard part isn't fixing a 404, it's finding which one to fix.

"Not found (404)": what Google is actually reporting

"Not found (404)" means Googlebot requested a URL and your server answered with an HTTP 404 code. The page doesn't exist. Google won't index it, and drops it from the index if it was there. It's a raw technical fact, not a severity rating: the status describes a server response, it says nothing about how important the lost page was.

Set it apart right away from a case that looks similar: the Soft 404. There, the server returns a 200 code ("the page exists") while the page is empty or carries no real value. Google catches the mismatch and flags it under its own status. A "hard" 404 sends the right code; a Soft 404 lies about its own state. The two problems have neither the same cause nor the same fix. We come back to Soft 404 below, and the dedicated article on the Not found (404) status walks through reading the report itself.

Is a 404 always a problem?

No, and that's the point most audits miss. Google is explicit: "404 responses are not necessarily a problem, if the page has been removed without any replacement." A page you deliberately deleted returns a 404, and that's the expected behavior. Google's own John Mueller has said many times that 404s are part of how a normal site works: their mere presence in the report calls for no fix at all.

The useful distinction isn't "404 or not 404," it's "harmless 404" versus "costly 404."

A normal, zero-cost 404 is a URL no one important references anymore:

• a spam URL, or one invented by a scraper, that you never created;
• a typo in a link someone placed on another site;
• a page you deliberately deleted, with no equivalent, that has no reason to exist.

A costly 404 is the opposite: a page that had value and disappeared.

• A useful page lost by accident: an unintended deletion, a URL changed without a redirect, a failed deploy. It had traffic, links, rankings.
• A 404 your own site still points to: a live internal link, or an entry still sitting in your sitemap. You're sending visitors and Googlebot into a dead end.

That second group is exactly the one Google recommends you handle. Its guidance is blunt: "In general, we recommend fixing only 404 errors that you link to yourself or list in a sitemap." Everything else can stay as it is.

What causes a 404

A 404 always has a precise technical origin, and that origin dictates the fix. The causes sort best by how actionable they are: the ones that come from your own site, which you can fix, and the ones manufactured elsewhere, over which you have no control.

From your own site (worth fixing)

• Deletion without a redirect. You pull a page that had an equivalent, without pointing a redirect to it. The 404 becomes an avoidable dead end.
• Broken internal links. A link in your content points to a wrong URL (a typo, an old structure). The target doesn't exist, even though a good page may sit right next to it.
• Broken redirects. A redirect chain whose final destination has itself been deleted. The visitor hops through redirects only to land on a 404.

From the outside (often safe to ignore)

• Broken backlinks. Another site links you with a stale or mistyped URL. You don't control that link, but if it pointed to a useful page, you can recover its value with a redirect.
• URLs never created, spam, external typos. Invented addresses, variants generated by bots. The 404 is the correct answer here: nothing to fix.

One last case is worth naming without dwelling on it: some pages surface not under "Not found (404)" but under "Blocked due to other 4xx issue" (codes 401, 403, and so on). It's a neighboring status with its own rules, one we'll cover in a future article.

Soft 404: the 404 disguised as a valid page

A Soft 404 is a page that answers with a 200 code ("all good") while its content actually signals an absence. Google treats it as a 404 because it brings nothing, but it doesn't show up in the "Not found (404)" report: it has its own status.

The classic triggers:

• an empty category or results page ("no products in this section") that still returns a 200;
• an error-message page ("this listing no longer exists") served with a 200 code instead of a real 404;
• a client-side rendered page (JS/CSR) whose content never loads for Googlebot, so all it sees is an empty shell. Google's documentation notes that a SPA handling errors in JavaScript often "report a 200 HTTP status code instead of the appropriate status code," which can get error pages indexed.

The principle is straightforward: pages that genuinely don't exist should return a real 404, not a 200. Serving a 200 on an empty page creates more confusion than an honest 404. The full mechanism, its causes and its fixes are covered in the Soft 404 article.

The decision tree: ignore, 410, 301, or restore

For every 404 that deserves your attention, only four outcomes. The right choice depends on what the page was and what replaces it, not on one rule applied uniformly to the whole list.

1. Ignore it. The page has no equivalent and no residual value, and no one important points to it anymore. Leave the 404: it's the correct answer. Forcing it out of the report achieves nothing.
2. Return a 410 (Gone). The page is permanently and deliberately deleted, and you want to say so without ambiguity. A 410 asserts the intent to delete.
3. Redirect with a 301. The page has a genuine equivalent. A 301 redirect to that equivalent passes both visitors and signals to the right destination.
4. Restore it. A useful page disappeared by mistake. Put it back online at the same URL.

On the 404-versus-410 choice, keep a sense of proportion. In practice, Google treats all 4xx errors the same way: in both cases the URL ends up deindexed and the content is no longer used. A 410 simply says "gone for good" more explicitly. Reserve it for deliberate, owned deletions (old promotions, items discontinued in batches). For everything else, a 404 by default is perfectly fine. There's no point in mass-migrating your dead pages to 410: the gain is marginal and the effort is real.

This tree is easy to run on five URLs. The difficulty starts when the report holds hundreds.

Triaging your 404s at scale

Triaging hundreds of 404s comes down to cross-referencing three pieces of information per URL: its past traffic, the internal links it still receives, and whether or not it sits in your sitemap. That cross-reference is what files each 404 into a branch of the tree. The catch is that Search Console's URL Inspection tool handles one URL at a time: you inspect, you read, you move to the next. On a handful of addresses, that's workable. Past that, manual triage becomes impractical.

That's the wall IndexProbe breaks: the bulk version of Google's URL Inspection tool. It queries the official Search Console API to inspect, in a single analysis, the list of URLs you give it (CSV import, sitemap, paste) or the one you build from your own Search Console. For each URL, it returns the official crawl code Google holds on record (404, 410, 200, redirect) and the date Googlebot last visited. At a glance, you tell apart the URLs genuinely returning 404, the ones answering 200 again after a fix, and the ones now pointing to a redirect.

Sample data (10,000 fictional URLs). Crawl-code breakdown per URL, including the share of 404s | IndexProbe view.

But triage doesn't stop at crawl codes. The 404 most dangerous to your traffic isn't in the 404 report at all. It's a page that still answers 200, that had clicks in Search Console, and that has no recent impressions. Technically, it never returned a 404: no error report flags it. Yet it has stopped ranking, which betrays a likely drop from the index, a silent regression. That's the kind of signal an HTTP-code sort never surfaces, and that cross-referencing past clicks against recent impressions brings to light.

What you get out of the analysis depends on the list you bring in. IndexProbe doesn't crawl your site to discover URLs: it inspects the ones you give it, and only those.

• A selection of strategic pages (your key pages, your sitemap of pages meant to be indexed). Any important page that comes back 404 is an immediate signal: a useful page gone, to restore or to redirect to its equivalent. No extrapolation needed, the verdict lands on pages whose value you already know.
• A full export of your URLs (entire sitemap, crawl export). The breakdown by page type shows where the 404s concentrate (an old blog, a removed product family) and steers a decision per segment rather than case by case.

Sample data (full URL export analysis). 404 concentration by URL segment | IndexProbe view.

Fixing it: the right action per the tree's verdict

Once your 404s are triaged, apply the action that matches each case. Here are the four situations and their fix.

1. Wrong internal link → fix the link's URL to the right page. The target already exists; only the link was wrong.
2. Moved page → set a 301 redirect to the real equivalent, and check that no redirect chain sits in between. A redirect pointing to another redirect dilutes the signal and slows the crawl; aim for the final destination in a single hop. The related status is covered in Page with redirect.
3. Permanently deleted page → leave the 404, or return a 410, then remove the URL from your sitemap and your internal links. As long as an internal link or a sitemap entry points to the dead page, you keep sending Googlebot to it.
4. Useful page lost → restore it at the same URL. Bringing the original address back recovers the links and rankings the page had earned.

One trap to call out without appeal: never redirect a deleted page to the homepage "to recover the link juice." Google treats a redirect to an unrelated page as a Soft 404: you swap an honest 404 for another problem, and the hoped-for benefit never materializes. A redirect is only justified to a real equivalent.

On the CMS side, the mechanics vary but the logic holds. On WordPress, a redirect plugin (or the .htaccess file) handles the 301s, and you still need to clean up the internal links inside your posts. On Shopify, the built-in URL redirect tool covers deleted products and collections. On Magento, the URL rewrite rules and the handling of disabled products drive the 404 behavior and the redirects. In every case, the decision tree comes before the tool: you pick the action first, then apply it with whatever the CMS provides.

Confirming the fix held

Fixing isn't enough; you have to confirm Google took note. After your changes, request a re-crawl of the URLs you handled in Search Console, then track how things move over time: moved pages should answer with a 301 to their equivalent, restored pages should return to 200 and rejoin the index, and still-linked 404s should leave your sitemap and your links. A single analysis won't tell you that; it's the comparison between a before state and an after state that proves it.