You know that sinking feeling. You click a link, and instead of the page you expected, you get a 404. A blank page. A dead end. That’s not just a technical error. It’s a betrayal. Someone, somewhere, decided that the link they gave you wasn’t worth keeping alive. And the web lost a little bit of its trust.
Most people treat URLs as technical locators. Bits of text to manage, rename, redirect, or delete when the next redesign comes along. But they’re wrong. A URI is a promise to the future. Once you publish it, you don’t own it anymore—the web owns it.
That’s what Tim Berners-Lee and the W3C tried to tell us in 1998 with the classic article Cool URIs Don’t Change. It wasn’t a suggestion. It was a design constraint. The web’s entire value depends on the stability of its identifiers. Every link you publish becomes part of the shared infrastructure. Rename a URL, and you break every bookmark, every tweet, every academic citation that relied on it.
We think of URLs as addresses. They’re actually handshakes. When you give someone a link, you’re saying, I’ll be here. You can build on this. Changing a URI isn’t maintenance—it’s breaking public trust. And in a decentralized web, the only enforcement is your own discipline.
Remember when Digg redesigned in 2010 and all those old links died? That wasn’t a redesign. That was a breach of contract. Thousands of conversations, references, and ideas vanished overnight. The same thing happens every day on smaller scales: a blog moves to a new CMS, a product page gets reorganized, a company rebrands. Each time, someone’s bookmark breaks. Each time, trust erodes just a little more.
You might think, But I have redirects. I’ll use 301s. Redirects are better than nothing, but they’re not a solution. They’re a crutch. A redirect is an apology for a broken promise. The best apology is to never need one.
This is the uncomfortable truth: the web is defined by continuous change, yet its long-term value depends on deliberately freezing certain identifiers. Progress requires a form of permanence that seems anti-innovative but is actually foundational. The most innovative companies are the ones that treat their URLs like concrete—once poured, they don’t move.
So take a stand. When you’re about to rename a URL, stop. Ask yourself: Am I about to break a promise? If the answer is even maybe, don’t do it. Build around the old link. Keep it alive. It’s not just a string of characters. It’s a commitment to the person who clicked it.
The next time you see a 404, don’t just curse the broken link. Think about the promise behind it. And then make your own promises unbreakable. Cool URIs don’t change. And neither should your commitment to the web you’re building.
FAQ
Q: What's the practical difference between a URL and a URI?
A: A URL is a type of URI that specifies both the identity and the location of a resource. In practice, for web pages, the terms are often used interchangeably. The key point is that any identifier you publish on the web should be stable and permanent.
Q: Why is this still relevant today when we have redirects and link rot tools?
A: Redirects are a workaround, not a fix. They rely on the publisher maintaining the redirect forever. Link rot tools can only detect broken links, not prevent them. The only true solution is to never change your URIs in the first place. Every time you change a URL, you break the chain of trust.
Q: What if I need to change my domain or restructure my site?
A: If you must change a domain, use permanent 301 redirects from every old URL to the new one, and keep those redirects in place indefinitely. But even better: design your URL structure to be independent of domain changes. Use content-addressable or hash-based schemes. The goal is to ensure that the identifier remains meaningful and accessible regardless of organizational changes.