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.htmlTherefore 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…
Then 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.
$ 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_...
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."
"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
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.
You can even make an orphan branch and check out that branch into `dist/` as a worktree to keep it under version control.
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.