404 Not Found Site: Fix Guide

A "404 not found" that hits your whole site, or a large share of its URLs, is a different problem from one broken link. When many pages return 404 at once, the cause is usually server side: a bad deployment, a misconfigured server, or a domain that no longer points where it should. This guide focuses on site wide 404 patterns, what they cost you in search, and how to fix them fast.

What "404 not found" means at the site level

The 404 status code is a standard client error response. Per the HTTP specification documented in MDN's 404 reference, it means the server could not find the requested resource, without saying whether the absence is temporary or permanent. For a permanently removed resource, the correct code is actually 410 Gone. A single 404 is normal internet housekeeping. The alarm bell is scale: when a whole section, a whole template, or the entire domain starts returning 404, something structural has broken.

Site wide 404s tend to look like one of these patterns:

• Every URL on the domain returns 404, including the homepage.
• A whole content type breaks at once, for example every blog post or every product page.
• URLs that worked yesterday return 404 today with no content changes, pointing to a deployment or config event.

Common causes of a site wide 404

When many URLs fail together, work through these usual suspects:

1. A broken deployment. A release that changed the routing, deleted a build folder, or shipped a bad rewrite rule can 404 everything at once. This is the most common cause of a sudden mass 404.
2. Server or rewrite misconfiguration. A mistyped rule in your web server config or .htaccess, or a rewrite engine that is switched off, can stop the server from mapping URLs to files.
3. DNS or hosting change. If the domain now points at an empty server, a parked page, or the wrong document root, requests land where the content is not.
4. Expired or moved hosting. A lapsed plan or a migration that did not carry the files across leaves the server answering requests for content that is no longer there.
5. CMS or database failure. If the app cannot reach its database, some platforms serve 404s for dynamic pages even though the files exist.
6. Case sensitivity and path changes. Moving from a case insensitive to a case sensitive server can 404 URLs whose capitalization no longer matches.

The SEO impact of mass 404s

Google is explicit about how it treats 404s. According to Google's documentation on HTTP and network errors, when a previously indexed URL returns 404 it is removed from the index, newly discovered 404 URLs are not processed, and Google gradually reduces how often it crawls those URLs. At the scale of a single dead page, that is healthy pruning. At the scale of a whole site, it is damaging:

• Lost visibility. URLs dropped from the index stop appearing in Search, so the traffic they earned disappears.
• Wasted crawl attention. Crawlers spend requests fetching errors instead of your real content, slowing rediscovery once you fix things.
• Broken internal and external links. Every inbound link now points at an error, so the authority those links carried is stranded until you restore or redirect the URLs.
• User trust and conversions. Visitors who hit a wall of errors leave, and the bounce signals a poor experience.

The good news is that recovery is usually fast once the underlying cause is fixed, because Google recrawls and reindexes URLs that start returning 200 again. Speed matters: the longer a mass 404 persists, the more URLs get dropped and the longer full recovery takes. For the single page version of this problem, see our guide to 404 Not Found errors.

How to diagnose a site wide 404, step by step

1. Confirm the scope. Test the homepage, a few key pages, and one URL per content type. Note which return 404 and which return 200. The pattern points to the layer that broke.
2. Check the server and deployment. Review your most recent deploy or config change. If the 404s started at a known release time, roll back or fix that change first.
3. Inspect the web server config. Look at rewrite rules, the document root, and error handling. A single wrong directive can 404 an entire site.
4. Verify DNS and hosting. Confirm the domain resolves to the correct server and that the files are actually present in the document root.
5. Read the server logs. The error log usually names the failing file path or rule, which turns guesswork into a targeted fix.
6. Use Search Console. The Pages report and URL Inspection tool show which URLs Google now sees as 404 and let you request reindexing once fixed.

How to fix it and prevent a repeat

Fix the root cause before you touch redirects. If the files are missing, restore them. If a deploy broke routing, correct or roll back the release. If DNS points wrong, repoint it. Once URLs return 200 again, handle any genuinely moved content:

• Redirect moved URLs permanently. Use a 301 redirect from each old URL to its true new location so users and search engines follow the move and link value transfers. Our HTTP redirect checker guide shows how to confirm each redirect resolves correctly.
• Do not blanket redirect everything to the homepage. Google may treat mass redirects to the homepage as soft 404s, which does not help. Map each URL to its closest real replacement, or let it 404 or 410 if there is no equivalent.
• Restore internal links. Audit your own site for links that now point at dead URLs and repoint them. See our guide to broken links for the cleanup routine.
• Request reindexing. Use URL Inspection in Search Console to prompt a recrawl of the most important recovered pages.

Continuous monitoring so it does not happen twice

Most mass 404 events are discovered late, after traffic has already dropped. Close that gap by monitoring status codes continuously:

• Set an uptime and status monitor on your homepage and one URL per content type, alerting the moment any returns 404 or 5xx.
• Watch the Search Console Pages report weekly for spikes in "Not found (404)."
• Run a periodic crawl of your own site to catch broken internal links before users do, as covered in our find broken links guide.
• Add a post deploy smoke test that fetches a handful of key URLs and fails the release if any return 404.

For the website wide audit angle on this same problem, see our companion guide on 404 not found across a website, and for the user facing message and custom error page, read 404 this page is not found.

Frequently asked questions

What does "404 not found site" mean?

It means the server responded with a 404 status, indicating it could not find the requested resource, across the whole site or a large share of its URLs. Unlike a single broken link, a site wide 404 usually points to a server, routing, or DNS problem rather than one deleted page.

Why is my entire site returning 404?

The most common causes are a broken deployment, a misconfigured web server or rewrite rule, or a DNS and hosting change that points the domain at the wrong location or an empty document root. A database or CMS failure can also cause dynamic pages to 404. Check the homepage status first to tell a server problem from a content one.

Do site wide 404 errors hurt SEO?

Yes. Google removes indexed URLs that return 404, does not process newly found ones, and crawls them less over time. At site scale that means lost visibility, stranded link value, and a poor user experience. Recovery is usually quick once URLs return a 200 status again, but every day of downtime drops more URLs.

Should I redirect all my 404 URLs to the homepage?

No. Redirecting many unrelated URLs to the homepage is often treated as a soft 404 and does not preserve relevance. Redirect each moved URL to its closest real replacement with a 301, and let URLs with no equivalent return a genuine 404 or 410.

How do I know when my site starts returning 404 again?

Use continuous monitoring. Set an uptime and status code monitor that alerts you when the homepage or key URLs return 404 or 5xx, watch the Search Console Pages report weekly, and add a post deploy check that fetches key URLs and fails the release if any error. That way you catch a mass 404 in minutes, not weeks.