Cool URIs Don't Change (1998)

Not that long ago I clicked on a link that Microsoft provided somewhere in Windows -- could have been the event log, I don't remember. I do remember it was for a specific support article, but it ended up at a generic landing page for something. I am not talking about a link from Windows 95, it must have been Windows 10. But regardless, it is all gone. Then again, it probably wasn't a cool URL to begin with.

It's amazingly many news sites that also seem to scrub their URLs every time they do a redesign. Also uncool.

    $ curl -IL logitech.com/mx 2>/dev/null | grep http
    Location: https://logitech.com:443/mx
    location: https://www.logitech.com:443/mx
    location: https://www.logitech.com/en-ca/mx.html

I find that every time major companies as well as most authors switch blogging systems even if they maintain their URLs broadly, their RSS feed url breaks.

Sadly, though:

    $ curl -I https://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
    HTTP/2 404 
    content-type: text/html; charset=UTF-8
    content-length: 54737
    date: Sun, 09 Aug 2026 17:58:44 GMT
    strict-transport-security: max-age=31536000; includeSubdomains; preload
    server: Apache

What this page doesn't mention is 301 or 302 redirects. SEO has made "old URLs staying live" more of a widespread concern than it was at the time. And WordPress etc ship with inbuilt redirects upon slug rename

So to a large extent this has been mitigated and not using the suggestion here, which is to create a permanent URL ontology upfront

That said eventually neglect, removal, reorgs (or simply websites going offline) still happens... but the way the suggested goal has been advanced is due to becoming a business priority and with redirects and CMSes as tech to help

That said one suggestion made here turned out to be very useful and indeed is the default in WP:

   http://www.w3.org/1998/12/01/chairs

If you use date as part of the taxonomy then -- as Tim BL says here:

> A reason for using a topic area as part of the URI is that responsibility for sub-parts of a URI space is typically delegated, and then you need a name for the organizational body - the subdivision or group or whatever - which has responsibility for that sub-space. This is binding your URIs to the organizational structure. It is typically safe only when protected by a date further up the URI (to the left of it): 1998/pics can be taken to mean for your server "what we meant in 1998 by pics", rather than "what in 1998 we did with what we now refer to as pics."

A side effect of the idea that this information can be "permanent" means you should really think before putting it up there.

But today is not that, it is the opposite of that with stuff being put online that really doesn't need to be. This is permaweb vs slopweb.

A classic. This keeps getting more credible as it ages. Now it's been at the same URI for 28 years.

Great article, lots and lots of past discussion: https://hn.algolia.com/?q=cool+uris

If you run a statically generated website, I recommend append-only generation, where you keep your `dist/` (or whatever web root) stateful between builds. This guarantees you don't break URIs even if the static generator changes or the source content is removed.

You can even make an orphan branch and check out that branch into `dist/` as a worktree to keep it under version control.

I've been trying to keep all URLs backwards compatible forever on swizec.com and it's surprisingly hard. I _think_ anything from 2010 onward should be good. The domain started in 2005.

Unfortunately I'll never know for sure.