What Is a 404 Error?
A 404 error (Page Not Found) is an HTTP status code that means the server could not find the requested page. When a user or search engine bot tries to access a URL that does not exist at the requested location, the server responds with a 404 status code to indicate the resource is missing. Unlike a 500 server error or a 403 forbidden error, a 404 is a statement about the URL itself: the server is reachable, it understood the request, but no file, route, or database record corresponds to the path you asked for.
Every major website encounters 404s. They are a normal part of how the web works. A blog retires old posts, an ecommerce store stops selling a product, a URL structure changes during a migration, or a user mistypes a link in a tweet. When any of those URLs is requested, a correctly configured server returns a 404 to say "this doesn't exist here." The question for SEO is not whether you have 404s — you do — but whether the 404s you have are the right 404s, and whether you are handling them cleanly.
This guide walks through what a 404 actually is at the HTTP level, how hard 404s differ from soft 404s, why they matter for crawl budget and user experience, when a 404 is the correct response versus when you should redirect, how to design a 404 page that helps users instead of losing them, and how to monitor broken links on an ongoing basis with tools like the broken link checker and a full site audit.
What HTTP 404 Actually Means
HTTP status codes are three-digit numbers the server returns along with every response. They are grouped into five classes: 1xx informational, 2xx success, 3xx redirection, 4xx client error, and 5xx server error. A 404 is a 4xx error — the 4 means "the client asked for something that can't be fulfilled," and the 04 is the specific code for "not found." The server received a valid request, processed it, and determined that there is no resource at the URL path the client sent.
The raw response looks something like this:
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Content-Length: 1247
Date: Tue, 12 Mar 2026 14:22:18 GMT
<!DOCTYPE html>
<html><head><title>Page not found</title></head>
<body><h1>404 - Page not found</h1>...</body></html>
The critical piece is the status line — HTTP/1.1 404 Not Found. That is what crawlers read to decide how to treat the URL. The HTML body is what humans see, but Googlebot, Bingbot and other bots make their indexing decisions based on the header, not the words on screen.
Why 404 Errors Matter for SEO
A 404 on its own is not a penalty. Google has stated repeatedly that returning 404s for pages that no longer exist is correct behaviour. What hurts SEO is not the status code itself but the side effects: lost link equity, wasted crawl budget, broken user journeys, and signals of poor site maintenance.
Lost link equity
When an external site links to /best-running-shoes-2022 and that page now returns a 404, the backlink still exists but its value evaporates. Link equity, sometimes called PageRank, flows through the graph of links on the web, but a 404 is a dead end. Whatever authority that link was passing is effectively lost. Multiply that across hundreds of inbound links and you can see how a poorly handled site migration can wipe out years of off-site SEO work in a weekend.
Wasted crawl budget
Google allocates a crawl budget to every site based on authority, responsiveness, and perceived freshness. Every time Googlebot requests a 404, that is a request it did not spend on a page that could rank. On a small site this is irrelevant. On a site with 500,000 URLs, where 15% of those URLs are stale 404s, it becomes a real drag on how quickly new content gets discovered and indexed.
Poor user experience
Visitors who click a link and land on a 404 do one of three things: hit back, try to guess the correct URL, or leave the site entirely. All three are bad. Bounce rate goes up, pages per session goes down, and any trust the user had in the brand takes a hit.
Signals of poor maintenance
A site riddled with internal 404s looks unmaintained. Search engines indirectly factor this into quality assessments because crawlers can see that internal links on indexable pages point to dead URLs.
Hard 404 vs Soft 404
Not every page that says "not found" actually returns a 404 status code. This is where the distinction between a hard 404 and a soft 404 becomes important.
| Type | Status Code | Page Content | How Google Treats It |
|---|---|---|---|
| Hard 404 | 404 | "Page not found" content | Correct — removes from index |
| Soft 404 | 200 | Thin content or "not found" message | Google flags as soft 404 in Search Console and usually ignores the URL |
| Real 404 redirected to home | 301 to / | Homepage | Treated as soft 404 if pattern repeats |
| Legitimate thin page | 200 | Low word count, little unique content | May also be flagged as soft 404 |
A soft 404 is a URL that should be returning a 404 (because the content is gone or was never useful) but is instead returning a 200 OK. The most common cause is a developer choosing to "handle" missing content by redirecting every unknown URL to the homepage, or by serving a generic "Sorry, this page could not be found" message with a 200 status. Google's crawler sees the 200, assumes the URL is valid, and then gets confused when the content looks identical across hundreds of URLs. It will eventually classify these as soft 404s, and they show up in the Pages report of Google Search Console under "Soft 404."
Fix soft 404s by returning the correct status code. If content genuinely does not exist, serve a 404. If the content was moved, serve a 301. If it is thin but legitimate, add more content or noindex it.
Common Causes of 404 Errors
Understanding where 404s come from helps you prevent them at the source instead of constantly cleaning up after the fact.
Deleted pages without redirects
The single most common cause. Someone removes a blog post, retires a product page, or deletes a category, but forgets to set up a 301 to redirect the old URL. Every existing link to that page — internal navigation, external backlinks, bookmarked URLs, social shares — now hits a 404.
URL structure changes during a migration
A site moves from /blog/post-title to /articles/post-title, or from WordPress default permalinks to a cleaner slug structure. Without a comprehensive redirect map, every URL in the old structure becomes a 404 the moment the new config goes live.
Typos in links
Internal links with a missing character, an extra slash, or an incorrect case (on a case-sensitive Unix server) can silently produce 404s. These often go unnoticed because the person editing the content never clicks their own link.
External sites linking to old URLs
You have no control over how other sites link to you. Journalists, bloggers, and Reddit users will sometimes point to URLs that have since changed.
Expired or seasonal content
Event pages for last year's conference, ecommerce pages for discontinued products, or time-limited landing pages will accumulate 404s if the URL slugs include year or season markers that are no longer valid.
CMS migration artefacts
Moving from Shopify to WooCommerce, Magento to Shopify, or Wix to WordPress almost always produces a large number of 404s in the weeks following the switch if redirect planning was inadequate.
Domain migrations
Changing domains without a full 301 map is the most destructive version of this problem. Every URL on the old domain becomes a 404 unless redirected.
When a 404 Is the Correct Response
Not every missing page should be redirected. Sometimes a 404 is exactly what you want. Use the decision table below:
| Scenario | Recommended Action | Why |
|---|---|---|
| Page permanently removed, no close replacement | Return 404 (or 410) | Tells Google to drop it from the index |
| Page permanently removed, close replacement exists | 301 redirect | Preserves link equity |
| Page moved to a new URL | 301 redirect | Preserves link equity and rankings |
| Temporary maintenance | 503 Service Unavailable | Tells Google to come back later |
| Spam URLs Google is crawling | Return 404 or 410 | Stops crawl and removes from index |
URL pattern generated in error (e.g. ?utm_source junk) | Canonical to clean URL | Consolidates signals |
The rule of thumb: if the page is never coming back and there is no equivalent page, a 404 or 410 is the right call. Redirecting every dead URL to the homepage is a well-known soft 404 anti-pattern that hurts more than it helps.
404 vs 410 Gone
A 410 Gone is a close cousin of the 404. Both mean "not here," but 410 is more definitive — it tells crawlers and browsers that the resource intentionally no longer exists and is unlikely to return. Google has said in public blog posts and John Mueller Q&A sessions that they treat 404 and 410 almost identically for indexing purposes, with 410 being removed from the index slightly faster in some cases.
If you permanently retire a set of URLs — a discontinued product line, a deprecated API endpoint, a shuttered blog section — returning 410 signals intent more clearly than 404. For everything else, 404 is fine.
How 404s Affect Crawl Budget
Crawl budget is the number of URLs Googlebot will fetch from your site within a given window. On small sites, budget is never the bottleneck. On large sites — ecommerce stores with faceted navigation, news sites with long archives, marketplaces with user-generated content — crawl budget is a real constraint.
Every 404 Googlebot fetches is a request it cannot spend on a rankable page. If Googlebot hits 10,000 dead URLs a day because of a faulty internal search page that generates a unique URL for every query, that is 10,000 requests not spent on your product detail pages, blog posts, or category pages. The fix is not to redirect those URLs — that just moves the problem — but to prevent them from being linked or discovered in the first place, and to block them in robots.txt if they are already proliferating. See the robots.txt guide for how to do this safely.
Custom 404 Page Design
A well-designed custom 404 page turns a dead end into a useful moment. A poorly designed one is a dead end that looks like a broken site. The difference is measurable in bounce rate and pages-per-session.
Essential elements
- Clear messaging — state plainly that the page was not found. Avoid jargon like "404" without explanation.
- Site search — a search box lets users find what they were looking for.
- Navigation — full site nav so users can continue their journey.
- Popular links — list your top pages or recent posts.
- Contact option — link to a contact page so users can report issues.
- Brand consistency — same header, footer, and visual identity as the rest of the site.
What to avoid
- Redirect loops — do not automatically redirect 404s to the homepage or another page.
- 200 status code — the page body can say anything, but the HTTP status must be 404.
- Blank pages — a white page with "404" in Times New Roman looks broken.
- Cryptic error codes — do not show stack traces or server paths.
- No way forward — always give the user at least one next step.
Example 404 page HTML
<!DOCTYPE html>
<html lang="en">
<head>
<title>Page Not Found - Example Site</title>
<meta name="robots" content="noindex">
</head>
<body>
<h1>We couldn't find that page</h1>
<p>The page you were looking for may have moved or been removed.</p>
<form action="/search">
<input type="search" name="q" placeholder="Search the site...">
</form>
<h2>Popular pages</h2>
<ul>
<li><a href="/">Homepage</a></li>
<li><a href="/products">Products</a></li>
<li><a href="/blog">Blog</a></li>
</ul>
</body>
</html>
Note the meta name="robots" content="noindex" — optional on a 404 page but common, since the page is intentionally non-indexable. The status code of 404 is what actually prevents indexing.
How to Find 404 Errors on Your Site
Finding 404s requires a combination of tools because different sources of 404s need different detection methods.
1. Google Search Console
The Pages report in Search Console groups URLs by status. The "Not found (404)" bucket shows URLs Google tried to crawl that returned 404s. This is the single best source because Google sees links from across the web, not just your own site. Check this weekly for active sites.
2. The RankNibbler broken link checker
The broken link checker scans any page you point it at and reports every internal and external link that returns a 4xx or 5xx status. Useful for checking a specific page after a migration or for ad-hoc spot checks.
3. Full site audit
The site audit tool crawls your entire site like Googlebot would and reports every broken link it finds in context. This catches internal 404s that only exist because you have a stale navigation link somewhere.
4. Server access logs
Your web server writes every request to a log file. Filtering for status 404 shows every 404 actually served — including ones Googlebot or users hit that never appeared in Search Console. Useful on large sites.
5. Third-party backlink tools
Tools like Ahrefs, SEMrush, and Moz maintain crawls of the web and will report inbound links pointing to pages on your site that return 404s. This is the fastest way to find lost link equity opportunities.
How to Fix 404 Errors
Once you have a list of 404s, classify each one and apply the appropriate fix.
Step 1: Classify
- Has inbound links or organic traffic? — high priority, consider 301 to a close match
- Was it an important page? — restore or redirect
- Was it always junk? — leave as 404, or upgrade to 410
- Is it an internal link typo? — fix the source link, not the URL
Step 2: Redirect where appropriate
Use a 301 redirect when there is a close replacement. A close replacement is a page that serves the same intent as the original: a product page for a similar product, the category page for a retired item, or an updated version of an article. Do not 301 to the homepage unless there is literally nowhere more specific to send the user — that is the classic soft 404 anti-pattern. Read our full guide on what a 301 redirect is for implementation details.
Step 3: Update internal links
Every internal link pointing to a 404 URL should be updated to point to the correct or replacement URL. Redirects work, but a direct link is always faster and passes link equity more cleanly.
Step 4: Reach out about external links
For high-value backlinks pointing to 404 pages, email the linking site and ask them to update the URL. Most webmasters will update a link on request, especially if you make it easy by giving them the exact new URL.
Step 5: Monitor ongoing
Set up a weekly or monthly review of the Search Console Pages report so new 404s do not accumulate.
Implementation on Common Platforms
How you implement a 404 page and URL redirects depends on your stack.
Apache (.htaccess)
ErrorDocument 404 /404.html
Redirect 301 /old-page /new-page
Nginx
server {
error_page 404 /404.html;
location = /404.html {
internal;
}
location /old-page {
return 301 /new-page;
}
}
WordPress
WordPress serves its 404.php template automatically. Plugins like Redirection and Rank Math can manage 301 redirects from the dashboard.
Shopify
Shopify has a URL Redirects admin section. Custom 404 pages are controlled via the 404.liquid template in your theme.
Next.js
Create pages/404.js or app/not-found.js and return a proper 404 status. Use next.config.js redirects() for 301s.
Static sites
Most static hosts (Netlify, Vercel, Cloudflare Pages) let you configure a _redirects file or similar for 301s and a 404.html at the root for the 404 page.
Common 404 Mistakes to Avoid
- Redirecting everything to the homepage — creates soft 404s and destroys relevance signals.
- Returning 200 for missing content — confuses crawlers and hides real 404s from reports.
- Using JavaScript to render the 404 message — crawlers may index the URL if the initial HTML is a 200 shell.
- Forgetting to noindex parameterised error pages — search URLs like
/search?q=with no results can be indexed if not handled. - Mass-redirecting during a migration without analysis — creates redirect chains and loses pages that should have stayed live.
- Ignoring soft 404s in Search Console — they indicate pages Google is ignoring.
- Not monitoring — 404s accumulate silently if nobody is looking.
Best Practices for Managing 404s
- Return the correct status code — the HTTP status header is what crawlers read.
- Design a useful 404 page — search, navigation, popular links.
- Redirect when a close match exists — only when the new page serves the same intent.
- Use 410 for permanent removals — signals intent more clearly than 404.
- Monitor continuously — review Search Console weekly.
- Audit internal links after migrations — the broken link checker is your friend.
- Update internal links directly — do not rely on redirects as a permanent fix.
- Keep redirect chains to one hop — avoid A to B to C.
- Noindex your 404 page — optional but clean.
- Log server-side — track 404s in your analytics or server logs so patterns are visible.
Case Study: A Migration Gone Wrong
A mid-size SaaS company migrated from a subdirectory blog (/blog/post-slug) to a subdomain (blog.example.com/post-slug) without setting up 301 redirects. Within 6 weeks, organic traffic to the blog dropped 73%. Google Search Console showed 840 URLs in the "Not found (404)" bucket, many of which had significant inbound links. The team implemented bulk 301 redirects from the old paths to the new subdomain, resubmitted the sitemap, and ran a full site audit to find internal links still pointing to the old URLs. Traffic recovered to 85% of its original level within 3 months.
The lesson: redirect planning is not optional during migrations. It is the single most important piece of technical SEO work during any URL structure change.
404s and Internationalisation
Sites with multi-language versions need 404 pages that respect the language context. A user who lands on a 404 from /fr/produits/widget should see a French 404 page with French navigation, not an English fallback. The same applies to the lang attribute, hreflang alternates, and the site search language. Serving the wrong language on a 404 is a small but noticeable UX failure.
Tools to Check for 404 Errors
| Tool | What It Does | When to Use |
|---|---|---|
| Broken Link Checker | Scans a single page for broken links | Spot-checking a specific page |
| Site Audit | Crawls entire site, reports all 404s | Full site health check |
| Bulk URL Checker | Checks status codes for a list of URLs | Verifying a redirect map after migration |
| Redirect Checker | Traces the redirect chain for any URL | Debugging redirect loops and chains |
| Google Search Console | Shows 404s Google has crawled | Weekly monitoring |
| Server logs | Shows every 404 actually served | Deep diagnostic work |
Frequently Asked Questions
Does a 404 error hurt my ranking?
A 404 on a URL that should not exist does not hurt rankings. The page is simply removed from the index. What hurts rankings is 404s on pages that had traffic, backlinks, or indexed content — those represent real loss.
How long does Google keep a 404 URL in the index?
Google typically drops a 404 URL from the index after a handful of re-crawls confirm the 404 status, which usually takes a few weeks. A 410 is often dropped faster.
Can I have too many 404s?
Yes — when 404s make up a large fraction of the URLs Googlebot crawls, it can consume enough crawl budget to slow indexing of real pages. Small sites never hit this; very large sites can.
Should I redirect all 404s to the homepage?
No. This is the classic soft 404 anti-pattern. Google's documentation explicitly warns against it. Redirect only when a close match exists.
Is a 404 page the same as a 404 error?
Close but not identical. The 404 error is the HTTP response. The 404 page is the HTML the user sees when that error occurs. A site can serve a custom 404 page while still returning a 404 status code — in fact, that is the correct setup.
What is a 404 page's role in SEO?
Minor directly, important indirectly. A good 404 page reduces bounce rate and keeps users on site. Search engines do not rank 404 pages (they are excluded from the index), but the behaviour metrics of users who hit them feed into quality signals.
Should a 404 page be noindexed?
Optional. The 404 status code itself prevents indexing. Adding noindex is belt-and-braces and not harmful.
How do I fix soft 404s?
Identify the URLs in Search Console, then either return a real 404 status code, add substantive content to the page, or redirect to a relevant live page.
Can JavaScript cause 404 issues?
Yes. Single-page apps that render the "not found" message in the browser while the server returns 200 will produce soft 404s. The fix is to configure the server to return a real 404 status for unknown routes.
Do broken images cause 404s?
Yes — image requests that return 404 are logged just like page 404s. They also hurt user experience. Use the image checker and the broken link checker together to catch both.
What is the difference between 404 and 400?
A 400 Bad Request means the request itself was malformed (for example, invalid JSON in a POST body). A 404 means the request was valid but the resource does not exist.
Should 404 pages have Open Graph tags?
Not strictly necessary — 404 pages are typically not shared. But if they are reached via social share of a now-dead URL, basic Open Graph tags on the 404 prevent the share card from looking broken.
404 Errors and the Broader HTTP Status Family
Understanding where 404 fits in the HTTP status code hierarchy helps clarify when it is the right response versus when another code would be more appropriate.
| Code | Meaning | SEO Impact |
|---|---|---|
| 200 OK | Request succeeded, content returned | Page is indexable |
| 301 Moved Permanently | URL permanently redirected | Signals consolidate to new URL |
| 302 Found | Temporary redirect | Does not pass link equity like 301 |
| 307 Temporary Redirect | Same method redirect, temporary | Similar to 302 for SEO |
| 308 Permanent Redirect | Same method, permanent | Like 301 but preserves HTTP method |
| 400 Bad Request | Malformed request syntax | Rare for static URLs |
| 401 Unauthorized | Authentication required | Not indexed |
| 403 Forbidden | Access denied | Often left out of index |
| 404 Not Found | Resource does not exist | Removed from index |
| 410 Gone | Resource permanently removed | Removed from index, often faster than 404 |
| 500 Internal Server Error | Server-side fault | Not indexed, signals site health issue |
| 503 Service Unavailable | Temporary downtime | Google pauses indexing, retries |
The most common mistake is conflating 404 with 403, 500, or 503 scenarios. A 404 is specifically "the resource does not exist." If the resource exists but requires authentication, 401 is the correct response. If the server is temporarily broken, 500 or 503 is correct, not 404. Returning 404 for transient server issues causes Google to deindex the URL, which is often unrecoverable without reindexing effort.
The RankNibbler redirect checker shows the full response chain for any URL, including the final status code, making it easy to diagnose mix-ups.
Understanding "Crawled - Currently Not Indexed" vs 404
Google Search Console lists pages under several status categories, and the distinctions matter for diagnosis. A URL that returns 404 appears under "Not found (404)." A URL that returns 200 but was deemed low-quality appears under "Crawled - currently not indexed." These require different fixes: the first needs redirect or restoration, the second needs content improvement or consolidation.
Pages in "Discovered - currently not indexed" are URLs Google knows about but has not crawled yet, often due to crawl budget constraints. Pages in "Soft 404" appear when the URL returns 200 but Google's algorithms determine the content represents a missing or non-existent page.
Reviewing these categories weekly and categorising the URLs in each is a high-leverage activity. A site with 4,000 URLs in "Not found" likely has a broken redirect map or a rogue internal link pattern. A site with 6,000 URLs in "Soft 404" likely has a misconfigured template returning 200 for missing content. Each bucket needs a different intervention.
The Role of XML Sitemaps in 404 Management
An XML sitemap tells Google which URLs you consider important. Including 404 URLs in the sitemap sends mixed signals: "this is important" and "this doesn't exist" at the same time. Google will surface these in the sitemap coverage report with errors.
Best practice:
- Sitemap lists only 200-OK, canonical, indexable URLs
- Remove URLs from the sitemap as soon as they are retired
- Regenerate the sitemap on a regular schedule (daily for news sites, weekly for most sites)
- Submit the sitemap to Search Console and monitor the Coverage report
- Run the site audit periodically to catch sitemap drift
Large sites often automate sitemap generation from a database query that excludes any URL returning non-200 or flagged as noindex. This prevents sitemap bloat and 404 noise in Search Console.
Server-Side Logging for 404 Diagnosis
Search Console surfaces the 404s Google is actively tracking. Server logs surface every 404 served — including bot requests Google has not yet reported, human traffic hits from referrals, and obscure spam bot probing that never reaches Search Console at all.
A simple analysis for Apache access logs filtering only 404s:
grep ' 404 ' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50
This returns the top 50 most-404ed paths. Patterns usually emerge quickly: a typo in a navigation link that generates hundreds of daily 404s, a spammy URL pattern hitting a legacy endpoint, a broken Open Graph image reference, or a stale Ahrefs backlink that nobody has addressed.
Feed the top-404 list into a prioritisation matrix: which URLs have referrers? Which have historical traffic? Which get hit by Googlebot vs random scanners? Address the Googlebot-heavy and traffic-heavy entries first; leave the scanner noise alone.
Preventing 404s at the Source
The best fix for a 404 is preventing it from happening in the first place. Three high-leverage prevention patterns:
1. URL-aware content workflows
Every content workflow that can change URLs — renaming a slug, deleting a post, restructuring categories — should include a redirect step before publish. For WordPress, plugins like Redirection can automatically log slug changes and create 301s. For static sites, include redirect map updates in the PR checklist.
2. Internal linking audits
Broken internal links create 404s that visitors see and crawlers follow. A monthly crawl with the broken link checker or site audit catches these early. Fix the source link — do not rely on a redirect as a permanent patch.
3. Deploy-time URL validation
CI/CD pipelines can crawl the site after every deploy and fail the build if critical URLs return non-200. For static sites, this is straightforward: list the top 100 URLs, hit each one post-deploy, alert on any failure. For dynamic sites, a subset check is still valuable.
404s in Single-Page Applications
Single-page apps (SPAs) built with React, Vue, Angular, or Svelte handle routing in the client. A user navigating to a URL that does not map to a route typically sees a client-rendered "not found" component while the server returns 200 for every URL. This is the textbook soft 404.
Three approaches to fix:
1. Server-side rendering with proper status codes
Next.js, Nuxt, SvelteKit, Remix, and similar frameworks render on the server and can return proper 404 status codes for unknown routes. Configure the catch-all route to return 404 at the HTTP level.
2. Pre-rendering known 404s
For static generators, pre-render a 404.html file and configure your host (Netlify, Vercel, Cloudflare Pages) to serve it with a 404 status code for unknown paths.
3. Server-side URL validation before client takes over
For legacy SPAs where migrating to SSR is impractical, add a server-side check that validates known routes and returns 404 at the HTTP level for unknowns before any JavaScript runs.
Ignoring this problem is the single most common SEO failure in modern SPAs. Google flags the site with thousands of soft 404s, crawl budget drains into non-existent routes, and real content gets pushed down the indexing queue.
Measuring the Business Impact of 404s
To justify engineering time on 404 cleanup, quantify the impact. Rough framework:
- Lost traffic — sum of historical organic traffic to URLs currently returning 404
- Lost link equity — count of external backlinks pointing to 404 URLs
- Lost revenue — lost traffic multiplied by conversion rate and average order value
- Wasted crawl budget — percentage of Googlebot requests hitting 404s
- User experience cost — bounce rate and session duration impact
On a mid-size ecommerce site, a 404 cleanup that restores 200 high-traffic URLs via appropriate redirects often delivers a measurable quarter-over-quarter lift in organic revenue. The work is unglamorous but the ROI is typically strong.
Monitoring 404s on an Ongoing Basis
A one-off cleanup is useful; a monitoring rhythm is essential. The most common monitoring cadences are:
- Weekly — Search Console Pages report check on active, high-volume sites
- Monthly — site audit crawl for internal link health
- Post-deploy — crawl the site right after any release that touches URLs
- Post-migration — daily monitoring for the first 2 weeks
Set up alerts where possible. If your analytics platform supports custom alerts, configure one for a sudden spike in 404 hits. That early-warning signal is often the first indicator that a deploy broke something.
Final Thoughts
A 404 error is not a bug or a failure — it is the HTTP protocol doing its job by telling the world that a URL does not exist. What matters for SEO is using 404s correctly: returning them when content is genuinely gone, redirecting only when a real replacement exists, designing a helpful 404 page, and monitoring for patterns that indicate something is broken. Teams that treat 404 management as a routine part of their release process have clean crawl reports and stable organic traffic; teams that treat it as an afterthought watch migrations erase years of work.
Start with a scan of your site using the broken link checker, then move to a full site audit to catch broken internal links, and finish by checking your Google Search Console Pages report for anything Google is seeing that you are not. That three-layer approach covers internal, external, and search-engine-visible 404s with minimal overlap.
Last updated: March 2026