Searching for page.link will miss most of your dead Dynamic Links

Why does searching for page.link miss most dead links?

Firebase Dynamic Links shut down on 25 August 2025. Google’s deprecation FAQ is unambiguous about the scope: all links served by the service stopped working, both those hosted on custom domains and those on page.link subdomains. Clicked links return a 404; the Short Links and Link Stats API endpoints return 400 or 403.

The custom-domain half is what breaks the audit. A team that configured links.yourapp.com years ago has links that carry no Firebase signature anywhere in the URL. Grep the codebase for page.link and you get zero results, which reads exactly like we were not using this. The links are dead all the same, and the only thing distinguishing them from working links is that somebody has to click one.

So the audit does not start with a string search. It starts with a question: did we ever configure a custom link domain, and what was its hostname? Whoever set it up may have left. The record is in the Firebase console under Dynamic Links, in your DNS zone as a record pointing at Google, and in whatever runbook the person kept.

Once you have that hostname, it goes into every search below alongside page.link.

What should you search for?

Four patterns find nearly all of it, in rough order of how much each one turns up.

1. Your custom link hostname, if you had one. This finds the links nothing else will.
2. page.link — the automatically provisioned subdomains.
3. firebasedynamiclinks.googleapis.com — code that created links at runtime rather than embedding fixed ones. These fail differently: the API returns 400 or 403 rather than a link, so the failure surfaces as an error in your own code rather than a bad address.
4. The SDK imports — FirebaseDynamicLinks, com.google.firebase:firebase-dynamic-links, firebase/dynamic-links. Anything importing these is doing something that no longer works.

Run all four across every repository, not just the app. The marketing site, the email templates repository, the docs, the support macros and the internal tooling all publish links.

Where do dead links hide outside version control?

Searching code is the fast half. The links that actually cost you traffic are mostly not in code, and each of these has to be opened by hand.

The last three rows are worth separating out, because they are not a to-do list. A QR code already printed, a link compiled into a build that is already installed, and a URL on a page you do not control cannot be fixed by migrating. The address that redirect served no longer resolves, and no replacement product can revive an address it never served. What you can do is limit the next round: publish the new links on a domain you own so that a future migration is a routing change on your side rather than another shutdown on someone else’s.

The one that is not a marketing link at all

Firebase Authentication’s sign-in with email link relied on Dynamic Links. If your app used that flow, it is part of this migration and it is not in your marketing inventory — nobody thinks of an auth email as a campaign asset, and the person auditing bio links has no reason to open the auth code.

It fails as a support ticket rather than as a metric: users report that the sign-in email does not work, one at a time. Check it explicitly rather than waiting to be told.

How do you split what you found?

Once the inventory exists, sort it once before rebuilding anything, because the two halves have different answers and the split is the whole migration decision.

1. Links that only had to route. One address, App Store for an iPhone, Play for everything else, a preview page in between. This is most bio links, ad destinations, README badges and QR codes. Rebuilding these is an afternoon.
2. Links that carried a payload across an install. Invites, referral codes, share-a-specific-item links — anything where a brand-new user has to land somewhere specific after installing. This is deferred deep linking, it needs an SDK, and no link tool substitutes for one. What actually breaks in a referral flow covers this half.

Teams that skip the split usually assume everything is in the second bucket and turn a two-hour job into a procurement exercise. Google’s own replacement list encourages that reading — six of the seven products it names are measurement platforms — and most of that list is sized for a problem most migrating teams do not have.

While you are editing every link you own

You are about to touch every published address in the company, which makes it the cheapest moment you will ever get to fix something Dynamic Links never covered.

A store link opened inside Instagram’s or TikTok’s in-app browser frequently dies on a blank page. The link is not rejected and it is not malformed — the hand-off from the in-app browser to the store fails, silently, and the visitor leaves. A Dynamic Link was an HTTPS URL like any other and met the same wall, so if your bio link underperformed before the shutdown, this is a likely reason and it was never a Firebase problem. How that failure actually works is worth reading before you republish, because you only want to do this once.