Less bad than you fear, and more nuanced than most advice admits. A page that returns a proper 404 is doing its job. Google removes it and moves on. The real damage comes from pages that pretend to work, from lost link value on URLs worth saving, and from visitors who hit a dead end and leave.
We audit a lot of sites, and broken links are on nearly all of them. Content gets renamed. Products get retired. A migration changes the URL pattern and nobody checks the old ones. This is normal wear, not negligence.
What separates a healthy site from a leaky one is not having zero broken links. It is knowing which ones matter and handling those correctly.
A 404 is an HTTP status code meaning the server looked for the page and could not find it. It is a signal, not a failure. The server is telling browsers and crawlers, honestly, that nothing lives at this address. That honesty is exactly what search engines want.
The important part is that the status code travels separately from what the visitor sees. A page can show a friendly "sorry, we could not find that" message while still returning a 404 in the response header. Humans read the message, machines read the code, and both need to be right.
Google's documentation on HTTP status codes is clear about what happens next. It states that "Google doesn't index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index."
Google also keeps checking for a while before giving up. Its documentation notes that after repeated 4xx responses "the crawling frequency gradually decreases." Nothing is deleted the instant a page breaks, which gives you a window to fix genuine mistakes.
Not directly. A 404 on a page nobody links to and nobody visits costs you nothing. What costs you is a 404 on a URL that had links pointing at it, traffic arriving at it, or a place in someone's navigation. The problem is never the status code. It is the value sitting behind the URL.
Think about it as three separate questions. Does anything link to this URL from outside your site? Does anyone still visit it? Does an equivalent page exist now? If all three answers are no, let it 404 and stop worrying.
The panic reaction is to redirect everything to the homepage. Do not do this. Google treats a redirect as a claim that the target is the replacement for the source, and the homepage is not a replacement for a deleted blog post. Bulk homepage redirects usually get treated as soft 404s anyway, which puts you back where you started with extra work done.
The other reason 404s get blamed unfairly is that they cluster around migrations. A site moves, hundreds of URLs break at once, and rankings drop. The drop came from the migration, not from the 404 status code. We cover doing that properly in our guide to migrating a website without losing SEO.
A soft 404 is a page that says it is broken while returning a 200 OK status code. The visitor sees an error, the crawler sees a working page. That mismatch is genuinely harmful, because search engines index the error page, waste crawl effort on it, and may show it in results.
Google names the symptom directly, stating that "if the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error." Google is guessing at your intent from the visible content, which tells you how confusing the situation is.
Single-page applications are the most common cause. Google's own JavaScript debugging guidance explains that "when a SPA is using client-side JavaScript to handle errors they often report a 200 HTTP status code instead of the appropriate status code. This can lead to error pages being indexed and possibly shown in search results."
Google gives two fixes for that case. Its guidance is to "redirect to a URL where the server responds with a 404 status code" or to "add or change the robots meta tag to noindex." Either works. The point is that something in the response has to tell the crawler this page is not real content. This is the same class of problem we describe in our piece on JavaScript rendering and why AI crawlers miss your content.
Use 410 when you know the page is gone forever and you want to say so. MDN describes 410 Gone as indicating "that the target resource is no longer available at the origin server and that this condition is likely to be permanent," and notes that "a 410 response is cacheable by default."
The difference matters most for cleanup at scale. If you retire a thousand old product URLs and you are certain they will never return, 410 tells crawlers not to keep checking. MDN puts it plainly, stating that "clients should not repeat requests for resources that return a 410 response."
MDN also gives the rule for when not to use it. If "server owners don't know whether this condition is temporary or permanent, a 404 status code should be used instead." Uncertainty means 404. Certainty means 410.
Be aware that Google treats them almost identically. Its documentation states that "all 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist." So 410 is a courtesy and a small crawl efficiency gain, not a ranking lever. Do not spend a week converting 404s to 410s expecting a result.
Redirect when a genuine replacement exists. If the old page had an equivalent on the new site, send visitors there with a permanent redirect. If nothing equivalent exists, a 404 is the honest answer and the better one for everyone involved.
Google distinguishes the strength of the signal by redirect type. Its documentation says a 301 means "Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed," while a 302 is used "as a weak signal." Permanent moves need a permanent redirect.
The method matters too. Google ranks server-side redirects as the most reliable, using 301 or 308 for permanent moves and 302, 303, or 307 for temporary ones. Meta refresh comes second, and JavaScript redirects last, with Google advising to "only use JavaScript redirects if you can't do server-side or meta refresh redirects."
Google also explains the visible consequence of picking the wrong one. Permanent redirects "show the new redirect target in search results," while temporary redirects "show the source page in search results." If you permanently moved a page and used a 302, you are telling Google to keep the old URL. We go through the setup in detail in our guide to setting up redirects.
Start with Google Search Console, because it shows you the URLs Google actually cares about. The Pages report separates genuine 404s from soft 404s, and the soft 404 list is where the real problems hide. Then run a crawler such as Screaming Frog across the live site to catch internal links pointing at dead pages.
Those two tools answer different questions. Search Console tells you which broken URLs the outside world knows about. A crawler tells you which broken links you are creating yourself from your own navigation, body copy, and footers. Internal broken links are entirely your fault and entirely within your control, so fix those first.
Analytics gives you the third view. Filter for pageviews on your 404 template and you will see which dead URLs people are still reaching. Those are the ones worth redirecting, because real humans are still arriving at them from somewhere.
Check external tools last. Ahrefs and Semrush will show broken pages that still have backlinks pointing at them, which is the clearest possible signal that a redirect is worth setting up. A dead URL with real inbound links is free authority waiting to be reconnected.
It should apologise briefly, explain what happened in plain language, and give the visitor an obvious way forward. Search, main navigation, and a link to the most popular section. It should never be a dead end with a cartoon and nothing else.
The mistake we see most is a 404 page designed as a joke. A clever illustration is fine, but it cannot be the whole page. Someone arrived here trying to do something. Help them do it, then be funny if you have room.
Keep it fast and keep it consistent with the rest of the site. A 404 page that loads a completely different layout, drops the navigation, and takes three seconds to appear signals a broken site rather than a missing page. It should feel like your site, because it is.
And check the status code. The single most common bug we find on custom 404 pages is a beautiful design that returns 200. Load the page and inspect the response header. If it says 200, you have built a soft 404 with extra steps.
Decide on a URL policy and hold to it. URLs are a contract with everyone who ever linked to you. Once a page is published, its address should change only when there is a real reason, and when it does change, a redirect goes in on the same day. Most broken link problems are really URL discipline problems.
Build the check into launch. Before any site goes live we crawl the staging build for broken internal links and confirm the 404 template returns a real 404. It takes minutes and catches the majority of what would otherwise become next quarter's cleanup.
Set a recurring review. Once a quarter, open Search Console, look at the not found and soft 404 reports, and decide on each cluster. Most will be noise from scrapers and bad bots and can be ignored. A few will be real, and catching those early is much cheaper than finding them a year later.
Finally, keep a redirect map for every migration and never delete it. The map is the institutional memory of every URL your site has ever had. On sites that have been through several rebuilds, that document is worth more than the analytics.
Open Google Search Console and look at your soft 404 report first. Those are the ones actively hurting you. Then crawl your own site for internal links pointing at dead pages and fix them at the source. Then, and only then, decide which genuinely dead URLs deserve a redirect.
Most sites need an afternoon of this work, not a project. The goal is not zero 404s. The goal is that every 404 is intentional and every URL with real value still resolves to something useful.
If you would like us to run this pass over your site and tell you which broken links actually matter, we are happy to take a look. Reach out through phoenix.studio and send us the domain.
Tell us where you want to go. We'll tell you how we'd get you there.