{"id":436,"date":"2026-03-13T17:00:00","date_gmt":"2026-03-13T22:00:00","guid":{"rendered":"https:\/\/tolinku.com\/blog\/?p=436"},"modified":"2026-03-07T04:45:29","modified_gmt":"2026-03-07T09:45:29","slug":"deep-linking-for-web","status":"publish","type":"post","link":"https:\/\/tolinku.com\/blog\/deep-linking-for-web\/","title":{"rendered":"Deep Linking for Web: Bridging Browser and App Experiences"},"content":{"rendered":"\n

Your app has a product detail page that loads in under a second, handles offline mode gracefully, and sends push notifications when a user's order ships. Your mobile website has the same content but it's slower, harder to navigate, and lacks those features. Yet a large chunk of your mobile users browse your site in a browser and never make it into your app.<\/p>\n\n\n\n

This is the web-to-app gap, and it costs real conversions. Deep linking for web is the set of techniques that closes it: detecting whether the app is installed, routing users into the right screen when it is, and providing a useful fallback experience when it is not.<\/p>\n\n\n\n

This article covers the full range of strategies, from the basic HTML meta tag to JavaScript detection APIs, server-side logic, and landing pages that work as graceful fallbacks.<\/p>\n\n\n\n

\"Tolinku\nThe route list page showing all configured deep link routes with paths, types, and actions.<\/em><\/p>\n\n\n\n

The Web-to-App Problem in Practice<\/h2>\n\n\n\n

Consider a few common scenarios:<\/p>\n\n\n\n

A user clicks a product link in a marketing email. They open it on their phone. They have your app installed. The link opens in their mobile browser, they browse the product, and they leave. They never saw the smoother in-app experience, and your push notification for abandoned carts never fires because the session was in the browser.<\/p>\n\n\n\n

A user searches for your brand on Google and taps an organic result. They land on your mobile site. No banner tells them an app exists. They convert on the web, but their data is siloed and you cannot retarget them with app-specific campaigns.<\/p>\n\n\n\n

A user shares a link to a product with a friend. The friend taps it, sees your mobile web page, and eventually finds the app store listing on their own, if at all. The context from that shared link (the specific product, maybe a referral code) is lost.<\/p>\n\n\n\n

Each of these scenarios has a solution, and the solutions layer together. None of them require replacing your website. The approach is progressive enhancement: the web experience works fine on its own, and you add layers to route app users into the app while converting non-app users.<\/p>\n\n\n\n

The Apple Smart App Banner Meta Tag<\/h2>\n\n\n\n

The quickest way to surface your app on iOS Safari is the apple-itunes-app<\/code> meta tag. Add it to your HTML <head><\/code> and Safari renders a small banner at the top of the page with your app icon, name, and a button to open or install the app.<\/p>\n\n\n\n

<meta name="apple-itunes-app" content="app-id=YOUR_APP_STORE_ID">\n<\/code><\/pre>\n\n\n\n
If you want the banner to open a specific screen when tapped, add the app-argument<\/code> parameter:<\/p>\n\n\n\n
<meta\n  name="apple-itunes-app"\n  content="app-id=YOUR_APP_STORE_ID, app-argument=https:\/\/yourapp.com\/products\/42"\n>\n<\/code><\/pre>\n\n\n\n
Your app receives the app-argument<\/code> value in the application(_:open:options:)<\/code> delegate method and can parse it to navigate to the right screen. This is Apple's simplest version of deep linking from the web.<\/p>\n\n\n\n
The limitations are real. The banner only works in Safari, not Chrome or other browsers on iOS. You cannot customize the banner's appearance. You get no analytics on how many users tapped it. And there is nothing equivalent built into Android.<\/p>\n\n\n\n
For many teams, that is enough to start. For teams that need more control, custom banners fill the gaps. Tolinku's smart banner feature<\/a> provides a cross-platform custom banner you can configure without building it yourself, including targeting rules, scheduling, and click tracking.<\/p>\n\n\n\n
Custom Smart Banners with JavaScript<\/h2>\n\n\n\n
If you want a banner that works on Android, works in Chrome on iOS, and gives you control over appearance and behavior, you build it yourself or use a library. The basic mechanics are straightforward.<\/p>\n\n\n\n
<!-- Banner markup (hidden by default) -->\n<div id="app-banner" style="display: none;">\n  <img src="\/app-icon.png" alt="App icon">\n  <div>\n    <strong>YourApp<\/strong>\n    <span>Open for the best experience<\/span>\n  <\/div>\n  <a id="app-banner-btn" href="#">Open App<\/a>\n  <button id="app-banner-close">\u2715<\/button>\n<\/div>\n<\/code><\/pre>\n\n\n\n
(function() {\n  var ua = navigator.userAgent;\n  var isIOS = \/iPhone|iPad|iPod\/.test(ua);\n  var isAndroid = \/Android\/.test(ua);\n\n  if (!isIOS && !isAndroid) return; \/\/ Desktop: no banner\n\n  var banner = document.getElementById('app-banner');\n  var btn = document.getElementById('app-banner-btn');\n  var close = document.getElementById('app-banner-close');\n\n  \/\/ Set the deep link URL based on current page\n  var deepLinkPath = window.location.pathname + window.location.search;\n  if (isIOS) {\n    btn.href = 'https:\/\/apps.apple.com\/app\/idYOUR_APP_ID';\n  } else {\n    btn.href = 'https:\/\/play.google.com\/store\/apps\/details?id=com.yourapp';\n  }\n\n  banner.style.display = 'flex';\n\n  close.addEventListener('click', function() {\n    banner.style.display = 'none';\n    \/\/ Store in sessionStorage so the banner doesn't reappear\n    sessionStorage.setItem('app-banner-dismissed', '1');\n  });\n\n  if (sessionStorage.getItem('app-banner-dismissed')) {\n    banner.style.display = 'none';\n  }\n})();\n<\/code><\/pre>\n\n\n\n
This is a starting point. In production you would also handle the "open app if installed" case with a URI scheme attempt, track clicks, and persist the dismissal in localStorage so users who have already seen and dismissed the banner do not see it again on their next visit.<\/p>\n\n\n\n
Attempting to Open the App Directly<\/h2>\n\n\n\n
The banner above links to the App Store or Google Play. That is safe: it always works. But if the user already has the app installed, you want to open the app directly instead.<\/p>\n\n\n\n
The traditional way to do this on the web is a custom URI scheme attempt. You write a deep link URL to your app's custom scheme, try to navigate to it, and see if anything happens.<\/p>\n\n\n\n
function tryOpenApp(deepLinkUrl, fallbackUrl, timeout) {\n  timeout = timeout || 1500;\n  var start = Date.now();\n\n  \/\/ Try the custom scheme\n  window.location.href = deepLinkUrl; \/\/ e.g. "yourapp:\/\/products\/42"\n\n  \/\/ If the app is not installed, nothing happens and we land here\n  setTimeout(function() {\n    \/\/ If the page is still visible (not hidden by app switch), redirect to fallback\n    if (Date.now() - start < timeout + 200) {\n      window.location.href = fallbackUrl;\n    }\n  }, timeout);\n}\n<\/code><\/pre>\n\n\n\n
The logic: you try to navigate to the custom scheme. If the app is installed, the OS hands off to the app and the user leaves the browser. If the app is not installed, nothing happens, and after the timeout you redirect to the fallback (usually the App Store or a landing page).<\/p>\n\n\n\n
The timeout approach has well-known reliability issues. Some browsers fire the fallback redirect even when the app does launch. Some OSes show a confirmation dialog that pauses the timer. iOS Safari in particular has changed its behavior for custom scheme handling across versions. Custom schemes are also not indexed by search engines and do not benefit from Universal Link or App Link trust.<\/p>\n\n\n\n
For more reliable behavior, use Universal Links on iOS and App Links on Android as your primary mechanism, with custom schemes only as a fallback for older OS versions.<\/p>\n\n\n\n
The getInstalledRelatedApps<\/code> API<\/h2>\n\n\n\n
The Web Application Manifest<\/a> and the getInstalledRelatedApps<\/code> API offer a more direct way to check whether your app is installed, at least on Android with Chrome.<\/p>\n\n\n\n
First, add your app to your web app manifest:<\/p>\n\n\n\n
{\n  "name": "YourApp",\n  "related_applications": [\n    {\n      "platform": "play",\n      "url": "https:\/\/play.google.com\/store\/apps\/details?id=com.yourapp",\n      "id": "com.yourapp"\n    }\n  ],\n  "prefer_related_applications": false\n}\n<\/code><\/pre>\n\n\n\n
Then query it from JavaScript:<\/p>\n\n\n\n
async function checkAppInstalled() {\n  if (!('getInstalledRelatedApps' in navigator)) {\n    return false; \/\/ API not supported\n  }\n  try {\n    var apps = await navigator.getInstalledRelatedApps();\n    return apps.some(function(app) {\n      return app.id === 'com.yourapp';\n    });\n  } catch (e) {\n    return false;\n  }\n}\n\ncheckAppInstalled().then(function(installed) {\n  if (installed) {\n    \/\/ Show "Open in App" button with direct deep link\n    showOpenInAppButton();\n  } else {\n    \/\/ Show "Get the App" banner\n    showInstallBanner();\n  }\n});\n<\/code><\/pre>\n\n\n\n
As of 2026, getInstalledRelatedApps<\/code> works reliably on Chrome for Android. It is not available on iOS, where Safari does not implement it. The API requires that your app declares your website in its asset links (the assetlinks.json<\/code> file at \/.well-known\/assetlinks.json<\/code>), so there is a two-way trust requirement, which is the same verification Android App Links need anyway.<\/p>\n\n\n\n
This API is genuinely useful for Android. It lets you show the right CTA without ambiguity: if the app is installed, offer to open it directly; if not, offer to install it. No timeout hacks required.<\/p>\n\n\n\n
Server-Side User Agent Detection<\/h2>\n\n\n\n
Not everything needs to happen in JavaScript. Server-side user agent detection is useful for redirects that should happen before the page renders at all.<\/p>\n\n\n\n
If you run a marketing site and want mobile users to land on a page optimized for app conversion while desktop users see the standard page, you can branch at the server or CDN level.<\/p>\n\n\n\n
In an Express app, for example:<\/p>\n\n\n\n
const mobileRe = \/Android|iPhone|iPad|iPod\/i;\n\napp.get('\/products\/:id', (req, res) => {\n  const isMobile = mobileRe.test(req.headers['user-agent'] || '');\n\n  if (isMobile) {\n    \/\/ Serve a lightweight landing page with app CTAs\n    res.render('product-mobile', { productId: req.params.id });\n  } else {\n    res.render('product-desktop', { productId: req.params.id });\n  }\n});\n<\/code><\/pre>\n\n\n\n
Be careful with this pattern. Serving completely different content based on user agent can create SEO problems if Google's crawler (which runs as a desktop agent) sees different content than mobile users. For SEO-sensitive pages, client-side progressive enhancement is safer. Server-side redirection makes more sense for dedicated campaign landing pages or post-click flows where SEO ranking is not a concern.<\/p>\n\n\n\n
User agent detection is also inherently imprecise. Tablet UA strings vary, in-app browsers report themselves as their host app, and the UA string can be spoofed. Use it as a strong hint, not a definitive signal.<\/p>\n\n\n\n
Landing Pages as Fallback<\/h2>\n\n\n\n
When a user taps a deep link and does not have the app installed, they need somewhere to go. A well-designed fallback landing page does several things at once:<\/p>\n\n\n\n