For seven years, Firebase Dynamic Links (FDL) was the default answer to "how do I send someone from a link to the right screen in my app, even if they don't have it installed yet?". Then Google retired it. On August 25, 2025 the service shut down, and it took a lot of production links with it.
If you're reading this in late 2026, you've probably either migrated in a hurry or discovered a pocket of old links still returning 404s. This guide covers what actually broke, what can still be rescued, and how to choose a replacement.
What stopped working on August 25, 2025
Google's deprecation FAQ is specific about the behaviour after shutdown:
- Every Dynamic Link returns HTTP 404, both links on
*.page.linksubdomains and links on custom domains served through FDL. - The Short Links API and Link Stats API return 400/403 errors. Code that creates links at runtime fails.
- The SDKs don't crash your app, but they return empty data. iOS first-open attribution sends back an empty FDL object; on Android,
getDynamicLink()succeeds with nothing in it. Your onboarding code may silently treat every install as organic. - Link metadata was marked for deletion at shutdown and purged under Firebase's data retention policy.
The quiet failure in the third point is the one teams most often miss. Nothing throws an error. Users who tap a referral or a campaign link just land on the generic first screen, and conversion from those campaigns falls with no alert.
What you can still recover
Whether an old link can come back depends entirely on its domain.
Links on page.link: gone. Firebase's FAQ is unambiguous: .page.link domains can't be kept or transferred. Any URL like yourapp.page.link/abc is permanently dead. Replace it everywhere you still control it: email templates, app store descriptions, help-centre articles, printed material at its next print run.
Links on your own custom domain: recoverable. If your links looked like links.yourapp.com/promo, the domain is still yours. Point it at a new provider, recreate the links with the same paths, and every old URL resolves again: the QR code on last year's packaging, the link in a three-year-old email, the URL a chatbot memorised. Firebase's own FAQ notes that you can keep the same domain and path prefix with another provider. If you served FDL through Firebase Hosting rewrites, update those rules first.
This is the strongest argument for putting links on a domain you own. When a provider disappears, a custom domain turns a catastrophe into a DNS change.
Find what's still out there. Search your codebase, CMS, email platform and support macros for page.link and your FDL domain. Check app store listings and partner sites. For printed codes, keep a list and replace them on the next reprint.
Choosing a replacement: three paths
Whichever path you take, put the short link on a domain you control and pick a provider whose links don't lapse with a plan. (How crisp handles this; the Studio plan has early access to the deep-link surface.)
Path 1: App Links and Universal Links only (free)
If all you need is "tap a link, open the installed app at the right screen", the platforms do it natively:
- Android App Links: verified HTTPS links, configured with an
assetlinks.jsonfile on your domain. - iOS Universal Links: configured with an
apple-app-site-association(AASA) file on your domain.
Firebase publishes a migration guide for exactly this case. What you don't get: deferred deep linking (new users land on the generic first screen after install), automatic store routing, a web fallback page and click analytics. You build or skip those yourself.
Path 2: A deep-linking provider (full replacement)
If you relied on FDL's full feature set, you need a provider. Firebase's FAQ lists the features to match:
| FDL feature | What to check in a replacement |
|---|---|
| Route to the right store per device, web fallback | Per-platform rules and a configurable fallback URL |
| Deferred deep linking after install | How install matching works, and how it treats privacy |
| Deep links into an installed app | Universal Link and App Link hosting (AASA and assetlinks on your domain) |
| Click analytics | Per-link clicks, platforms, countries; bot filtering |
| Short links | Custom domains and editable destinations |
| Social preview metadata | Per-link title, description and image |
Firebase's FAQ names Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular as examples, and notes that Google hasn't vetted them. Prices and feature sets vary widely, so compare on the features you actually used rather than the full list.
Path 3: Build it yourself
You can host the AASA and assetlinks files, run a redirect service and match installs yourself. Deferred deep linking is the hard part. Neither platform passes the original link through an App Store or Play Store install, so any solution relies on matching a pre-install click to a post-install open. Do that carefully and with clear privacy disclosures. Budget for ongoing maintenance as platform rules change: Google cited exactly those ecosystem changes as a reason for retiring FDL.
Don't forget authentication flows
FDL also powered some Firebase Authentication flows on mobile, including email-link sign-in, password resets and email verification handled in-app. These need updated Firebase Auth SDKs and a migration to the new approach. Older app versions that still use the old SDK lose those features entirely. Web-only auth flows aren't affected. Check Firebase's FAQ section on authentication if your app uses email links.
A migration checklist
- Inventory every place your FDL URLs live, and sort them into
page.link(replace) and custom domain (revive). - Decide on the feature set: App Links and Universal Links only, or full deferred deep linking.
- Host AASA and assetlinks files on the domain your new links will use, and verify them with each platform's tools.
- Recreate custom-domain links with identical paths so the URLs already out in the world resolve again.
- Replace
page.linkURLs in every channel you control. - Update app code: remove the FDL SDK, add the new provider's SDK or your own handler, and test first-open and reopen flows on real devices.
- Migrate auth email-link flows if you use them.
- Watch your funnel: compare install-to-activation rates from links before and after, so a silent failure can't hide.
Lessons for the next shutdown
FDL's end was announced well in advance, and it still caught teams out, because links outlive the decisions that created them. Two habits make the next migration painless: keep links on a domain you control, and choose providers that let you export your links and data. Then if anything changes, you just point the domain somewhere else.
About crisp: crisp's deep-link engine (Universal Links and App Links hosting, store routing and deferred deep linking, with React Native and Flutter SDKs) is in early access on the Studio plan. Short links, dynamic QR codes and bio pages are available on every plan today. If you're still cleaning up after FDL, email us — we're onboarding early-access teams one at a time.