Error pages that recover — 404, 500 and what must not die

A dead URL with no way onward costs you the session you already paid to get. The user came from an old newsletter, a PDF link, a quote in a post, a misspelling. They land on an empty 404 or a homepage you sent them to with a 302, and they leave. You think you have 'a 404 page'. You have a stop. Recovery is the boring part: show that you understood the URL, show three paths that live, show search, show how they reach you. The homepage is one link. It is not a strategy.

Teams inherit the wrong default. WordPress shows a theme 404 nobody edited. Next.js shows `not-found.tsx` with one paragraph. The CDN shows a vendor page in another language when origin is down. Three truths, none of them yours. Monitoring tells you something is wrong. The error page is what the customer sees while you are still looking at the log. The two posts are neighbours. They are not the same job.

It is also an SEO and trust question. A soft 404 — 200 OK with 'page not found' — teaches Google that your 404s are content. A 302 from every dead URL to the homepage teaches Google that the homepage is the answer to everything, and that you do not have your paths under control. The relaunch post is cutover and 301s. Here it is the URL you did not get to fix: it should die out loud, with a 404, and with a page you are not ashamed to show a crawler.

We write this because 'custom 404' has become a design purchase you make before you have a sentence about recovery. An honest setup is boring: a true status, the same chrome as the rest of the site, a next step, and a 500 that does not make the outage worse. Without that sentence you have an illustration. You do not have an error page.

A recovering error page is three things on one screen: you say honestly what happened (does not exist, or we failed), you let the status code match, and you give a next step that is not a guess. On 404: search, a small set of paths you know are alive, the URL they asked for, a way to contact. On 500: 'this is us', a time or a reference id if you have one, a ban on resubmitting the form blindly, a link to status if you have one. That is recovery. It is not a campaign.

It is not monitoring. Monitoring is you noticing that origin is down, that the form died, that GSC saw a crawl spike. The error page is what holds the user while that happens. You can have tidy uptime alerting and a 404 that only says '404'. You can have a loving illustration and no alarm. You need both. This post is only what the screen shows.

It is also not a redirect strategy. A 301 from an old path to the new one is right when you know the target. A 302 of every unknown path to `/` is how you hide debt and destroy the signal. The relaunch post is the list you fix. The 404 is what you show when the list does not have the row. The two must not swap. A homepage is not a 404.

And it is not a brand joke as the job. A gag, a 404 game, an 'oops' illustration is allowed if the next step is still there and the page is accessible. It is not allowed as the only effort. If you spent the design budget on the animation and left search and paths out, you bought a meme. The user arrived with an intent. Give them a path that looks like it.

The first failure is the status code. The app shows the right text and the wrong header. A client-side router fallback, a `fallback: true` without a 404, a middleware that rewrites to `/`. The crawler sees 200. The user sees 'not found'. You have lied to both. Test with `curl -sI` on a path you know is dead, and on a path you just deleted. If you only look in the browser, you are testing the layout.

The second failure is the homepage as a trap. Every unknown URL 302s to `/`, 'so they do not see an error'. Then you cannot see in the log what was dead. Google learns that the homepage is the answer to old slugs. The user loses the URL they could have sent to support. A 404 with the original path in the body is more honest — and it gives you the list the redirect work later needs.

The third failure is the 500 page that makes the outage worse. Auto-reload every five seconds. A script that hits origin again. A 'try again' button that posts the payment a second time. When origin is down, the error page should be static — cached at the edge, without calling the database to show that the database is dead. Say it is you. Give a time to try again. Save the action if you can. The reload loop is how you DDoS yourselves.

The fourth failure is that the error page is not your site. Another language. No navigation. A different cookie banner, or none, while scripts still run. A layout that breaks on mobile. The cookie-banner post is the control. The accessibility post is the EAA. Here the duty is simpler: 404 and 500 must be usable by the same person who could use the homepage. If they cannot, recovery is a screenshot.

A Next.js site typically dies in a `not-found` you never wrote, in a rewrite that swallows unknown paths, or in an `error.tsx` that calls the app again to show that the app is dead. App Router gives you the right primitives. It also gives you a chance to pretend a client-side empty state is a 404. Keep 404 on the server. Keep 500 as close to static as you can. Preview deploys are a good place to show a colleague `curl -sI` on a dead path — before it reaches prod.

A WordPress site typically dies in the theme 404 you never opened, and in plugins that 302 'for SEO'. A cache plugin can serve a 200 cache of a page you deleted. A redirection plugin can send everything to the homepage. Inventory with a cold path and a cache bypass. If you cannot point at the template and at the status code, you do not have a 404. You have a theme.

The edge — Cloudflare, Vercel, a load balancer — is the 500 you forget. When origin does not answer, the vendor shows its own page, often in English, often without your navigation. That is still your brand for five minutes. A custom error page at the edge, cached, with no origin call, is the boring work that makes monitoring visible to the customer as 'we know', not as 'the site is gone'. Monitoring without that page is a Slack message. The customer sees the vendor's CSS.

If you already have monitoring, relaunch and an honest cookie banner, and the 404 still feels like the weak link, that is because it is. The alarm without recovery is an internal mail. Cutover without a 404 is a hope that the list was complete. The banner without a 404 that also respects consent is a leak on the page you thought nobody saw. The error page is what the wrong URL sees. It has to carry the others.