What Is a Deep Link?

The term deep link started out in the web world, where it names a link that points straight to a specific inner page of a site, such as a product page itself rather than the homepage. That's the original meaning, and it still applies whenever the topic is internal link structure.

Mobile apps added a second meaning, the more common one today: an app deep link is a special link that opens a particular screen or piece of content directly inside an app, rather than just launching it on its home screen. A link to a product inside a shop's app that opens that exact product page instead of the general catalog is a typical example.

Both cases share the same idea: skip the generic entry point and take the user straight to what they were after. On a website, that navigation depth usually shows up in the page's breadcrumb; in organic search, Google often links directly to that inner page instead of the homepage.

At its core, a deferred deep link solves a coordination problem between installing the app and reaching the right content: without the app installed, no link can open it, so the system routes through the store first and only recovers the original destination afterward. Many campaigns wrap this process in a dedicated URL shortener, which also measures where each install came from.

An app deep link needs a way for the operating system to know which app to open. The oldest method is custom URI schemes, addresses with their own prefix like myapp://product/123, which the system associates with the app during installation. They work, but they carry a problem: if two different apps register the same scheme, there's no reliable way to know which one should open, and if the app isn't installed, the link simply fails without warning.

Current standards solve this with regular HTTPS links instead of custom schemes. On iOS they're called Universal Links, on Android App Links, and both work the same way: the app publishes a verification file on its domain, apple-app-site-association or assetlinks.json, proving to the operating system that the domain owner and the app publisher are the same entity. With that verification in place, the same link opens the app when it's installed and falls back naturally to the browser when it isn't.

The deferred deep link case adds one more piece: since the app doesn't exist on the device yet, neither the scheme nor the verification can act. The usual fix runs through a third-party attribution SDK, which keeps track of what content the user was after throughout the entire customer journey, from the ad click to the app's first launch after installing, and then opens that screen instead of the generic welcome one.

On a website, a clear internal link structure that reaches deep pages makes it easier for a crawler to find and index them, instead of only covering the homepage and top-level categories. That's one reason technical SEO still pays attention to something as old as a well-aimed link.

For apps, the stakes are mostly about conversion and measurement. A campaign that drops a user straight onto a product page inside the app, instead of just the home screen, cuts the steps between click and purchase, and that shows up in the campaign's conversion rate. A deferred deep link, on top of that, is what makes it possible to measure exactly which ad generated which install, something there's no way to know if the link just opened the app generically.

Google, for its part, can crawl and index app content through properly configured deep links, surfacing it in mobile search results for users who already have the app installed.

• Use Universal Links or App Links instead of custom URI schemes for any new link: they're safer and don't depend on no other app registering the same prefix.
• Check the apple-app-site-association or assetlinks.json file after every domain or certificate change; a failure there breaks verification with no visible warning.
• Define a clear fallback behavior for when someone opens the link without the app installed, instead of letting it fail silently.
• Test every deep link in both real scenarios, with the app installed and without it, not only from a desktop browser.
• If you're using an attribution SDK for deferred deep links, check what data it sends to third parties before integrating it, not just whether it works.
• On the website, link internally to deep pages with descriptive anchor text, not only from the main menu.

• Not setting up a clear error page for when a deep link points to content that no longer exists: the user hits a 400 error or a blank screen with no explanation.
• Still relying only on custom URI schemes in 2026, when Universal Links and App Links have long been the standard Apple and Google recommend.
• Forgetting to re-upload the verification file after a domain or hosting migration, breaking every deep link at once.
• Blaming a broken deep link on the app itself: the fault almost always sits in the domain verification or the link, not in the destination screen's code.
• Not measuring installs from a deferred deep link separately, losing track of which campaign actually generated them.