Web-to-App Fallbacks When the App Is Not Installed

Start with a page that works alone

Apple's description of universal links is also the best fallback rule we know: "because universal links are standard HTTP or HTTPS links, one URL works for both your website and your app. If the person hasn't installed your app, the system opens the URL in their default web browser, allowing your website to handle it." Android App Links work the same way, since they are web links that Android has verified.

So the first question for any campaign or notification link is not which app screen it opens, but whether the web page at that address is complete. An event page should show the event; a help link should show the help article. The rules Google applies to that page are in the mobile-first indexing guide. Links that went through Firebase Dynamic Links no longer work at all; moving off Firebase Dynamic Links explains what to replace them with.

The cases a fallback has to cover

Chrome intent links on Android

Each branch here maps to a step in the search-to-app route. Chrome on Android supports a special link form that names an app and a fallback in one address. The general shape is intent://HOST/PATH#Intent;scheme=...;package=...;end, and a fallback is added as an extra:

<a href="intent://www.example.com/events/123#Intent;scheme=https;package=com.example.sportsbook;S.browser_fallback_url=https%3A%2F%2Fwww.example.com%2Fevents%2F123;end">Open in the app</a>

Chrome's documentation says the visitor can be sent to the fallback URL when the intent isn't resolved or the app doesn't launch, and that Chrome removes browser_fallback_url before the app receives the intent. Only activities with the BROWSABLE category can be opened this way. For most routes a verified App Link is simpler: it needs no special markup and falls back by itself. Use the route inspector to read an intent link's parts and check that its fallback is an https address.

Why timer redirects fail

An old pattern tried to open a custom scheme and, after a short delay, send the visitor to the store. Chrome blocks the parts that make it work. Its documentation says Chrome won't launch an external app when a JavaScript timer tries to open it without a user gesture, won't launch one from an intent URI started without a user gesture, and won't launch one for an intent URI redirected from a typed-in URL. The visitor is left on a half-loaded step. Put the app choice behind a tap, and keep the page useful whatever the result.

Offering the store, carefully

A store link is a choice, not a fallback. Offer it with a banner, as the install banner guide describes, and only where the app is legally distributed. Google Play allows different gambling products in each market. A visitor in a market where the app is not offered should not be pushed to a listing they cannot use. Listing requirements per market are in store listings for licensed gambling markets. Why the web page stays the main address even when most visitors use the app is argued in canonical web pages in an app-first product.

If you want the app to open the original page after an install, that is a deferred deep link. It depends on extra data carried through the install, covered in privacy-aware web-to-app measurement, and is never guaranteed; the note on routing and attribution explains the limits.