What Is a 404 Error?

Code 404 belongs to the 4xx family, which groups failures that originate in the client's request, with one key difference from a 400 error: with a 400, the request itself is malformed and the server never even attempts to look for the resource. With a 404, the request arrives fine, the server processes it, and confirms there is nothing at that URL.

It is also the exact counterpart to a 500 error. In a 500, the server fails while trying to respond; in a 404, the server works fine and answers normally, only the answer is "there's nothing here." That distinction matters for diagnosis: a spike in 404s does not mean the server went down, it means links or URLs are pointing at pages that no longer exist.

The most common causes are simple: a page gets deleted without leaving a redirect, someone mistypes a URL, content moves to a new address without the internal links being updated, or a domain migration breaks routes that used to work. In every one of these cases, the server itself is not at fault. It simply cannot find the resource being asked for.

Not every "not found" case should be handled the same way. The table compares a 404 against the most common alternatives, including the tricky soft 404 case.

The soft 404 is the most dangerous case because it goes unnoticed: the page visibly says "no results found" or similar, but the server responds with 200, as if the content were valid. Google still treats these pages as 404s for indexing purposes, but the site owner often does not see it that way in their own logs, which delays detection.

When a browser or a crawler requests a URL, the server processes it and looks for the matching resource. If the request is well formed, which covers the vast majority of 404s, the server reaches the resource-lookup stage and discovers there is nothing at that route. It then returns status 404, along with an error page, either a custom one or the server's generic default.

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:18:47 GMT

Googlebot gets the same 404 any visitor would, and interprets it consistently: it tells the rest of the indexing system that the content does not exist. If the URL was indexed, the system removes it from the index over time; if Google encounters it for the first time as a 404, it never processes it at all. Crawl frequency for that route drops gradually the more the error repeats, a different pattern from a 500 error, where Google tends to retry the URL a few times before pulling back on crawling, on the assumption the failure might be temporary.

A soft 404 breaks that logic, because the HTTP code says "everything's fine" (200) while the content says the opposite. Google catches the contradiction by analyzing the actual page content, not just the status code, and ends up treating the page as a 404 in Search Console even though it technically never returned that code. The practical outcome is the same as a real 404: the URL does not get indexed, or gets removed if it already was.

A single 404 does not hurt the rest of the domain's rankings; it is a normal part of running a website and Google expects it. The problem shows up in two specific scenarios. The first is when a URL that used to rank and carried links, internal or external, starts returning 404 without a redirect to pass that authority along: the value of those links is lost instead of moving to a live page.

The second is volume. A large accumulation of 404s, especially ones Googlebot finds through broken internal links, eats into crawl budget that could be spent on pages that actually matter. It does not sink the ranking of the whole site, but it can slow down how quickly new or updated content gets discovered.

Search Console shows 404s as their own category, "Not found (404)," inside the Page Indexing report, something neither a 400 error nor other client errors get: those land bundled into a generic bucket. That makes it easy to review the full list of affected URLs without cross-checking against server logs, something that is actually necessary to diagnose a 400 or a 500 error.

• Check the "Not found (404)" category in Search Console's Page Indexing report regularly, not just after a migration.
• Apply a 301 redirect to a page with equivalent content, never to the homepage by default: a generic redirect confuses both the user and Google about what they actually landed on.
• Design a custom 404 page with internal search and links to key sections, for the cases where no equivalent URL exists to redirect to.
• Audit internal links after any structural change or migration, before Googlebot finds them broken on its own.
• Confirm that "no results" templates (internal search, product filters with no matches) return a real 404 instead of 200, to avoid creating a soft 404.
• Treat 404 monitoring as a fixed part of a site's technical SEO, not a one-off task after a launch.

• Redirecting every 404 to the homepage instead of to a page with related content.
• Leaving an empty-results template returning 200 instead of 404, creating a soft 404 without realizing it.
• Ignoring 404s on URLs with no current traffic, when some of them still carry valuable external links.
• Confusing a 400 error with a 404 during diagnosis, when the underlying cause is different in each case.
• Assuming a spike in 404s means a server-side problem like a 500 error, instead of checking internal links and crawl sources first.