page.link opens a Google preview page on iPhone? Why it happens and how to fix it

You tap a yourapp.page.link/… link on an iPhone and, instead of your app, Safari opens a Google page at preview.page.link. It shows your app's name, the link's title, a line saying "Save my place in the app. A link will be copied to continue to this page." and an OPEN button. Some people tap it. Many just close the tab.

This post explains where that page comes from, when the app opens without it, and how to get rid of it. We tested live page.link links from several apps on 29 October 2026, so the details below are what those links do today, not what the old Firebase docs said.

The short answer

• The preview page is Firebase's fallback for when iOS doesn't open your app straight from the link. Firebase Dynamic Links shut down on 25 August 2025, but Google's servers still answer many page.link links, and short links still send iPhones to this page.
• If the app is installed, iOS can still skip the page and open the app, because Google still serves the Apple verification file for page.link subdomains. That only happens where Universal Links work: Safari, Messages, Mail, Notes. Inside Instagram, Facebook, TikTok or a link typed into the address bar, people get the preview page.
• You can't switch it off any more. The Firebase console that held the "skip the preview page" setting is gone, and adding efr=1 to a short link made no difference in our test.
• The fix is a link on your own domain, so you control what an iPhone sees. Old page.link links keep doing whatever Google decides until they stop.

What we saw on 29 October 2026

We requested each link the way Safari on an iPhone does and followed the redirect:

Link type	What an iPhone got
Short link (app.page.link/3MEC)	A redirect to preview.page.link/…, Google's "Open in app?" page
Short link with ?efr=1 added	The same preview page
Short "download the app" link	A Google page that sends the browser on to the App Store with a script
Long link with only link, apn and isi	Straight to the website in link. No App Store and no app, because the link had no iOS bundle id (ibi)
apple-app-site-association on the page.link subdomain	Still served, with the app's id and /* as the paths

So the same shutdown service now behaves three ways, depending on how each link was built years ago. You can't fix any of them from the Firebase side.

Why Firebase shows a preview page at all

When someone taps a link to your domain, iOS decides whether to open the app before any web page loads. That decision is a Universal Link, and it only happens if:

1. the app is installed and lists the domain under Associated Domains,
2. iOS has fetched and accepted the domain's apple-app-site-association file,
3. the tap happened somewhere that hands links to iOS. Safari, Messages and Mail do. Most in-app browsers don't, and neither does typing or pasting the link into the address bar.

If any of those fail, Safari loads the link as a web page. Firebase then had to choose between jumping straight to the App Store and showing a page first. It chose a page, for two reasons:

• A tap from a person. On a page the person has tapped, Safari will try to open the app and fall back to the store, which a straight redirect can't do reliably.
• Deferred deep linking. The OPEN button copies the link to the clipboard. After an install, the Dynamic Links SDK read the clipboard on first launch to send the person to the right screen. Since iOS 16, reading the clipboard shows an "Allow Paste" prompt, so that hand-off now asks the person's permission first.

Firebase let you skip the page with the efr=1 parameter or a checkbox in the console. Skipping it meant losing the clipboard hand-off, so many apps left it on.

Why it costs you installs now

Each extra screen between a tap and the App Store loses people. This one is worse than most:

• It doesn't look like your app. It's a Google domain with a generic layout, and many people read it as spam or a broken link.
• Your app can lose the deep link. If your new app version no longer ships the Dynamic Links SDK, nothing reads that copied link, so the person who did tap through lands on your home screen.
• It turns up where your links are shared most. Referral links and "download the app" links mostly get tapped inside Instagram, WhatsApp and X. Universal Links rarely fire there, so the preview page is what most people see. Our Instagram in-app browser post covers what those browsers do.
• It can stop without warning. Google has said the service is shut down. When the servers stop answering, every one of these links breaks at once, including the ones in old posts, emails and QR codes.

Can I fix the page.link link itself?

No. You can't edit, re-create or re-configure Dynamic Links any more, and page.link is Google's domain, so you can't point it somewhere else. The parts you do control:

• New links. Stop sharing page.link addresses from your app, website and emails.
• What the app does on launch. Keep handling old page.link URLs in your app while installed versions still receive them, so taps that do open the app still land on the right screen.

How to replace it, step by step

1. Find every place that creates page.link links: share buttons, referral screens, email templates, QR codes, store listings, social bios. The Firebase Dynamic Link decoder shows what each parameter in a long link did, so you know what to recreate.
2. Pick a link domain you own, such as link.yourapp.com. A subdomain keeps it separate from your website.
3. Serve the Apple and Android files on it: apple-app-site-association with your app id and paths, and assetlinks.json with your package name and signing certificate. If either is wrong, iPhones and Android phones open the browser instead of the app. Our Universal Links checklist goes through the common mistakes.
4. Add the domain to the app: Associated Domains (applinks:link.yourapp.com) on iOS, and an intent-filter with android:autoVerify="true" on Android. Ship that app update.
5. Decide what an iPhone without the app sees. Usually that's a straight redirect to the App Store, or your own page with your branding and an App Store button. If you need deferred deep linking, your provider's SDK handles it on first launch.
6. Switch your share code to the new links, starting with the ones people tap most: referrals and invites.
7. Test on a real iPhone, with the app installed and not installed, from Safari, Messages, Instagram and WhatsApp.

The migration guide has the full checklist, including how to keep each link's path.

Check your own link

Paste any link into the free link checker, whether it's a page.link address or your new domain. It shows what an iPhone, an Android phone, a desktop and the main in-app browsers each get, and whether your Apple and Android files are valid. No sign-up needed. If you'd like to know when the links start failing, or when your new domain is fixed, the report has a "Watch this domain" button that emails you when the result changes.

Where DL2App fits

DL2App replaces Dynamic Links with links on your own domain, so you decide what an iPhone sees:

• No Google page in between. iPhones without the app go straight to the App Store. Inside Instagram and other in-app browsers, people get a hand-off page on your own domain. You can change either default per project or per link.
• We host the Apple and Android files for your link domain and check them on a schedule, and we email you if one breaks.
• Deferred deep linking on every plan, including Free. On iOS the clipboard hand-off is opt-in and only runs when the person taps a paste button in your app, so there's no surprise paste prompt.
• Import from Firebase. Each link keeps its path, and the Firebase parameters are mapped across.

The React Native SDK (including Expo) and the web SDK are live. The native iOS, Android and Flutter SDKs are built and in final testing. There's a free plan, and paid plans are flat monthly prices; see pricing.

Questions people ask

What is preview.page.link? It's the page Firebase Dynamic Links shows on iOS when the link doesn't open the app directly. It shows the app's name, an OPEN button, and a note that a link will be copied so the app can continue to the right page after an install.

Why does my page.link link open the preview page instead of my app? Either the app isn't installed, or the tap happened somewhere Universal Links don't work, such as an in-app browser or a link pasted into Safari's address bar. In those cases iOS loads the link as a web page and Google shows the preview page.

How do I skip the Firebase preview page? On a live Dynamic Links project you set efr=1 or ticked "skip the preview page" in the console. Since the shutdown the console is gone, and in our October 2026 test adding efr=1 to a short link still showed the page. The way to skip it now is to stop using page.link links.

Do page.link links still open the app on iPhone? Sometimes. Google still serves the Apple verification file for page.link subdomains, so an installed app that still lists the domain can open from Safari, Messages or Mail. Everywhere else, people get the preview page or a redirect.

Will my old page.link links keep working? For now, many still answer. Google has shut the service down and can stop serving the links at any time, so move your active links to a domain you own and treat the old ones as temporary.