Firebase Dynamic Links shut down: what your page.link links do now (tested October 2026)

Firebase Dynamic Links was shut down on 25 August 2025. More than a year later, plenty of apps still hand out page.link addresses: in referral programmes, in "Download the app" posts, in QR codes on packaging. So what actually happens when someone taps one today?

We tested it. On 19 October 2026 we opened live page.link links from 13 different apps, the way a phone, an Android device and a laptop would. Here is what we found and what to do about it.

The short answer

Where the link is tapped	What happens today
iPhone	Google shows its own preview page. The app does not open by itself; the person has to tap through.
Android	The link is handed to Google Play services. If that doesn't take it, the person lands on the Google Play listing.
Desktop	The link still redirects to the fallback web address it was created with.
A path that never existed	404.

So most links still go somewhere. But "still goes somewhere" is not the same as "works", and it is not the same as "will keep working".

iPhone: the extra page costs you installs

Every page.link link we tapped as an iPhone showed a page hosted by Google instead of opening the app or going straight to the App Store. The person has to read it and tap again.

That extra step matters most exactly where these links are used most:

• Referral links. The friend who was sent the link is the person you most want to convert. A page they didn't expect, on a domain that isn't yours, is where many of them stop.
• Links inside Instagram, WhatsApp or Facebook. These open in the app's own browser, where an extra page and a hand-off to the App Store are even more fragile.

We also found one app whose link sent iPhone visitors to Google Play. Nobody notices that kind of bug from a desk, because on desktop the link looks fine.

Android: it depends on Google Play services

On Android the link becomes an intent:// address aimed at Google Play services' Dynamic Links handler, with the Play Store listing as the fallback. Whether that ends in your app on the right screen depends on code that Google has stopped supporting: the Dynamic Links SDK in your app is deprecated and receives no fixes.

We did not test whether a fresh install still receives the link's data on first launch (deferred deep linking). If your onboarding or referral credit depends on it, test it on a real device today rather than assuming.

The real risk: you don't control when it stops

Google's own FAQ said Dynamic Links would stop working after the shutdown. In our tests many still answer. That gap is not a promise. It means the day they stop is not yours to choose, and nothing will warn you.

Who can move their links without breaking them depends on one thing: whose domain they are on.

• Links on yourapp.page.link live on Google's domain. You cannot point that domain somewhere else. Every link already printed, posted or shared will go wherever Google sends it, for as long as Google answers. New links need a new home.
• Links on your own domain (Firebase let you use one, such as link.yourapp.com) are yours. Point the domain at a new provider, keep every path the same, and the links people already shared keep working.

How to move, step by step

1. Find every place your links are made or printed. The share or referral code inside your app (this is usually the biggest source), QR codes on packaging and posters, emails and push notifications, ads, social bios, and help pages. Old app versions on people's phones keep making page.link links until they update.
2. Decide on the new address. Use a domain you own, such as link.yourapp.com, so you never have to do this again. If you already used a custom domain with Firebase, keep it.
3. Recreate the links with the same paths. If yourapp.page.link/summer-sale was printed on a poster, create summer-sale on the new domain too. Anything that isn't a fixed campaign link (a product page, an invite with an id) should be handled by a rule that passes the path through to the app, rather than one link per item.
4. Set up the app side. On iOS, add the new domain to Associated Domains; on Android, add an intent-filter with android:autoVerify="true" for it. The domain must serve a valid apple-app-site-association file and assetlinks.json. Replace the Dynamic Links SDK's getInitialLink / onLink calls with your new provider's.
5. Ship the app update, then switch your share code. Links only open the app in builds that list the new domain, so ship first, then start handing out the new links.
6. Re-print what you can. Replace QR codes and links you control. Leave the old page.link ones alone; they'll carry on as long as Google lets them.
7. Test on real phones. iPhone and Android, app installed and not installed, and from inside Instagram and WhatsApp.

Check your own link

Two free tools that need no sign-up:

• Link checker: paste any link and see what iPhone, Android, desktop and in-app browsers get, plus whether your Apple and Android verification files are valid.
• Firebase Dynamic Link decoder: paste a long page.link address and see every parameter it carries, so you know what to recreate.

Where DL2App fits

We built DL2App as a flat-priced replacement for Dynamic Links, so this is our area. Things that matter for a migration:

• Import from Firebase. Upload your links and each Firebase parameter is mapped across: the deep link, the desktop, Android and iPhone fallbacks, the social preview and the UTM tags. Each link keeps its path.
• Your own domain, on every plan including the free one, so the next migration is never forced on you.
• Paths pass through to the app, so link.yourapp.com/invite/8F2K works without creating a link for every invite.
• No page to tap through on iPhone. With the app installed, the link opens it. Without it, the person goes on to the App Store by themselves, after a brief "Opening the App Store…" while the link is noted for after the install. Inside Instagram and other in-app browsers, a short page helps the person get out to the app or the App Store.
• Links keep working if you stop paying. Editing stops; redirects don't.

The migration guide walks through it end to end.

Questions people ask

Do page.link links still work in 2026? Many still answer as of 19 October 2026: desktop visitors are redirected, iPhone visitors see a Google preview page, Android visitors are passed to Google Play services. Google said they would stop, so treat every one of them as borrowed time.

Can I redirect my page.link domain to a new provider? No. page.link belongs to Google. Only links on a custom domain you own can be moved without changing the address.

What happens to links already printed on packaging or posters? They keep doing whatever Google's servers do with them. Recreate the same path on your new domain for the next print run.

Do I need to update my app? Yes. A link only opens your app if the installed build lists that domain (Associated Domains on iOS, a verified intent filter on Android).