Why We Have a Rule That Links Are Never Allowed to 404

Have you had this experience: you see "Members Area" on a website, click it, and get a 404. You see "Learn More," click it, and land on a blank page. In that instant you don't get angry. You just quietly form a judgment — this company isn't quite together. Then you leave, and you don't come back.

Nobody will ever email you to say "I lost confidence in you because of a 404." This kind of churn is silent, which is why most teams never know they're paying for it.

A rule that looks like overkill

Our team has a rule written into our development standards: any link, button, or entry point that appears on screen may only point to a page that actually exists. Unfinished features are hidden — never exposed.

Enforcing this rule is genuinely not cheap. For a half-built feature, the easiest engineering move is to leave the entry point in place and backfill the page later; the most tempting product move is to hang up a "Coming Soon" placeholder. We forbid both. Every feature needs an extra feature-flag layer: until it's finished, the entire entry point disappears; when it's finished, everything lights up together.

Why so stubborn? Because we've been burned. We run our own e-commerce and subscription products, and we've watched the data with our own eyes: after a user hits a broken entry point, the rest of that session falls off a cliff. They don't go back and try other features — they just leave. For an e-commerce site that has to take orders every day, a dead link isn't a blemish. It's a leaking cash register.

A 404 never destroys just one page — it destroys the user's trust in the whole site. Trust doesn't do partial damage.

A link is the smallest unit of a promise

Go one level deeper and a link is really a promise: "Click me, and I'll give you what you expect." A 404 is a broken promise, a blank page is a brush-off, and "feature under development" dumps your scheduling problem onto the user.

A user's trust in a brand is built from hundreds of these tiny promises. The button responds when pressed, the form confirms when submitted, the thing the site says exists actually exists — each fulfillment is trivial on its own, but their sum is the feeling that "this company can be trusted." Conversely, any single broken promise makes the user re-evaluate every fulfillment that came before: were those actually reliable, or did they just happen not to be broken?

This is also why, in our shop, this rule doesn't belong to "quality assurance" — it belongs to "values." It's the same thing as being your own first user before delivery: your attitude toward details is your attitude toward users.

Something you can do today

No tools required. Open your website and click every single link. Navigation bar, footer, links inside articles, buttons, social icons — all of it. In our experience, on most sites that have been live for two-plus years, one pass like this catches at least a few broken ones.

Then do two things: fix what's broken, hide what's empty. Don't hang up "Coming Soon" — users won't anticipate it; they'll just remember that this part of your site was hollow. After this pass your website won't be prettier, but it will be honest. And from our own experience running products, honest is worth far more than pretty. If you'd like to know where else a website leaks silently like this, we can take a look — we do this kind of health check fast, because we do it on our own products every day.