Error 404: when to fix it, when to leave it

A 404 is not a malfunction. It is the correct, honest answer to a request for something that does not exist. Your server is working exactly as designed, and most of the 404s in a crawl report deserve no action at all.

The useful question is never "how do I get rid of this 404". It is "who is still pointing at it".

The only thing that makes a 404 expensive

A 404 costs you something when someone or something still expects a page there:

• another page of your site links to it: the visitor hits a wall in the middle of reading;
• another website links to it: you are losing the value of a link somebody gave you;
• it still gets traffic: from a bookmark, a newsletter, a search result not yet updated;
• it is in your menu or your sitemap: you are announcing a page that is not there.

If none of those is true, the 404 is a URL nobody asks for. It is not a problem. It is a fact.

Recognising the origin is most of the decision

A crawl report mixes together 404s that have nothing to do with one another. Separating them by origin takes ten minutes and divides the work by three.

The last two rows often make up half a report and require no work at all. Treating them like the others is the most common way to turn a useful afternoon into a wasted week.

The triage, in order

1. Is anything linking to it from your own site? Fix the link, not the page. This is the most common case by far and the fastest to resolve: you edit one article instead of resurrecting a page. You do need to know which page the link is on, which is exactly what the free methods provide when used properly.

2. Does an external site link to it? Then the page had value someone else recognised. Restore it, or redirect it to the closest genuine equivalent.

3. Does it still get traffic without any link? Old bookmarks, printed references, a QR code on a document. A redirect to the nearest useful page is kind here.

4. None of the above? Leave it. Removing it from your sitemap is the whole job.

404, 410 and the false 404: three answers, three effects

The third case, known as a soft 404, is a common accident with error pages built inside a CMS: the visitor sees an error, the machine sees a normal page. The search engine then indexes dozens of identical pages announcing that there is nothing there, and you later wonder why your site looks full of duplicate content.

Between 404 and 410 the difference is small and invisible to a visitor. A 410 is justified when you are certain the page will never come back, which is rarer than people think.

Two things that look like fixes and are not

Redirecting everything to the homepage. The reader who clicked "our 2023 pricing guide" lands on a homepage and has no idea why. Search engines, for their part, tend to read a homepage redirect as "no equivalent exists", which is what a 404 already said, but with a worse experience attached.

Redirecting to something vaguely related. The same mistake, quieter. That decision is made page by page, and the tree that settles it is four questions long.

What a real 404 page contains

Write it once and it applies to every broken URL you have not found yet. Four elements are enough:

• A clear sentence: this page does not exist, or no longer does. No obscure humour, no bare error code.
• A search box, because the visitor was looking for something specific.
• Two or three real links to your most requested pages, not your entire menu copied out.
• The right HTTP status, which is 404. That is the part people forget, and the only one machines read.

An hour of work, and a dead end becomes a detour.

The 404s nobody sees go by

Three families escape both crawl reports and human proofreading, and they do quiet damage.

Files. A missing image, a moved stylesheet, a PDF pulled from the server. The visitor sees no error, they see a page that looks broken, which is worse because they will not know what to tell you.

Pages reachable only from outside. An address sent in a newsletter, printed on a leaflet, pasted into an email signature. No internal link leads to it, so no crawler tests it, and yet people request it.

Redirects broken halfway. The old URL redirects to an intermediate address that no longer exists. The report shows a valid redirect, and the visitor lands on an error two hops later.

Your server logs are the only place where all three families appear, because they record what people actually asked for rather than what your site offers.

A routine that holds

The rhythm matters more than the depth. A realistic routine is three habits: a full check every quarter, a check of the menu and footer pages after every template change, and a monthly glance at Search Console errors. It is not much, it is doable, and it catches the important cases before a reader does it for you.

How many 404s is too many?

There is no threshold, and that is the honest answer. A ten-year-old site with five hundred 404s none of which is linked is healthier than a two-year-old site with ten of them in the middle of its menu. The number says nothing; the question "who still points at it" says everything.

What does circulate is the idea that a pile of 404s wastes a search engine's attention. That is false in very nearly every case: crawl budget concerns almost nobody, and certainly not a site with a few hundred of them.

Two moments do deserve real attention, because 404s arrive there by the hundred and for bad reasons: a redesign and a migration. The corresponding check-list handles the subject at the source, which always costs less than handling it afterwards.

And do not forget the half of the problem that appears in none of your reports: One confusion is worth clearing before we close: a 404 and a server error are not handled alike at all. The first is a correct answer to a request for nothing; the second says something is broken on your side, right now, and is read under time pressure. 500, 502 and 503 have their own grid.

And do not forget the half of the problem that appears in none of your reports: the links leaving your site for pages that died elsewhere. Those show up nowhere, and they are the ones your readers click first. Nothing on your side will ever report them, which is exactly why they accumulate for years without anyone noticing.