Do 404 Errors Hurt SEO?

Michel Bardelmeijer is Tech Lead and Sales at redirect.pizza, where he helps DevOps and IT teams solve domain redirect challenges at scale. Michel has guided organizations like SD Worx, Zurich Airport and Harvard through complex redirect scenarios involving thousands of domains.
Have questions about bulk redirects, HTTPS migrations, or domain consolidations? Connect with Michel on LinkedIn or reach out to the redirect.pizza team.
404 errors do not directly hurt your search rankings. What hurts is losing the traffic and link equity those broken URLs were carrying.
Google's documentation is clear: "404 errors are a perfectly normal part of the web." John Mueller reiterated it in 2025: a 404 is not a quality signal, not a ranking signal. Search engines expect pages to come and go.
That answers a technical question. But it is probably not the question you are asking. When you shut down a domain, finish a rebrand, or delete a section of your site, the question in your head is not "what HTTP status code should I return?" It is: am I losing traffic and authority? The answer is yes, and the loss is progressive. A 404 status code does not hurt your rankings directly. The decision that created the 404 might.
This article covers when 404 errors actually cost you something, when they are harmless, and what to do when hundreds of them appear at once. For a broader look at how redirects work across different scenarios, see our complete guide to URL redirects.
Key Takeaways
- A 404 status code is not a direct ranking penalty. Google treats them as a normal part of the web. But the traffic and authority you lose behind those 404s is real.
- Soft 404s are worse than hard 404s. They waste crawl budget and pollute your index with empty pages.
- When you decommission a domain without redirects, the damage cascades over months: direct traffic first, then rankings, then backlink equity, then long-tail referrals.
- Your registrar's built-in forwarding typically lacks path forwarding and analytics, which limits its usefulness for anything beyond simple root-domain redirects.
- Not every 404 needs a redirect. Typo URLs and pages that never existed should stay 404.

What is a 404 error?
A 404 is an HTTP status code that means the server received your request but could not find the page you asked for. The connection itself works fine. The domain resolves, the server responds. There is just nothing at that specific URL.
404 errors show up for four main reasons: a page was deleted, a URL was changed without setting up a redirect, an entire domain was decommissioned, or an external site links to a path that never existed in the first place.
There is an important distinction between a hard 404 and a soft 404. A hard 404 returns the correct HTTP status code (404 or 410) and tells search engines there is nothing here. That is the right behavior. A soft 404 is more problematic: the server returns a 200 OK status code, but the page itself is empty, shows a generic error message, or has no meaningful content. Google detects these through content analysis and flags them separately in Google Search Console. We will cover why soft 404s are the bigger SEO problem in a later section.
You can find your site's 404 errors in Google Search Console under Pages > Not found (404). GSC also reports soft 404s as a separate category.
The real question: do you lose traffic and authority?
Google's documentation says 404 errors are normal. Mueller, in a 2025 LinkedIn post, called them "not a quality signal, not a SEO signal" and said it is "significantly better to serve a 404 than a 200 for a page that doesn't exist." On a technical level, that is correct. A 404 status code does not trigger a penalty or lower your site's quality score.
But Mueller also wrote something else in that same post: "Most 404s are a result of poor planning. Unnecessary replatforming. Gratuitous URL changes." He was not saying 404s are harmless. He was saying the decisions that create them are the problem.
The distinction matters. A 404 on a page that never existed, or a URL someone mistyped, costs you nothing. A 404 on a page that had 50 referring domains and ranked on the first page for a competitive keyword costs you everything that page had earned.
For a broader look at how redirects themselves affect search performance, see Are Redirects Bad for SEO?. Here, we are focused specifically on the 404 side: what happens when a redirect is missing.
Three scenarios, in order of severity:
Page deleted, no backlinks, no traffic. No impact. This is the correct use of a 404. Google drops the page from the index and moves on.
Page deleted, has backlinks. The link equity flowing to that page stops accumulating. How much that matters depends on the number and authority of the referring pages. A page with 3 backlinks from low-authority blogs is not urgent. A page with 40 backlinks from industry publications is.
Domain decommissioned without redirects. This is where it gets expensive. Every URL on the old domain returns a 404. Every backlink, every bookmark, every indexed page points to nothing. The next section explains what happens and how fast.
What happens when a domain goes dark: the 404 waterfall
When you decommission a domain without setting up redirects, the damage does not happen all at once. It cascades. The exact speed varies by site, but the sequence is predictable.
Direct traffic goes first. Within days, anyone who had the old domain bookmarked, saved in an email, or printed on a business card hits a browser error or a registrar parking page. Think of every QR code on last year's packaging, every link in your investor deck, every email signature from a former employee. All of them still point to the old domain. Those were people who already knew you. Gone.
Then rankings. Google's crawler visits your old URLs, sees 404s, and starts pulling pages from the index. Mueller noted in 2025 that Google "gradually reduces crawl frequency" for URLs returning 404, so this is not a single event but a slow drain. High-authority sites that Google crawls daily lose rankings fast. Smaller sites bleed out over weeks. Either way, organic traffic to the old domain trends toward zero.
Backlink equity follows. External sites that linked to your content are now sending visitors to a dead page. The link equity those backlinks carried stops flowing. This is the part most people underestimate, because you cannot see it happening in real time. There is no alert. Your authority just quietly erodes.
The long tail takes months. Forum posts, Stack Overflow answers, PDF whitepapers, internal wikis at client organizations, documentation from partners. These links broke on day one, but the volume per individual link is so low that you do not notice the loss until months later, when the cumulative total becomes visible in your analytics. By month six, Google has typically removed the remaining indexed pages. The old domain is gone from search results entirely.
Some of this damage is permanent. Quality-conscious sites run link checkers and eventually remove or update links to dead domains. Once they do, that equity is gone for good, redirect or not. Most sites never bother, which means most of your backlink equity is still sitting there, waiting to be recovered. But every week you wait, the window gets a little smaller.
When to redirect a 404 (and when to leave it)
Not every 404 deserves a redirect. The decision depends on what was behind the URL before it broke.
| Situation | Action | Why |
|---|---|---|
| Page moved to a new URL | 301 redirect to the new URL | Preserves link equity, user experience, and rankings |
| Page deleted, has backlinks | 301 redirect to the most relevant remaining page | Captures the link equity that would otherwise be lost |
| Page deleted, no backlinks, no traffic | Leave as 404 | Correct signal to search engines. Nothing of value to preserve |
| Content permanently removed, no replacement exists | 404 or 410 | Google treats both identically. 410 documents your intent more explicitly for your own team |
| Entire domain decommissioned or rebranded | Bulk 301 redirects | Without this, you get the waterfall described above |
| Typo URLs, never existed | Leave as 404 | No action needed. These are not real pages |
| Redirect everything to the homepage | Never do this | Google detects the content mismatch between what the linking page expected and what it finds. At scale, this is treated similarly to soft 404s and the redirects are effectively ignored |
That last row is worth emphasizing. We see this pattern constantly: a company migrates to a new domain and redirects every old URL to the new homepage because it is the fastest thing to configure. Three months later they wonder why their organic traffic did not transfer. It did transfer. Google just ignored the redirects because they all pointed to the same page regardless of what the original content was about.
For a detailed comparison of 301 vs 302 redirect behavior, see 301 vs 302 Redirects: Which Should You Use?
Soft 404s: the actual SEO problem
If hard 404s are the correct response to missing content, soft 404s are the problematic one. A soft 404 occurs when a server returns a 200 OK status code for a page that has no meaningful content. The page might show a generic error message, a "coming soon" placeholder, or an empty template. To the browser and to Google's crawler, the 200 status code says "this page exists." But when Google analyzes the content, it finds nothing useful.
This creates three problems. First, crawlers keep visiting the page because the status code tells them it is live. That wastes crawl budget that could be spent on pages with actual content. Second, the page may get indexed, cluttering your search results with empty entries. Third, Google Search Console flags it as a "Soft 404," which means Google has identified a disconnect between the status code and the content.
The most common causes of soft 404s are custom 404 pages that return a 200 status code instead of an actual 404, "coming soon" or "under construction" placeholder pages, empty category pages with no products, and mass-redirecting deleted pages to the homepage. The first one is the sneakiest: your designer made a beautiful 404 page with helpful links and a friendly illustration. Your server is returning a 200 for it. Google thinks it is a real page with almost no content. That last one also deserves attention: when Google sees dozens or hundreds of unrelated URLs all redirecting to the same homepage, it detects the content mismatch between what the linking pages expected and what the homepage actually offers. The redirects are treated similarly to soft 404s and largely ignored.
The fix is straightforward: make sure your server returns the correct status code. Pages that do not exist should return 404 or 410, not 200. Check Google Search Console under Pages > Soft 404 to find affected URLs, and use the URL Inspection tool to verify the status code Google sees for individual pages.
Fixing 404 errors at scale
When a single page returns a 404, the fix is simple: set up one redirect or remove the broken link. When an entire domain is decommissioned or rebranded, you might be looking at hundreds or thousands of URLs that all went dark at once. The waterfall has started. Here is how to stop it.
Step 1: Build your URL inventory. You need a complete list of URLs that existed on the old domain. If the domain still resolves, crawl it with a tool like Screaming Frog. If hosting is already shut down, use your most recent crawl export, a sitemap backup, or the Wayback Machine. Google Search Console's Links report also shows which external sites linked to which pages on the old domain.
Step 2: Map old URLs to new destinations. Not every URL needs a one-to-one mapping. Group by section: all /blog/ URLs redirect to /blog on the new domain, all /product/ URLs redirect to /products, and so on. Prioritize URLs that have backlinks. Those carry the most recoverable equity.
Step 3: Implement bulk redirects. This is where most people run into their first problem.
Why your registrar's forwarding probably won't work
The obvious first move is to enable forwarding at your domain registrar. GoDaddy, Namecheap, Hover, and most other registrars offer this as a built-in feature. It seems like the simplest solution. For simple root-domain redirects, it can work. For anything more complex, it breaks down.
No path forwarding at most registrars. When someone visits example.com/blog/your-best-post, registrar forwarding typically sends them to newdomain.com, not to newdomain.com/blog/your-best-post. The path is discarded. For one or two vanity domains, that might be acceptable. For a site with hundreds of indexed pages, every one of those paths now lands on a homepage that has nothing to do with what the visitor was looking for. Google treats this pattern similarly to soft 404s at scale.
No analytics. Registrar forwarding gives you no visibility into how much traffic passes through, which old paths still get visits, or whether the redirect is working at all. You have no way to tell if 10 people a month or 10,000 are hitting the old domain.
Limited subdomain support. Many registrars do not support forwarding for subdomains like blog.example.com or shop.example.com. If your old site used subdomains, those paths simply stop working. For subdomain-specific redirect strategies, see How to Redirect a Subdomain.
Inconsistent HTTPS support. Some registrars have added SSL support for forwarded domains, but the implementation varies. If your old URLs used HTTPS and the registrar does not provision a valid certificate for the forwarded domain, the redirect fails silently or visitors see a certificate warning before the redirect can fire. For registrar-specific details, see our setup guides for GoDaddy, Hover, and Network Solutions.
"The reason most registrars can't do path forwarding is architectural," says Michel Bardelmeijer, Tech Lead at redirect.pizza. "Their forwarding service is a simple HTTP-level redirect on a shared IP. It has no concept of paths, no certificate management per domain, and no logging layer. Building that infrastructure is a different product entirely, and it's not one registrars are incentivized to build."
For a detailed comparison of domain forwarding methods and their limitations, see our domain forwarding guide.
Three methods for bulk domain redirects
If registrar forwarding is not sufficient, three methods can handle domain-level redirects at scale:
| Server-side (.htaccess / nginx) | DNS-based redirect service | Cloudflare Redirect Rules | |
|---|---|---|---|
| Requires active hosting | Yes | No | No (but requires Cloudflare DNS) |
| HTTPS on old domain | Manual (own certificate) | Automatic (certificate provisioning) | Automatic (Cloudflare certificate) |
| Path forwarding | Yes (regex capable) | Yes (depends on service) | Yes (expression matching) |
| Bulk import | Config file editing | CSV upload | Bulk Redirects list |
| Works after hosting cancellation | No | Yes | Partially (DNS must stay on Cloudflare) |
| Per-redirect analytics | No (server logs only) | Depends on service | No |
Server-side redirects give you the most control, but they require active hosting on the old domain. If you have already cancelled hosting, that option is gone.
DNS-based redirect services provision SSL certificates automatically for the old domain, support CSV bulk imports, per-redirect analytics, and continue working after you cancel hosting. That makes them practical for domain decommissions where server-side redirects are no longer an option. redirect.pizza is one example.
Cloudflare's Redirect Rules work well if your DNS is already on Cloudflare. The free tier includes limited redirect rules, and the Bulk Redirects feature supports URL-level mappings at scale. The constraint is that your domain's DNS must remain on Cloudflare for as long as the redirects need to function.
The method matters less than the timing. Get 301 redirects in place before the waterfall progresses further than it already has. For step-by-step instructions, see our domain redirect setup guide. For migration planning, see the domain migration SEO checklist.
Frequently Asked Questions
No. When Google sees hundreds of unrelated URLs all redirecting to the same homepage, it compares the homepage content to what each linking page expected to find. The mismatch tells Google these redirects are not genuine replacements, so it treats them similarly to soft 404s and largely ignores them. Instead, redirect each deleted URL to the most relevant remaining page on your site. If you have a large number of URLs, group them by section: redirect all old /blog/ URLs to your blog index, all old /product/ URLs to your products page. Use path-based redirect rules or regex patterns to handle this in bulk. If a deleted page truly has no relevant replacement anywhere on your site, leave it as a 404. That is the correct signal.
A soft 404 is a page that returns a 200 OK status code but has no meaningful content. Google detects soft 404s through automated content analysis. It evaluates factors like word count and content substance, checks for known error page templates and phrases like "page not found," and compares the page content to what it expects based on inbound links and the URL pattern. Pages that fall below Google's content quality bar or match error page signatures are flagged as soft 404s in Google Search Console, even though the server technically reports them as live pages.
Start with the 404s that are costing you the most. Export the full 404 list from Google Search Console under Pages > Not found. Cross-reference that list with your backlink data from a tool like Ahrefs or the Links report in Google Search Console. Sort by the number of referring domains. Fix the top 20 URLs with the most backlinks first, since those carry the most recoverable link equity. After that, check which 404 URLs still generate impressions in GSC. Those pages still appear in search results and are actively losing clicks.
At minimum, one year. Ideally longer. Google consolidates link signals over time, but external links in PDFs, printed materials, documentation, forum posts, and internal wikis at other organizations are rarely updated. As long as referral traffic is still coming through the redirect, it is doing its job. With a dedicated redirect service, the ongoing cost of maintaining the redirect is typically negligible compared to the value of the traffic and link equity it preserves.
Hard 404s do not waste crawl budget. When Google's crawler encounters a proper 404 or 410 response, it quickly reduces the crawl frequency for that URL and eventually stops visiting it. In that sense, a hard 404 actually helps your crawl budget by telling Google not to come back. Soft 404s are the opposite: because the server returns a 200 status code, Google's crawler treats the page as live and keeps revisiting it. If you have hundreds of soft 404s, that is crawl budget being spent on pages with no content instead of on pages you actually want indexed. Fixing soft 404s by returning the correct status code is one of the most direct ways to improve crawl efficiency.
