What happened to goo.gl, and what it means for your short links

Start with the short answer, because most of what is written about this is out of date: most goo.gl links still work.

Google announced that every goo.gl link would stop resolving after 25 August 2025. Three weeks before that deadline it changed the plan. A great deal of the coverage was published before the reversal and was never updated, which is why searching this topic today still returns confident claims that the entire service went dark.

It did not. Here is what actually happened, how to check a link you still have, and — more usefully — what the episode says about short links in general.

What actually happened

The sequence, according to Google's own announcement on the Developers Blog:

So the deciding factor was not the deadline. It was whether a given link had been used during late 2024. Links that were still in circulation were kept and, in Google's words, "will continue to function as normal". Links generated inside Google products such as Maps were excluded from the shutdown entirely.

The interstitial warning was the tell. A link that displayed "this link will no longer work in the near future" was on the deactivation list. A link that redirected silently was not.

How to check a link you still have

Google's own guidance is the simplest test: open the link. If it redirects without a message, it was retained.

If you would rather not open an unknown destination — a reasonable instinct — read the response headers instead. The redirect target sits in the Location header:

bash curl -sI https://goo.gl/abc123 | grep -i location

The -I flag requests headers only, and without -L curl stops at the first response instead of following the chain.

A deactivated or nonexistent goo.gl code now returns HTTP 404 — checked at the time of writing. There is no redirect and no explanatory page, which matters if you are auditing a large set of links programmatically: you are looking for a status code, not for text on a page.

One detail worth knowing if you encounter archived documentation: appending si=1 as a query parameter suppressed the interstitial on affected links. If you find goo.gl URLs carrying that parameter in old material, that is why.

The part that outlives goo.gl

The interesting question is not what Google did. It is why a link stopped working at all when nothing about the destination changed.

A short link is not an address. It is a lookup — a promise by a third party to keep translating a short code into a real address, indefinitely, for free. The destination server can be running perfectly and the link still dies, because the failure is in the middle.

That has a few practical consequences that apply to every shortener, including this one:

A short link is a dependency with no contract. Free services close. Companies get acquired. Domains lapse. The goo.gl case is unusual only because Google gave more than a year of notice and then softened the plan — most shutdowns are less generous.

Short links age badly in permanent media. A link printed in a book, etched into signage, embedded in a QR code on packaging, or cited in an academic paper cannot be updated after the fact. Those are precisely the places where a shortener should not be the only record of the address.

"Actively used" is not a property you control. The goo.gl criterion was traffic during a specific window. A link that mattered enormously to you but happened to sit unused in 2024 was deactivated; a link nobody cared about but that a scraper hit regularly survived. If a third party defines the retention rule, your archive is subject to it.

What to do if you have goo.gl links in old material

1. Inventory them. Search your site, documentation, repositories and exported content for goo.gl/. A repository-wide grep usually finds more than expected.
2. Resolve each one to its destination using the header method above, and record the full URL alongside the short one. The mapping is the thing worth preserving — once a shortener is gone, it cannot be reconstructed.
3. Replace the short link with the full address wherever the medium allows. In body text there is rarely a reason to keep a shortener at all.
4. Where you need a short link — QR codes, print, character-limited contexts — recreate it with a service you can migrate away from.

For links that were already deactivated, the destination is not recoverable from Google. If the page still exists, the Wayback Machine sometimes holds a snapshot of the goo.gl URL that reveals where it pointed.

Reducing the dependency

Nothing removes the middle step entirely — that is what shortening is. But two things change the risk profile.

The first is keeping your own copy of the mapping. If you can export short code to destination URL, a shutdown becomes a migration rather than a loss. Treat that export as part of your backups, not as something the provider holds for you.

The second is using a domain you own. With a custom domain, the short links point at a hostname registered to you, and moving them to a different provider is a DNS change rather than a rewrite of every published link. The trade-offs are discussed in more depth in custom domains for short links.

This is not an argument against shorteners. They solve real problems — measurable clicks, readable addresses, links that fit inside a QR code without turning into an unscannable grid. Those benefits are covered in short links: pros and cons, and the mechanics of the redirect itself in how URL shorteners work.

It is an argument for knowing what the dependency is, and for not making a free third-party lookup the only surviving record of an address you care about.

The current state, briefly

If you are reading this while holding a goo.gl link: open it or check its headers. If it resolves, it was retained and there is no deadline pending. If it returns 404, it was deactivated in August 2025 and the destination is not recoverable from Google.

Either way, copy the destination somewhere you control. That is the whole lesson.