Link rot: what happens to your short links when the shortener dies
A short link is two dependencies stacked on top of each other. The destination has to stay up, and the redirector has to stay in business and stay interested. goo.gl, tr.im, and a long tail of vanity domains have already broken links inside published papers, printed packaging, and archived records. Here is how shortener death actually plays out, and how to shorten in a way that survives it.
Every link is a bet that something will still be there later. A full URL bets on one thing: the destination. A short link bets on two, because between your reader and the destination sits a company that has to keep a database online, keep a domain registered, and keep caring.
Companies lose interest. That is not cynicism, it is the observed history of URL shortening, and it is the single strongest argument against using a shortener as a default.
How a shortener dies
There are four common endings, and they fail in different ways.
- Announced shutdown. The service publishes a date and stops serving redirects. Google did this with goo.gl: closed to new links in 2019, existing links scheduled to break, shutdown completed in 2025 after public pushback bought a delay. Announced is the best case, and it still breaks everything printed.
- Quiet abandonment. The domain stops resolving one day with no notice. This is the fate of most small vanity shorteners, including tr.im, which announced its own end back in 2009 and became the standard cautionary tale.
- Domain expiry and takeover. The worst case. The registration lapses, somebody else buys the domain, and now they control where every one of your printed links resolves. Nothing about the printed artifact changes. It just points somewhere new, and you do not find out.
- Policy change. The service stays alive but paywalls, throttles, or retires old links, or inserts an interstitial that did not exist when you created them.
Where the damage lands
Broken links on a web page are annoying and fixable. Link rot hurts most where the link cannot be edited after publication:
- Academic citations. Papers from the 2010s are full of shortened URLs, because journals limited reference length and authors wanted tidy footnotes. Those references are now unresolvable without an archive copy.
- Print and packaging. Manuals, labels, signage, business cards. The artifact outlives the service and cannot be recalled.
- QR codes. A code is an immutable printed string, so a redirect inside it is a permanent dependency. See QR codes are short links printed as pixels.
- Internal documentation. Runbooks and wikis full of short links to dashboards, where nobody remembers what the slug pointed at.
- Legal and archival records. Anything meant to be evidence of what a page said on a date.
The repointing problem is worse than the breaking problem
A dead link fails loudly. You click, you get an error, you go looking. A repointed link fails silently: the same short URL, the same printed square, a completely different destination, and no signal at all that the mapping changed.
This is inherent to the model. The short code is a key; the destination is a mutable column. Whoever holds the account can change it, and so can whoever inherits the domain. For anything where the identity of the destination matters - a citation, a contract, a published claim - a mutable pointer is the wrong instrument, and no amount of good behavior by the operator fixes the structural issue. That includes us.
What actually survives
- The canonical URL. Publish the full URL wherever length is not a hard constraint. It shows the destination, it has one failure mode instead of two, and it does not route your reader through anyone.
- A domain you control. If you need short links at scale, run them on your own domain. Then the mapping is portable: change the software underneath, keep every published link alive. This is the single highest-value decision in the whole topic.
- Your own copy of the mapping. Export slug plus destination and keep it somewhere you own. If you use our API, that export is a single request, documented on the API page. A mapping you hold can be rebuilt anywhere. A mapping only the vendor holds cannot.
- An archive snapshot for anything cited. Archive the destination and cite the archived copy next to the live URL. That way the reference survives both failure modes.
- Persistent identifiers where they exist. For scholarly work, a DOI is designed for exactly this problem and a shortener is not.
What this means for us
Forwrd is a dependency. If we shut down, links pointing through forwrd.us break, and no promise on this page changes the arithmetic. What we can do is make the dependency easy to leave: no account required to create a link, a plain HTTP redirect rather than a JavaScript interstitial in the path, exportable link data for account holders, and an API that gives you your slugs and destinations in one call. Those are the properties that let you walk away, and you should expect them from any shortener you commit printed material to.
We would rather you use a short link where it earns its place - print, slides, QR codes, character-limited fields, spoken URLs - and use the full link everywhere else. If you want the rest of our position stated plainly, including what a click does and does not record, that is in what forwrd.us logs when someone clicks.
Frequently asked
What is link rot?
Link rot is the gradual failure of URLs over time. A link stops resolving because the page moved, the site was restructured, the domain lapsed, or the host disappeared. Short links add a second, independent cause: the redirector itself can vanish, which breaks the link even when the destination is still perfectly healthy.
Did goo.gl links stop working?
Google closed goo.gl to new links in 2019 and announced that existing short links would stop serving redirects, with the shutdown landing in 2025 after a partial reprieve. Because goo.gl was used heavily in academic papers, documentation, and printed material during the 2010s, the shutdown broke links inside published work that nobody can reprint.
How do I future-proof a short link?
Use a shortener on a domain you control, so the mapping can be moved if the service behind it changes. Keep a record of every slug and its destination, so the mapping can be rebuilt from your own data rather than recovered from someone's database. Prefer the full canonical URL for anything meant to be durable, and where a citation matters, archive the destination and cite the archive alongside the live link.
Are long URLs really more reliable than short ones?
For durability, yes. A long URL has one point of failure - the destination. A short URL has two, because it also depends on the redirector staying online, staying funded, and keeping the domain registered. Short links win on other axes, such as fitting in print or a QR code, but not on longevity.
Related reading
What forwrd.us logs when someone clicks your link
Every shortener sits in the path of every click, which makes it an analytics checkpoint whether it advertises itself as one or not. Rather than write another piece about other people's logging, here is ours: what a click writes to our database, what it does not, what our hosting layer sees before our code runs, how long any of it lives, and which parts we cannot promise away.
12 min readQR codes are short links printed as pixels
A QR code is not a technology for trust. It is a machine-readable string with no human-readable preview, which is exactly why quishing works on people who would never click the same URL in an email. Here is what a QR code actually encodes, why the phone camera layer is where the risk lives, and how to publish one without turning it into a permanent dependency on a company staying alive.
13 min readHow to check where a short link goes before you open it
The whole function of a short link is that it hides the destination, so the usual advice to read the URL before clicking does not apply. There are still reliable ways to resolve one without loading the page. Here is what works, what does not, and why an unfurled preview in a chat app is not the same as knowing where a link points.
11 min read