Cool URIs Don't Change (1998)
w3.org
w3.org
It's amazingly many news sites that also seem to scrub their URLs every time they do a redesign. Also uncool.
Or it's something about your own connection. Maybe an ad blocker? For me, the redirect works:
$ 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 got it specifically because they had a mini rant about the weight of switches that other vertical mice use, and while I couldn't tell if that was a real problem, that's the kind of mentality I used to ascribe to Logitech.
The MX4 is clearly marketing logic. The haptic feature adds nothing of note, and 100% feels like their marketing people got to preempt the core goal of making an ergonomic mouse so they could have a headline.
Location: https://logitech.com:443/mx
location: https://www.logitech.com:443/mx
location: https://www.logitech.com/en-us/mx.html
location: https://www.logitech.com/discover/c/master-series
location: https://www.logitech.com/en-us/discover/c/master-series.htmlBut the rest could have been flattened into the second redirect.
Therefore I try to make a local copy of a document that I link to.
There a plugin for Firefox that can check bookmarked links. You will be surprised how they vanish pretty fast…
But they shouldn't. Microsoft especially should make all of their documentation pages plain static HTML pages and keep them available forever.
But also, any Windows documentation can live offline in the OS itself. At least nowadays, I get how in the windows 98 / XP era they wanted to reduce disk usage.
The Event Log fwlinks still append the `ProdName=MicrosoftWindowsOperatingSystem` to the URL and the Microsoft Support homepage just ignores them helpfully asking "What do you need help with today?" and putting Windows on the second row of a 5 column grid.
Open the Event Viewer, click on an event and click the blue "Event Log Online Help" hyperlink at the bottom. I'll be willing to bet it won't matter what event you pick, you'll still end up at the Microsoft Support homepage.
Others take you on a roundabout journey to the Microsoft homepage.
> GET /fwlink/?LinkId=52884 HTTP/1.1
< Location: https://www.microsoft.com/products/ee/transform.aspx?[snip]
> GET /products/ee/transform.aspx?[snip] HTTP/2
< location: https://www.microsoft.com/?[snip]
> GET /fwlink/?LinkId=528884 HTTP/1.1
< Location: https://www.bing.com/search?q=get+help+with+file+explorer+in+windows&filters=guid:%224026535-en-dia%22%20lang:%22en%22&form=S00028Then I realized that they have a galaxy of consultants and experts that effectively make a living by keeping on top of all issues and fixing them for a fee. So there is little incentive for them to actually be user-friendly: as long as they are "partner friendly" with timely material, that's good enough.
They are not alone in this, btw - pretty much all major platform providers do this, one way or the other.
A common solution is to create placeholders at the old URLs with permanent redirects to the new URLs, but that doesn't fix all of the old hyperlinks, so it becomes extremely expensive to maintain backwards compatibility after 2 or more CMS changes.
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
> 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."
$ 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: Apachehttps://web.archive.org/web/20250000000000*/https://www.nsf....
Maybe its removal is related to this:
https://en.wikipedia.org/wiki/2025_United_States_government_...
You can even make an orphan branch and check out that branch into `dist/` as a worktree to keep it under version control.
"The original URL for this prediction will no longer be available in 11 years (2011)" (longbets.org)
https://news.ycombinator.com/item?id=49228458
186 points | 12 hours ago | 91 comments
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.
There are people in MS who knows this is an issue. But knowledge is not equal to behaviour.
This makes it difficult to share links to info on some products in forums, chat or a Wiki -- because the recipient may not be from the same country as I am.
See also: https://xkcd.com/869/ for a variation of the same problem.
When I worked for an ecommerce website, we spent weeks making sure every URL worked after a migration.
Nowadays it feels a little quaint because most of my 404s are from LLMs hallucinating URLs that never existed, sometimes for topics I never covered. I wonder what nonsense it attributes to me.
Unfortunately I'll never know for sure.
https://www.w3.org/Provider/Style/GuideStyle.css
H1 { margin-left: -20%; }
H2 { margin-left: -15%; }
H3 { margin-left: -10%; }
H4 { margin-left: -05%; }archive.org perhaps have/could have some interesting insights on it.
Not a reason not to have a redirect, but a reason that this happens.
So if I split up a resource into two new resources, where should the old link point to? It seems to me never changing URLs could only ever fully work for applications where the datamodel never changes.
I usually bookmark a link only to come back to a few days/weeks later. I don't expect a bookmark to work after years. I let the URL owners to have freedom to change it.
A thing that changes or goes away, feels natural. An URL that didn't change in 20 years, actually freaks me out, like a non-degradable plastic.
That's mostly about the social contract: if you publish something on the Internet, should it be made easier for the readers/users to access, or for you to move the thing around for whatever silly reason?
> I let the URL owners to have freedom to change it.
You know, you used the term "URL owners" twice, and I think I have a fundamental problem with this concept. The publisher ought not to own the URL, it really ought to belong to the consumers.
> A thing that changes or goes away, feels natural.
Yeah, but the URL is not a thing of nature, it's manufactured, and its original intent was that it was manufactured to last.
> An URL that didn't change in 20 years, actually freaks me out, like a non-degradable plastic.
A URL that doesn't change shares zero problems that non-biodegradable plastic has. In fact, the constantly changing URLs do have a couple of problems similar.
Also, you can try a different metaphor, like e.g. a rock or a mountain. It's a freaky thing, innit? Always there, unchanging... until people with excavators show up and turn a mountain into a quarry (which happened to several mountains, actually). Take it, nature!
If something is important to the site operator they will make their content discoverable. If something is important to the reader then they should archive/snapshot it.
In either case, stable URIs are non-essential but in the latter case you are protecting yourself from domain name changes too.