How to Handle 404 Errors on a SaaS Site After Google's October 2026 Guidance

A 404 error is not a penalty. Google treats it as a signal that a page is gone and drops the URL over time without hurting your other pages. For each dead URL on a SaaS site, decide whether to redirect it, leave a 404 or 410, or improve the 404 page.

On October 28, 2026, Google's Gary Illyes covered this in a short video, and Search Engine Roundtable summarized it. This guide turns that advice into a working process for B2B SaaS teams with retired features, merged docs and pruned blog posts. Cekpr covers SEO and AI search for software companies, and 404 handling is one of the places teams waste the most time.

What Google said about 404 errors

According to Search Engine Roundtable's report, Illyes said Google expects pages to disappear and eventually drops them from the index. He said a 404 does not harm healthy pages, and that the idea that 404s drain crawl budget is a myth. The article notes the video adds nothing new but is a useful recap.

Google's own documentation says the same thing in plainer terms. In its guide to HTTP status codes and network errors, Google explains that a 404 or 410 signals that content no longer exists. URLs already in the index are removed, and Google crawls those URLs less often over time.

The same page draws a sharp line between client errors and server errors. A 5xx or 429 response makes Google slow its crawl, ignore the content and, if it persists, drop URLs from the index. That is where the real risk sits.

Do 404 errors hurt SaaS SEO?

No, not by themselves. A 404 only hurts when it replaces a page that earned traffic, links or sales and has a good substitute. In that case you lose the value that page carried. Dead URLs with no traffic, no links and no replacement cost you nothing in rankings.

SaaS sites produce 404s more than most. Teams retire features, rename integrations, merge help articles, sunset legacy plans and prune thin blog posts. Each change can leave a trail of dead URLs, and a Search Console report that lists them can look alarming.

Do not read the count as a score. A report with 2,000 404s may be harmless if those URLs were thin tag pages from a past migration. A report with 20 may be serious if they are old pricing or comparison pages that still receive links.

A decision process for every dead URL

Judge each dead URL by four facts: traffic, backlinks, business value and whether a real replacement exists. Those facts decide the action. Illyes described three options, and the table below maps each to a common SaaS case.

Check traffic in your analytics and links in a backlink tool before you decide. A URL with ten referring domains deserves a redirect. A URL with none and no visits can stay dead.

When should you redirect, and to where?

Redirect when a page has traffic or links and a genuinely relevant replacement exists. Use a permanent 301 so Google shows the new URL. Send the old URL to the closest equivalent, not to a loosely related page, so the visitor and the search engine both see the same match.

Google's redirect documentation recommends a permanent server-side redirect whenever you want the new URL to appear in results, and lists sending users from a removed page to a new one as a valid use. A temporary 302 keeps the old URL showing, so it is wrong for retired pages.

Avoid sending every dead URL to the homepage. Illyes warned that unrelated redirects confuse visitors and distort your data. A visitor who clicked a link to a feature page and lands on a generic home page often leaves, and your analytics then count a misleading bounce.

The same logic applies when you change slugs. Our guide to writing a URL slug policy for a SaaS blog explains how to avoid creating dead URLs in the first place by keeping slugs stable.

When to leave a 404 or serve a 410

Leave the URL dead when the page is permanently gone and nothing useful replaces it. A 404 says the page was not found. A 410 says it is gone on purpose. Google treats both as signals that the content no longer exists, so either works.

A 410 can be a cleaner signal when you remove a large batch of pages on purpose, such as an old campaign directory. A 404 is fine for everything else, and it is the default your server gives.

Watch for soft 404s. Google's documentation says a soft 404 occurs when a page returns a success status code but its content looks like an error or is empty. Search Console flags these. A page that says "no results" with a 200 status is a common SaaS cause, such as an empty search page or a deleted template.

How to build a 404 page that helps

If visitors still arrive at dead URLs, improve the 404 page. A helpful page tells the visitor plainly that the page is gone, offers a search box, and links to your main categories, such as product, pricing, docs and support. It should return a real 404 status, not a 200.

For a SaaS site, add a short list of the most visited pages and a link to contact support. If the dead URL looks like a docs path, show a link to the docs home. Small touches like this keep a lost visitor on the site.

Keep the design light. A heavy 404 page with many scripts slows the response, and a slow error page still counts as a poor experience. Test it by requesting a made-up URL and checking both the status code and the load time.

Why server errors matter more than 404s

Server errors are the ones that cost you. Illyes said 500-class and 429 errors signal a struggling server or too many requests, and Google may slow crawling as a result. Google's documentation says persistent 502 and 503 errors lead to removal from the index.

That makes uptime and rate limiting part of SEO. If your CDN or firewall returns 429 to Googlebot, you will slow your own crawling. Our guide to serving a 503 during an emergency patch shows how to take a site offline briefly without losing rankings.

If you want to cut the load on purpose, there is a safe way to do it. Our walkthrough on reducing Google's crawl rate safely explains why a temporary error with a retry hint works better than blocking crawlers.

How to audit the 404s on your site

Run a quarterly audit with a short checklist. Export the 404 list from Search Console and from your server logs. Sort it by internal links, external links and traffic. Group the rest by pattern, such as an old docs version or a removed folder.

Internal links come first. If your own pages link to a dead URL, that is a bug you control. Fix those links regardless of how Google treats the 404. Then confirm redirects do not form chains, since each extra hop slows users and adds risk.

If a traffic drop follows a content cleanup, check the causes before you blame 404s. Our post on diagnosing a SaaS organic traffic drop lists five causes and a checklist for telling them apart.

Conclusion

A 404 is a normal part of a growing site, and Google does not punish you for it. Spend your effort on the few dead URLs that carry traffic or links, redirect them to a true replacement, and let the rest go. Pay closer attention to 5xx and 429 responses, which can slow crawling and remove pages.

Your next step is to export your 404 list and sort it by links and visits. You will probably find a dozen URLs worth a redirect and thousands that are not. Cekpr will keep translating Google's guidance into steps a small SaaS team can finish in an afternoon.