What to Do When Your Website Returns 404? A Detailed Guide to Dead Links, HTTP Status Codes, and SEO Impact

After a website redesign, you might delete old pages, change article URLs, or remove a product. When users click the original links, they often see 404 Not Found. A few 404s here and there aren't a serious problem. What really matters is when some 404s come from your own navigation, internal links, or sitemap, or when pages that were previously indexed by Google, had rankings, or even backlinks suddenly become 404 because URL changes weren't properly redirected.

There are also cases where a page no longer exists, but the server still returns a 200 OK. Users see "Page Not Found," but search engines receive "Page is fine." This is commonly referred to as a Soft 404.

When your site returns 404s, it's not enough to redirect all dead URLs to the homepage. A better approach is to first determine why the URL no longer exists and whether the original content has a new address. Then decide whether to restore the page, set up a 301 redirect, or leave it as a 404.

1. What Does a 404 on Your Website Mean?

A 404 is an HTTP status code. When a browser requests a webpage, the server uses a status code to tell the browser the result of the request. For example, a normal page usually returns 200, a permanent redirect returns 301, and when the requested page cannot be found, the server returns: 404 Not Found. This means: The server is accessible, but the requested page or resource cannot be found on the server.

You can think of the process like this:

User visits website
      ↓
Domain resolves correctly
      ↓
Server connection is successful
      ↓
Request for a specific page
      ↓
Content not found
      ↓
404 Not Found

A 404 is not the same as "the entire website is down." If the server is down, CDN origin fetch fails, or there's a gateway error, you'll typically see 500, 502, 503, 504, etc. A 404 is more related to a specific URL, file, CMS route, or deleted content. Here are some common HTTP status codes to help you distinguish:

Google also considers these status codes when processing web pages. If a previously accessible URL consistently returns 404, Google will gradually reduce how often it crawls that URL and eventually remove the non-existent page from its search index.

2. Why Do 404s and Dead Links Occur on Websites?

A 404 itself isn't complicated; the tricky part is figuring out why it happens. When maintaining a website, common causes include:

1. Page Deleted

This is the most straightforward case.

For example, your site had: /blog/old-article

Later, you deleted the article in the backend, but other parts of the site still link to it. Users clicking from related posts, navigation, or search results will get a 404. E-commerce sites often face similar issues. When a product is removed, the product page is deleted, but category pages, recommendation modules, old articles, or even the sitemap still reference the original URL, leading to many dead links over time.

2. URL Changed Without a Redirect

This situation usually has a bigger impact on SEO than simply deleting a low-value page.

For example, the original article URL was:

/blog/website-speed-test

Later, to adjust the URL structure, you changed it to:

/blog/site-speed-test

The new page works fine, but the old URL has no redirect configured.

Previously existing:

• Google search results;

• Internal links;

• User bookmarks;

• Social media shares;

• External links;

will still point to the old URL.

As a result, users who visit the old address will see a 404.

If the page has simply moved and the content still exists, Google recommends using a server-side permanent redirect to map the old URL to the new one.

3. Site Redesign or CMS Migration Changes URL Paths

Large-scale site redesigns are especially prone to 404s.

For example, the old site used:

/article?id=125

The new site uses:

/blog/125

If during migration you only imported content into the new system without mapping old URLs to new ones, you could end up with hundreds or thousands of 404s after launch.

Changing domains, restructuring categories, migrating from an old CMS to WordPress, or redesigning multilingual URL structures are all similar situations.

Therefore, when redesigning a site, you shouldn't only consider "can the new pages open?" but also how old URLs should redirect to new ones.

4. Incorrect Internal Links

A 404 doesn't always mean the page was deleted; it could be a typo in the link.

For example, the correct URL is:

/tools/ping

But an article mistakenly links to:

/tool/ping

Users clicking that link will get a 404.

This problem is common after manually adding internal links, bulk editing URLs, copying old articles, or restructuring site directories.

The fix is simple: find the incorrect link and change it to the correct URL. There's no need to set up a 301 for every misspelled internal link.

5. Deleted Images, JS, CSS, and Other Resources

404s don't only happen on web pages.

The following resources can also return 404:

/images/banner.jpg
/assets/main.js
/css/style.css
/download/file.pdf

When a user visits a page, the HTML might return a normal 200, but if the images or scripts referenced by the page no longer exist, you might see broken images, broken styles, or non-functional interactive elements.

So when checking for dead links, don't forget to check important images, JavaScript, CSS, and downloadable files, not just HTML pages.

3. Does a 404 Affect Google SEO?

Seeing dozens or even hundreds of "Not found (404)" errors in Search Console can make you think your site's SEO is in serious trouble, but there's no need to panic at the sight of a 404.

1. Normal 404s Don't Directly Cause a Site-wide Penalty

If a URL shouldn't exist in the first place—for example, a user mistypes an address like /example-abcdefg123—the server returning a 404 is perfectly reasonable. Similarly, if a page has been permanently deleted and there's no replacement content, returning a 404 is fine. Google has explicitly stated that, in general, 404 errors don't affect the search performance of the entire site. If you confirm that a URL shouldn't exist, you can leave it as a 404.

So the real question isn't "How do I make my site have zero 404s?" but rather "Which of these 404s are caused by my own site and are worth fixing?"

2. A Large Number of Internal Dead Links Deserve More Attention

Imagine your site's articles constantly have situations like:

Article A → 404
Article B → 404
Product page → 404
Navigation category → 404

Then it's not just about a status code. Users browsing your site will keep clicking on non-existent content, which hurts their experience. For search engines, these URLs are discovered through your own internal links, so Googlebot may repeatedly try to crawl them. Google's advice for Search Console is to prioritize fixing 404s that your site links to, and 404 URLs that still appear in your sitemap. So compared to random error URLs from the internet, internal dead links are clearly more important to fix.

3. Pages with Rankings and Backlinks Suddenly Returning 404 Need Extra Attention

Suppose an article has been published for two years:

• It ranks well on Google;

• It consistently gets organic traffic each month;

• Other websites link to it;

• Many internal articles reference it.

If you simply let the old page return a 404 just because you changed the URL, you'll waste the page's accumulated signals and user entry points.

If the original content has moved to a new URL, a better approach is:

Old URL
  ↓
301 Permanent Redirect
  ↓
New URL

Google has also clearly stated that permanent redirects like 301 can be used to tell search engines the new location of a page.

4. Don't Keep 404 Pages in Your Sitemap Long-term

One of the purposes of a sitemap is to help search engines discover important URLs you want crawled.

Therefore:

Sitemap
   ↓
Submit URL
   ↓
Google crawls
   ↓
404

This situation is contradictory: on one hand, you're telling Google "this page is worth crawling," and on the other, the server tells Google "this page doesn't exist."

After confirming a page is deleted, besides handling the URL itself, you should also check:

• XML Sitemap;

• Site navigation;

• Category pages;

• Related posts;

• Canonical tags;

• hreflang tags;

• Other internal links.

If there's a new replacement URL, update the sitemap and set up redirects. If the page is permanently deleted, remove the dead URL from the sitemap.

4. What's the Difference Between a Normal 404 and a Soft 404?

A normal 404 isn't scary; what's tricky is a Soft 404.

What is a Normal 404?

For example, a user visits:

https://example.com/old-page

The page no longer exists, and the server returns:

HTTP/1.1 404 Not Found

The browser then shows: Sorry, the page you're looking for doesn't exist. This logic is fine. The server and the user see the same thing: the page truly doesn't exist.

What is a Soft 404?

Another scenario: the page also shows "Sorry, the page you're looking for doesn't exist," but when you check the HTTP response, the server returns: HTTP/1.1 200 OK. This is more problematic.

From the page content, it's an error page; from the HTTP status, it tells search engines that the page exists normally.

Google calls this a Soft 404. Besides the typical "page not found but returns 200," pages with almost no content might also be considered Soft 404s by Google.

For example, a product has been deleted:

/product/123

The backend doesn't actually return a 404; instead, it generates a blank product page saying "Product not found."

The HTTP status is still:

200 OK

This is not ideal.

If the product is permanently deleted and there's no corresponding new page, the URL should return a real 404 or 410.

Conversely, if the page should still exist but is being misjudged as a Soft 404 because JavaScript, the database, or key resources aren't loading correctly, you should check the actual rendered page rather than deleting it.

Search Console's URL Inspection tool can show you the page status and rendered content that Google sees.

5. How Should You Handle a 404 Once You Find It?

When you find a 404, the most important thing isn't to immediately add a redirect, but to ask: Does the original content still exist? Different situations call for different approaches:

1. Page Just Moved: Use a 301

For example:

/blog/old-seo-guide
        ↓
       301
        ↓
/blog/new-seo-guide

When the old and new pages clearly correspond in content, a permanent redirect is the most appropriate.

In addition to search engines, users who saved the old link and visitors from other sites will also be taken directly to the new page.

2. Page Accidentally Deleted: Restore It

If a page that should exist long-term was accidentally deleted in the backend, and the original URL has accumulated rankings, traffic, and backlinks, there's usually no need to create a new URL.

If you can restore the original URL, doing so is often simpler.

3. Content Permanently Deleted: Return a Normal 404 or 410

For example, a temporary campaign page from years ago:

/2022-summer-promotion

There's no longer any corresponding campaign, and there's no suitable new content to replace it.

In this case, returning a normal 404 or 410 is fine.

Google currently treats these two statuses very similarly: if a page is truly permanently gone and there's no suitable replacement, both 404 and 410 are valid responses.

4. Don't Redirect All 404s to the Homepage

This is a common mistake when handling dead links.

To make the number of 404s in monitoring tools zero, some sites set up:

All 404 pages
      ↓
     301
      ↓
     Homepage

On the surface, the 404s disappear, but the problem isn't really solved.

For example, a user is looking for:

/product/iphone-case

They're unexpectedly sent to the homepage, where they can't find the original content or know what to do next.

Google also explicitly warns against redirecting many old URLs to a page that's irrelevant to the original content, such as a blanket redirect to the homepage. These irrelevant redirects may be treated as Soft 404s.

So a 301 isn't a "tool to eliminate 404s."

It's truly appropriate when:

The old page has moved, and there's a relevant new URL with related content.

If there's no suitable replacement, letting the URL return a 404 is actually cleaner.

6. How to Check for Dead Links and 404s on Your Site

For a small site with only a few dozen pages, you can manually click through and check.

But if your site has hundreds, thousands, or even tens of thousands of URLs, you can't rely on manual checks.

1. First, Confirm What Status Code a Specific URL Actually Returns

If a user reports that a page won't open, don't jump to conclusions just because you see "404" text on the page.

What you really need to confirm is the HTTP status returned by the server.

Because a page showing "Page Not Found" doesn't necessarily mean the status code is 404.

It could actually be: 200, 301, 404, 410, or 500.

Especially with custom error pages, SPAs, and some CMSs, pages may look the same but return different statuses.

2. Use Google Search Console to Check 404s Found by Google

If your site is connected to Google Search Console, you can view the "Not found (404)" and "Soft 404" errors that Google discovered during crawling in the Page Indexing report.

For individual URLs, you can also use URL Inspection to check:

• Google's last crawl;

• Whether the page is currently accessible;

• Whether indexing is allowed;

• The actual returned status;

• The page content as seen by Google.

When you see a list of 404s, don't mechanically process them all.

Go through each one and ask:

Should this page exist?

If the answer is no, and there are no internal links pointing to it, that 404 probably doesn't need any action.

If the page should exist, or the URL still appears in your sitemap, navigation, or article links, then investigate further.

3. Bulk Check Internal Dead Links

For sites with many pages, a more effective method is to crawl the entire site starting from the homepage or sitemap.

The basic logic is:

Homepage
   ↓
Category pages
   ↓
Articles / Products
   ↓
Crawl internal links
   ↓
Check HTTP status codes
   ↓
Filter 404s

Focus on: header and footer navigation; internal links in articles; product recommendations; breadcrumbs; category pages; image URLs; downloadable files; sitemap.

If a 404 URL is referenced by dozens of articles, it should clearly have higher priority than a random error URL that never appeared on your site.

4. Use Chahu to Continuously Monitor Important Page Status

If you just need to check a page temporarily, you can directly confirm its current HTTP response. For important URLs like your homepage, login page, payment page, or API, continuous monitoring is more appropriate.

Chahu Website Monitoring supports HTTP(S) page and API status checks, continuously recording response status and response time, and allows you to set conditions based on expected status codes.

For example, a core page that should always return:

200 OK

might suddenly start returning:

404 Not Found

due to a mistake. Continuous monitoring can often catch issues sooner than waiting for users or search engines to notice. However, for checking dead links across thousands of URLs, the core approach should still be site crawling and internal link checks, rather than adding every ordinary page to monitoring.

For long-term site maintenance, a 404 itself isn't the biggest SEO problem; mishandling 404s is. Use Chahu to regularly check your site's internal links, Sitemap, and Search Console. Making it clear to users and search engines which content still exists, which has moved, and which has been permanently deleted is more meaningful than simply aiming for "zero 404s."

Related Q&A

1. What should I do if an old link referenced by an external high-authority site returns a 404, but there's no exact replacement page?

If you can't restore the original page and there's no 100% matching replacement, do not redirect it to the homepage (Google may treat it as a Soft 404 and discard the link equity). Instead, consider a 301 redirect to the parent category page where the content used to live, or to the most topically relevant article or product page. This preserves as much of the link juice from external backlinks as possible while providing users who click those links with relatively relevant context, reducing bounce rates.

2. After setting up a 301 redirect, how long does it take for Google to update its index and transfer rankings?

This depends on how often Googlebot crawls your site and the authority of the URL. For high-authority, frequently updated pages, Google may crawl and start transferring the index within a few days to a week. For deep or low-authority URLs, it could take weeks or even months. During this period, Search Console may show data for both the old and new URLs, which is normal. To speed things up, you can manually submit the old URL for "URL Inspection" in Google Search Console and request recrawling, while ensuring your XML sitemap has been updated to the new URL.

3. If my site suddenly gets a large number of random 404 URLs caused by malicious scanning, will it affect my site's authority?

No need to worry at all. Hacker tools and automated scripts on the internet often scan for common backend paths or non-existent files (like /wp-admin/, /.env, /shell.php, etc.). Google's algorithms are smart enough to recognize these as meaningless external random requests. As long as these URLs don't appear in your internal links, navigation, or sitemap, just let the server return a standard 404 or 410. Google will stop trying to crawl these non-existent paths after a few failures and will never penalize your site for them.

4. If I accidentally deleted an important page and then restored it with a 200 status, can I recover my old search rankings?

Yes, but it depends on how quickly you restore it. If the page was deleted for a short time (e.g., a few days), Googlebot may not have fully removed it from its index. After restoring the page and resubmitting it for crawling, rankings can often recover quickly. However, if the page has been returning 404 for weeks or months, Google may have completely released the page's rankings and authority. In that case, even if you restore the original URL and content, Google will treat it as "new content" and re-evaluate it, so rankings may take a long time to rebuild.

5. After setting up a 301 redirect from an old URL to a new one, how long should I keep the redirect rule?

Google recommends keeping it for at least one year. Although Google may transfer most of the index and authority to the new URL within a few months, there may still be user bookmarks, outdated external backlinks, and third-party references on the web. Keeping the redirect rule active long-term (or even permanently) not only consolidates the link equity from these historical backlinks but also ensures that users coming from these old entry points always have a smooth experience.