Device-targeted short links — mobile vs desktop redirects

Device-targeted short links route iOS, Android, and desktop visitors to different destinations from a single URL — one slug, three (or more) outcomes. The redirect server inspects what the visitor's browser is and chooses where to send them: iOS App Store for iPhones, Google Play for Android, marketing landing for desktops. Same printed QR code, same tweet, same email. The mobile vs desktop redirect logic lives on the server, invisible to whoever clicks. The same one-slug-many-destinations pattern, swapping device for geography, is the country-and-region routing playbook for geo-targeted short links — different inspector, identical plumbing on the redirect side.

This post covers the four use cases that genuinely need this pattern, why User-Agent sniffing is unreliable and what to use instead, the deep-link trap that breaks the App Store fallback, the SEO consequence most teams miss, and a working policy you can copy. The sample widget at the bottom builds the JSON-shaped rule for you.

Why mobile vs desktop redirects exist at all#

Mobile is now most of the web. StatCounter's 2024-2026 data puts mobile share of global page views at about 60%, desktop at about 38%, and tablets at the remaining sliver. Any short link that's shared in an email signature, on a business card, in a social post, or on a printed flyer will see a click distribution that mirrors that — slightly more mobile, often a lot more depending on the audience. Sending all of those visitors to the same destination means roughly six in ten people land on a page that wasn't built for the screen in their hand. Spin up a working redirect in the no-signup short-link builder and watch the user-agent log for yourself before deciding whether the split is worth the trouble.

Four real cases drive the need for device-aware routing.

The first is the app-or-web case. You have a mobile app and a web property. A click from an iPhone with the app installed should open the app at the right deep-link destination. A click from an iPhone without the app should land on the App Store page. A click from Android should open the app or fall back to Google Play. A click from a desktop browser should open the web equivalent, because desktops don't run mobile apps. One short link that handles all four behaviours is a useful product; four separate links you have to remember to share appropriately is not.

The second is the B2B-versus-B2C case. A consulting firm runs a campaign with a mobile-optimised lead-gen funnel for casual readers and a richer desktop landing for procurement people who'll actually click "request a demo". The same printed QR code at a trade show works for both — phone scans land on the short funnel, laptops land on the deeper page. Without device-aware routing, you'd ship two QR codes side-by-side and explain the difference, which nobody reads.

The third is pricing or coupon variation. Some products price differently by device class — mobile-app subscriptions through iOS take a 15-30% Apple cut that doesn't apply on the web. A coupon link that points web visitors at the cheaper web checkout and mobile visitors at the in-app subscription is a margin decision, not a UX decision. It's also a common one in published-content businesses (newspapers, streaming services).

The fourth is bot-and-crawler handling. Search engine indexers, link-preview fetchers, and uptime monitors all hit your short link before any human does. You want them to receive a clean indexable destination — usually the desktop landing page with full metadata — not a 302 to the App Store, which Google can't index and which corrupts your search snippet. Device routing for bots is an SEO necessity, not a feature.

User-Agent strings — what they say and what they mean#

Every browser sends a User-Agent header on every request. It's the first thing your redirect server can look at. The catch: the User-Agent string was never designed to be reliable, and decades of browser-compatibility hacks have made it actively misleading.

A typical iPhone User-Agent looks roughly like this: Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1. That single string claims to be Mozilla, AppleWebKit, KHTML, Gecko, and Safari simultaneously — none of those except "Safari" are accurate, but every claim is in there because some legacy server somewhere checks for that specific substring before serving content.

The reliable substrings — the ones that actually mean what they sound like — are short. For iOS phones: the literal string iPhone (and historically iPod, though that's near-extinct now). Notably not iPad, which since iPadOS 13 sends a desktop Safari User-Agent by default. For Android phones: the substring Android combined with Mobile. Android tablets typically don't include Mobile and should be treated as desktop or tablet. For bots: the substring bot or crawler or specific names like Googlebot, bingbot, Slackbot-LinkExpanding, WhatsApp, Twitterbot, facebookexternalhit. For desktop: the absence of the above, which is what makes desktop the default fall-through, not a positive match.

What you should not do is pull in a 200KB browser-detection library to handle this. The library will encode every quirk back to Internet Explorer 6, will rebuild itself on every request if you're not careful, and will make the routing decision opaque. Five lines of substring matching, in the order above, handles 99% of real traffic correctly and runs in microseconds.

Client Hints — the modern direction, slowly#

User-Agent strings are deprecated in spirit if not yet in practice. Google's User-Agent Reduction project, rolling out since Chrome 100, freezes the User-Agent string at fixed values and pushes real device information into a new family of HTTP headers called Client Hints. The hints — Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Sec-CH-UA-Model — say things like "Android", ?1 (mobile yes), and "Pixel 7" directly, without the legacy mess.

The catch is that Client Hints only show up if both the browser supports them and the server has previously asked for them via an Accept-CH response header on a prior request. That doesn't fit the short-link redirect pattern, where the first request is also the only request. So redirect-side device targeting in 2026 is still mostly User-Agent substring matching, with Client Hints used as a confirmation when present. Treat them as an upgrade, not a replacement — read Sec-CH-UA-Mobile if it's in the request, fall back to substrings when it's not.

Deep links — the trap that loses the context#

Here's where most device-targeting setups fail in subtle ways. You have an iOS app called Notebook with a custom URL scheme notebook://. You want a short link that opens notebook://note/abc123 if the app is installed, and falls back to the App Store page for Notebook if not. The naive setup: redirect iOS visitors to notebook://note/abc123. If iOS knows the app, it opens. If not, the user sees a confusing "cannot open" dialog.

The slightly less naive setup is "redirect to the app, and if that fails, redirect to the App Store after a timeout." This is the pattern you'll find in most older blog posts and most third-party deep-linking SDKs. The problem: there's a race condition between the app trying to open and the timeout firing. On iOS in particular, if the app does open, the timeout might still execute in Safari in the background, and when the user closes the app and returns to Safari, they're staring at the App Store page for an app they just used. Worse, the deep-link target (/note/abc123) is lost — the App Store doesn't know what content the user wanted, so even if they install the app, they land on its home screen rather than the note.

The right answer is Universal Links on iOS and App Links on Android. These are platform-level features that Apple and Google built specifically to solve this race condition. You associate a domain (yourapp.com) with your app via a signed JSON file at https://yourapp.com/.well-known/apple-app-site-association (and the equivalent assetlinks.json on Android). When iOS sees a click on any URL on that domain, it asks the OS — not the redirect server, not the browser — whether the app is installed. If yes, the app opens with the full URL as the deep-link context. If no, Safari opens the URL normally, and your redirect server can serve the App Store page from there.

The handoff happens before your redirect server is involved at all. That's the whole point. If the app is there, the OS opens it directly with the full URL — https://yourapp.com/note/abc123 — as the deep-link context. The app receives the URL, parses out the path, and shows the right note. If the app isn't there, the request reaches your redirect server normally, and you serve the App Store page from there. No race condition, no lost context.

The work to set this up isn't trivial — you have to publish the association JSON, configure entitlements in the iOS app and intent filters in the Android app, and verify the domain — but the alternative is a custom-scheme redirect that loses the deep-link context every time the user doesn't have the app. Apple's Universal Links documentation and Android's App Links documentation walk through the setup; both are linked in the sources at the end.

SEO — what Googlebot should see#

Search engines crawl every URL they discover, including short links shared on indexable pages. Googlebot's User-Agent is, predictably, Googlebot (with variants like Googlebot-Image, Googlebot-News). Bing's is bingbot. If you redirect Googlebot to your iOS App Store URL, two things happen.

First, Google sees a 302 to apps.apple.com, which is not your site. The crawler doesn't follow App Store URLs as canonical destinations; it logs the redirect and gives up. Your short link becomes invisible in search results because there's no indexable content behind it. Second, the link-preview crawlers — Slackbot, Twitterbot, facebookexternalhit, WhatsApp's preview fetcher — also hit the redirect when someone shares the short link. If your route serves them an iOS-only deep link or an App Store page, the preview card shows nothing useful. A broken or empty preview kills click-through.

The fix is to add a positive bot check at the top of your routing logic. Any User-Agent matching a curated list of crawlers and preview fetchers receives the indexable web URL — never the App Store, never a deep link. The list to start with: Googlebot, bingbot, DuckDuckBot, YandexBot, Slackbot, Twitterbot, facebookexternalhit, WhatsApp, LinkedInBot, Discordbot, TelegramBot. That covers around 95% of real bot-and-preview traffic. Anything else falls through to normal device routing. Linked.Codes maintains this list as part of its bot filter — the same one the analytics tracking debug guide references for click-counting accuracy.

Tablets — the iPad question#

Tablets are awkward. They're physically big enough to use desktop sites, often used in landscape like a laptop, and increasingly identify as desktop browsers anyway. Apple made this official in iPadOS 13 — by default, iPads now send the same Mac Safari User-Agent that a MacBook would. The honest default is to treat tablets as desktops unless you have a specific reason not to. Most "mobile" UX — small touch targets, bottom-fixed CTAs, swipe gestures — degrades on tablet, and most desktop experiences work fine on tablet.

Android tablets historically sent Android without the Mobile substring — that's the canonical way to tell them apart from phones, and modern Chrome on Android tablets follows the same convention. Routing on Android + Mobile together (rather than just Android) is what prevents Android tablets from being mistakenly sent to Play Store mobile-app URLs.

Smart TVs and the QR-code-on-screen pattern#

People scan QR codes pointed at a TV screen now — login flows for streaming services, "scan to authenticate", broadcast ads with a QR code in the corner. The QR code on screen is read by a phone, which is what executes the redirect. Routing logic doesn't need to know about the TV in that case; the request comes from the phone.

But TVs also browse the web. Tizen (Samsung), webOS (LG), Roku, Fire TV, Apple TV — all have built-in browsers, and short links shared in TV-app contexts sometimes get clicked from the TV itself. The User-Agent for these devices typically includes recognisable substrings: SMART-TV, Tizen, WebOS, BRAVIA, AppleTV. They are not phones, and not "desktops" in any useful sense. The pragmatic default is to route TV User-Agents to your desktop landing page — large screen, remote-control navigation, mobile-optimised pages are unusable. If you ship a TV-specific destination ("scan this code with your phone"), add it as a fourth route. Most teams won't need it.

A working policy#

Here's a policy block in the shape most short-link platforms can take. The widget below builds your version of it.

{
  "rules": [
    { "match": "bot", "destination": "https://example.com/" },
    { "match": "ios", "destination": "https://apps.apple.com/app/id123456789" },
    { "match": "android", "destination": "https://play.google.com/store/apps/details?id=com.example" },
    { "match": "default", "destination": "https://example.com/download" }
  ]
}

The order matters. Bot check first — otherwise Googlebot trips into the iOS branch when its User-Agent happens to include the word Mobile. iOS second, Android third, desktop default. Each match is a substring rule, evaluated in order. The first match wins. The default catches anything that didn't match — desktop browsers, smart TVs, weird devices, missing User-Agent headers. The platform-side configuration for this on Linked.Codes lives in the short-links docs.

Build your routing rule#

Plug in the destinations for each device class. The output is a JSON-shaped policy block you can paste into a config, plus a live "what happens for this visitor" preview that updates with the device pick.

The defaults populate with a generic app-or-web case — App Store, Play Store, web download page, plain web URL for bots. Edit any of the four fields and the policy JSON updates live; switch the visitor type to see which rule fires for each.

Related reading#

• UTM parameters that actually matter for short links — campaign attribution layered on top of device routing
• Branded short links — why your domain beats bit.ly — your domain, not the platform's, carries the routing rules
• Real-time link analytics — watching which device classes actually clicked, in real time
• Tracking links in email — email clients add their own User-Agent quirks worth knowing
• Bitly alternatives in 2026 — the field of platforms that handle device routing well