App Store Redirect: One Link for iPhone and Android Users

People who search for "app store redirect" or "mobile redirect" usually want one of two things. Most want a single link they can put in an ad, an email, a social bio or on a printed QR code, which opens the right store on whatever phone taps it. Others want phone visitors to land on a mobile version of a website. This guide covers the app store case first, with copy-paste code, then the mobile-site case and what Google says about it.

Step 1: Get the two store URLs#

Every option below needs the public listing URL for each store. Both follow a fixed pattern:

• Apple App Store: https://apps.apple.com/app/id<your app ID>. The app ID is the number Apple shows as "Apple ID" under App Information in App Store Connect, or the number between "id" and "?" in the link from Apple's App Store Marketing Tools.
• Google Play: https://play.google.com/store/apps/details?id=<package name>. The package name is the application ID in your app's manifest; it is also shown in the Play Console.

Open both URLs on a phone and a computer before you use them. A listing that is not available in a country shows an error instead of the app, so test from the markets you advertise in.

Step 2: Choose how the device is detected#

There are four common ways to build the redirect. They differ in where the decision is made and how much you have to maintain.

Option A: A "Get the app" page with both badges#

The most robust app store redirect is not a redirect at all: one page with an App Store badge, a Google Play badge, a short description and a QR code for desktop visitors. Nobody is ever sent to the wrong store, it works in every in-app browser, and it gives you a place to explain what the app does.

On iPhone and iPad you can add Apple's Smart App Banner^[1] to the same page. It shows a banner at the top of the page that opens your App Store listing, or opens the app if it is already installed, and it does not appear on devices your app does not support. You add it with one meta tag in the page's head:

html<meta name="apple-itunes-app" content="app-id=000000000, app-argument=https://mybrand.com/get-the-app">

Option B: Redirect with a few lines of JavaScript#

Put this script on the "Get the app" page from Option A. Phones are forwarded to their store straight away; desktop visitors and anything the script doesn't recognise stay on the page and see both badges. Replace the two URLs with yours.

html<script>
  var IOS_URL = 'https://apps.apple.com/app/id000000000';
  var ANDROID_URL = 'https://play.google.com/store/apps/details?id=com.mybrand.app';

  var ua = navigator.userAgent || '';
  // iPads that request the desktop site report a Mac User-Agent, so check for touch too
  var isIPadDesktopMode = /Macintosh/.test(ua) && navigator.maxTouchPoints > 1;

  if (/iPhone|iPad|iPod/.test(ua) || isIPadDesktopMode) {
    window.location.replace(IOS_URL);
  } else if (/Android/.test(ua)) {
    window.location.replace(ANDROID_URL);
  }
  // Everyone else stays here and sees both store badges.
</script>

location.replace() is used instead of a plain link change so the store page replaces the redirect page in the history; when visitors tap Back they don't bounce straight into the store again.

Option C: Redirect on the server#

A server rule answers before any HTML is sent, so there is no flash of the page. This Nginx example sends /app to the right store and everything else to the badges page. Use a 302 rather than a 301: the answer depends on the device, and a permanent redirect can be cached by a browser or proxy and replayed for the wrong device. The Vary header tells caches that the response changes with the User-Agent.

nginxlocation = /app {
    add_header Vary User-Agent always;
    if ($http_user_agent ~* "iphone|ipad|ipod") {
        return 302 https://apps.apple.com/app/id000000000;
    }
    if ($http_user_agent ~* "android") {
        return 302 https://play.google.com/store/apps/details?id=com.mybrand.app;
    }
    return 302 https://mybrand.com/get-the-app;
}

The server only sees the User-Agent header, so an iPad in desktop mode is treated like a Mac and lands on the badges page. That is a safe fallback, which is why the last line should never point at one of the stores.

Option D: Use a deep-linking or smart-link service#

If you need more than a store redirect, for example opening a specific screen in the installed app, carrying that context through a fresh install, or attributing installs to campaigns, a mobile deep-linking or attribution platform is the right tool. These services generally ask you to add their SDK to the app.

If your links still use Firebase Dynamic Links (page.link URLs), replace them now. Google shut the service down on August 25, 2025, and clicked links return an HTTP 404^[2].

Step 3: Set it up and test it#

Whichever option you pick, the rollout is the same:

1. Copy your App Store URL and your Google Play URL (Step 1).
2. Publish a "Get the app" page with both store badges, a QR code and a link to your website.
3. Add the redirect: the script from Option B, the server rule from Option C, or your service's link.
4. Test the link on an iPhone, an iPad, an Android phone and a desktop browser, and once more inside the Instagram or Facebook app, where links open in an in-app browser.
5. Check what the link returns with our redirect speed test: the status code, where it lands and how fast it answers.
6. Use that one link everywhere: ads, emails, social bios, packaging and printed QR codes.

Opening the app when it's already installed#

A store redirect always opens the store listing, even for people who already have your app. To open the app itself, set up Universal Links on iOS and App Links on Android: you publish a small verification file on your domain, and links to that domain open in the app when it is installed and in the browser when it isn't. The Smart App Banner's app-argument does the same job for Safari visitors on your website.

• Desktop visitors: show the badges page with a QR code they can scan with their phone, rather than sending them to a store they can't install from.
• Give people a way out: a "Continue to the website" link on the badges page, so nobody who just wanted your site gets stuck.
• Manufacturer stores: if you also publish to stores such as Samsung Galaxy Store or Huawei AppGallery, add a rule for those brands before the general Android rule; every other Android device goes to Google Play.

Mobile redirects to a mobile website#

The other meaning of "mobile redirect" is sending phone visitors from www.example.com to a separate mobile site such as m.example.com. Google's advice is to avoid this setup if you can:

• Prefer responsive design. Google recommends responsive web design because it's the easiest pattern to implement and maintain^[3]: one URL and one HTML page for every device, so there is nothing to redirect.
• If you keep a separate mobile site, redirect each desktop URL to its equivalent mobile URL, never every page to the mobile homepage. Pages that redirect to an unrelated page can drop out of the index.
• Link the two versions. The desktop URL is the canonical and the mobile URL is its alternate, marked with rel="canonical" on the mobile page and rel="alternate" on the desktop page.
• Serving different HTML on the same URL (dynamic serving) needs a Vary: User-Agent response header, so caches and crawlers know the page changes with the device.

App store redirects don't have this SEO problem as long as the link is a dedicated campaign URL (like /app or go.mybrand.com/app) rather than a content page you want to rank. Don't redirect your homepage or blog posts to a store on mobile: you would hide that content from phone visitors and from Google's mobile crawler.

Where RedirHub fits#

RedirHub does not pick a store by device by itself; that decision belongs on your "Get the app" page or in your server rule. What RedirHub adds is the link in front of it: a short, trustworthy address on your own domain that you can print, share and change later.

• One link on your domain. go.mybrand.com/app is a branded short link that reads as yours in ads, bios and emails, and you can point it at a new page later without changing the link.
• A QR code that never needs reprinting. Tick "Also make a QR code" and the same link becomes a QR code you can update after printing, so packaging and posters keep working when the page moves.
• See who taps it. Clicks and unique visitors with bots filtered out, by country, device and operating system, so you can see how many taps came from iPhones versus Android phones.
• Fast and secure everywhere. Served from 130 global edge locations (PoPs), close to each visitor, with automatic HTTPS issued and renewed for your link domain. Only that subdomain's DNS record changes; your website and email stay where they are.
• No page hosting needed on Pro. The Custom HTML redirect type (Pro plan) serves your own HTML at the link's address, which is enough for a simple badges page.

To create the link in the RedirHub dashboard:

1. Connect your link domain, for example go.mybrand.com, under Hostnames and follow Connect DNS.
2. Create a new branded link.
3. In Destination URL, enter your "Get the app" page, for example https://mybrand.com/get-the-app.
4. In Short link, pick go.mybrand.com and type app.
5. Tick Also make a QR code if the link will be printed.
6. Click Create link, then share go.mybrand.com/app everywhere.

If you need deferred deep links or install attribution, a deep-linking platform is the better choice. If you need one trustworthy link and QR code that gets people to your app, a badges page with the script above behind a RedirHub link is enough, and a free badges page on your own site is enough on its own if you don't need to track or change the link.

Common app store redirect mistakes#

• Using a 301. The right destination depends on the device, so use a 302 (see 301 vs 302 redirects).
• No desktop fallback. Sending desktop visitors to Google Play or the App Store wastes the click; show the badges page and a QR code.
• Forgetting iPads. Safari on iPad usually requests the desktop site, so a plain "iPhone|iPad" check misses it. Add the touch check from Option B, or let the badges page catch it.
• Redirect loops in the browser history. Use location.replace() so Back doesn't send people to the store again.
• Dead store listings. If an app is removed or not available in a country, the store shows an error. Re-check both URLs whenever you change listings, regions or package names.