Cool URIs That Survive: Building URLs That Don’t Rot

The bet that turned into a URL stress test

Picture a small website where every prediction has its own number-based page. Years pass. Servers get replaced, content gets reorganized, and “temporary” redirects quietly become permanent. Then the administrators do something surprisingly nerdy: they set a rule for a specific URL and schedule a check many years in the future.

That’s what the Long Bets prediction (Bet 601) was about. The test window ran on February 22, 2022 and required that visiting www.longbets.org/601 (or following a redirect from it) must still yield an HTML page containing a specific sentence about the URL no longer being available in eleven years. The bet duration was listed as 11 years (02011–02022). (longbets.org)

So what happened to the old URL? The whole point wasn’t that the site could magically keep the same storage forever. The point was whether the system behind the URL could keep honoring the identifier even after the implementation moved. That’s the difference between “keeping a file in place” and “keeping a name stable.”

Link rot isn’t random. It’s engineering failure modes.

Link rot is what happens when a link (a URL, or a broader URI) no longer points to what people think it points to. “What people think” can mean a page they bookmarked, a citation in a blog post, or an internal link in a documentation site.

Why does link rot feel inevitable? Because the modern web is full of churn:

• Pages get deleted during redesigns.
• Old routes get removed when frameworks change.
• Storage locations change when platforms migrate.
• Domain names shift, even when the brand stays.
• Path structures evolve (“we’ll clean up URLs later”).

There’s also a research-backed layer: content disappears at a measurable rate. Pew Research Center analyzed web content disappearing over time and reported that 38% of webpages that existed in 2013 were no longer accessible about a decade later. (pewresearch.org)

So when someone says “cool URIs don’t change,” they’re not being poetic. They’re pointing at a technical obligation: treat the URL space like an API you can’t afford to break.

“Cool URIs don’t change” means “design for permanence.”

Tim Berners-Lee’s classic guidance is blunt: a “cool URI” is one that doesn’t change, and people change them because of practical reasons. The essay also warns that exposing implementation details (like relying on a cgi-bin script layout) bakes in the future failure. (w3.org)

That “why” matters. Many URL rot problems are not caused by malicious intent. They’re caused by normal maintenance:

• “We rewrote the backend.”
• “We reorganized the CMS.”
• “We replaced the server.”
• “We cleaned up routing.”

If the URL design includes unstable elements (like scripts, internal directory structures, or version-specific paths), the URL changes the moment the system changes.

The engineering move is to separate identity from implementation. Identity is what the URL represents (“this prediction page”). Implementation is where that content lives right now (“this database row / this generated HTML / this folder on disk”).

The practical tool: HTTP 301 redirects

A URL doesn’t have to stay backed by the same file. It just has to keep resolving.

The most common mechanism for “resolving an old URL” is an HTTP redirect. HTTP is the web protocol that browsers and servers use. A redirect tells the client (browser, curl, a crawler) that the resource lives at a new address.

HTTP 301 means “Moved Permanently.” In the HTTP semantics specification, 301 indicates the target resource has a new permanent URI, and future references ought to use one of the provided URIs (usually via the Location header). (datatracker.ietf.org)

So the “stable URL” pattern looks like this:

• Keep the old URL path alive.
• Return 301 with a Location header pointing to the new URL.
• Ensure the old URL continues to resolve correctly for years.

In the Long Bets bet, the detailed terms explicitly allowed a 301 redirect from the old URL, as long as the redirected result still contained the required text. ()

How stable-URL systems are built (even when the site changes)

The tricky part is that a stable-URL promise is operational, not conceptual. You can’t “decide” URLs are permanent and stop thinking about it.

A workable stable URI system usually includes four layers.

1) Stable identifiers in the URL

The URL should encode something durable: a prediction number, a document ID, a year, or another identifier that won’t be invalidated by a redesign.

When URLs embed volatile structure (“where this page happens to live in our current framework”), you get rot during normal migrations.

2) A redirect mapping you treat like data

A redirect map is a database table (or config file) that stores pairs like:

• old URL → new URL
• and optionally metadata about when the redirect was created

The essential habit: redirect rules are part of the product. They need versioning, testing, backups, and review the same way features do.

3) Canonical destinations and content continuity

Redirects solve “where it goes,” but not “what it says.” The destination page must stay semantically correct.

In practice, that means:

• The redirected page should still render the expected content.
• If the content is generated, generation must remain reproducible enough to satisfy old references.

4) Continuous testing of legacy URLs

It’s easy to test new routes. It’s harder to test the old ones.

A stable URL program often includes a periodic job that checks key legacy URLs. The check can be lightweight (HTTP status codes and a presence-of-markers test) or deeper (snapshot tests of rendered HTML).

That’s exactly what the Long Bets terms do at the conceptual level: on a specific day, a specific legacy URL must still resolve to HTML containing a particular phrase. ()

A concrete “legacy URL check” you can run

If you want to see how these ideas translate to commands, imagine verifying that http://example.com/601 still resolves.

Step 1: follow redirects and capture the final HTML

curl -s -L http://example.com/601 | grep -F "The original URL"

Here, curl is a command-line tool for making web requests. The -L flag tells curl to follow redirects automatically. grep -F searches for a fixed string.

Step 2: check the redirect behavior itself

curl -I http://example.com/601

-I fetches only the headers. For an HTTP 301, you should see a 301 status code and usually a Location header pointing at the new URL. (datatracker.ietf.org)

The important engineering mindset: redirects are not a one-time migration artifact. They’re a contract.

Why archiving can help, but redirects must still win

Even with great redirect hygiene, some resources disappear anyway—legal takedowns, server outages, misconfigurations, or DNS changes.

That’s where web archiving enters the story. The Internet Archive’s Wayback Machine, for example, stores snapshots of public pages over time and lets users browse or “view, search, and save archived web pages.” (archivesupport.zendesk.com)

Archiving is a safety net. Stable URLs are the foundation.

If a site relies only on archives, then the link is still “fragile,” just preserved somewhere else. Redirect-backed persistence makes the web experience work for ordinary users and ordinary tooling.

Conclusion: permanence is a product feature

The Long Bets wager was entertaining because it turned a philosophical question into a scheduled verification: does a legacy URL still resolve in 11 years? (longbets.org)

Underneath the drama is a simple engineering truth. URLs don’t have to stay mapped to the same files, but the identity they represent must remain resolvable. That’s what “cool URIs don’t change” is really asking for: build your URL space like an API, use permanent redirects like HTTP 301, maintain a redirect map as living data, and continuously test the old identifiers.

The result is fewer dead links, fewer angry readers, and a web that behaves more like a library than a bonfire.

Notes on key facts

• Link rot rates and “digital decay” figures (including the 38% of 2013 pages becoming inaccessible) come from Pew Research Center’s analysis. (pewresearch.org)
• The “Cool URIs don’t change” guidance is from Tim Berners-Lee’s W3C-hosted essay. (w3.org)
• HTTP 301 “Moved Permanently” semantics are specified in RFC 9110. ()
• The Long Bets Bet 601 rules and timing are described on Long Bets. ()