应用商店跳转：iPhone 和 Android 用户的一个链接

搜索“app store redirect”或“mobile redirect”的人通常想要两种东西之一。大多数人想要一个可放在广告、电子邮件、社交简介或印刷二维码中的单一链接，它能在任何手机点击时打开正确的商店。另一些人则希望手机访客进入网站的移动版本。本指南首先介绍应用商店的情况，附带可直接复制粘贴的代码，然后再介绍移动网站的情况以及 Google 对此的说法。

步骤 1：获取两个商店的 URL#

下面的每一种方案都需要每个商店的公开列表 URL。两者都遵循固定格式：

• Apple App Store：https://apps.apple.com/app/id<你的应用 ID>。应用 ID 是 Apple 在 App Store Connect 的 App Information 中显示为“Apple ID”的数字，或者是 Apple 的 App Store Marketing Tools 链接中“id”和“?”之间的数字。
• Google Play：https://play.google.com/store/apps/details?id=<包名>。包名是你应用清单中的 application ID；它也会显示在 Play Console 中。

在使用这些 URL 之前，请先在手机和电脑上都打开它们。某个国家/地区无法提供的列表会显示错误而不是应用本身，所以请从你投放广告的市场进行测试。

步骤 2：选择如何检测设备#

构建重定向有四种常见方式。它们在决定发生的位置以及你需要维护的工作量上有所不同。

选项 A：一个同时带有两个徽章的“获取应用”页面#

最稳妥的应用商店跳转其实根本不是跳转：用一个页面放上 App Store 徽章、Google Play 徽章、简短说明和一个供桌面访客扫描的二维码。这样就不会有人被送到错误的商店，任何应用内浏览器都能正常工作，而且还能为你提供一个地方来解释应用是做什么的。

在 iPhone 和 iPad 上，你还可以在同一页面添加 Apple 的 智能应用横幅^[1]。它会在页面顶部显示一个横幅，点击后会打开你的 App Store 列表；如果应用已安装，则会直接打开应用，而且不会在你的应用不支持的设备上显示。你可以通过在页面的 head 中添加一个 meta 标签来实现：

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

方案 B：用几行 JavaScript 进行跳转#

把这个脚本放到方案 A 的“获取应用”页面上。手机会立刻被转到对应商店；桌面访客以及脚本无法识别的设备会停留在页面上，并看到两个徽章。把这两个 URL 换成你的即可。

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 || '';
  // 请求桌面版网站的 iPad 会报告为 Mac User-Agent，因此也要检查触控能力
  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);
  }
  // 其他所有人都会留在这里，并看到两个商店徽章。
</script>

之所以使用 location.replace() 而不是普通的链接跳转，是为了让商店页面在历史记录中替换掉重定向页面；这样访客点“返回”时，不会又立刻跳回商店。

方案 C：在服务器端进行跳转#

服务器规则会在发送任何 HTML 之前就作出响应，因此页面不会出现闪现。下面这个 Nginx 示例会把 /app 发送到正确的商店，并把其他所有请求都送到徽章页面。请使用 302 而不是 301：因为结果取决于设备，而永久重定向可能会被浏览器或代理缓存，并在错误的设备上重复使用。Vary 头会告诉缓存，响应会随着 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;
}

服务器只能看到 User-Agent 标头，因此桌面模式下的 iPad 会被当作 Mac 处理并进入徽章页面。这是一个安全的兜底方案，因此最后一行绝不应该指向任一商店。

选项 D：使用深度链接或智能链接服务#

如果你需要的不只是跳转到商店，例如在已安装的应用中打开特定界面、在全新安装后保留该上下文，或将安装归因到营销活动，那么移动深度链接或归因平台就是合适的工具。这些服务通常会要求你将它们的 SDK 添加到应用中。

如果你的链接仍在使用 Firebase Dynamic Links（page.link URL），请立即替换。Google 已于 2025 年 8 月 25 日关闭该服务，点击这些链接会返回 HTTP 404^[2]。

第 3 步：设置并测试#

无论你选择哪种方案，实施流程都相同：

1. 复制你的 App Store URL 和 Google Play URL（第 1 步）。
2. 发布一个包含两个商店徽章、二维码以及你网站链接的“获取应用”页面。
3. 添加重定向：使用选项 B 的脚本、选项 C 的服务器规则，或者你所用服务的链接。
4. 在 iPhone、iPad、Android 手机和桌面浏览器上测试该链接，然后再在 Instagram 或 Facebook 应用内测试一次，因为这些链接会在应用内浏览器中打开。
5. 查看链接的返回情况，使用我们的重定向速度测试：状态码、落点以及响应速度。
6. 让这一条链接在所有地方都能使用：广告、电子邮件、社交简介、包装和印刷的二维码。

在应用已安装时打开应用#

商店重定向总是会打开应用商店页面，即使对于已经安装了你应用的人也是如此。要直接打开应用本身，请在 iOS 上设置 Universal Links、在 Android 上设置 App Links：你在自己的域名上发布一个小型验证文件，当链接指向该域名时，应用已安装就会在应用中打开，未安装则会在浏览器中打开。Smart App Banner 的 app-argument 对网站上的 Safari 访客也起到同样作用。

• 桌面访客： 显示徽章页面和一个可供他们用手机扫描的二维码，而不是把他们送到无法安装的商店。
• 给用户一个退出选项： 在徽章页面上提供“继续访问网站”链接，这样任何只想访问你网站的人都不会被困住。
• 制造商应用商店： 如果你还会发布到 Samsung Galaxy Store 或 Huawei AppGallery 等商店，请在通用 Android 规则之前为这些品牌添加规则；其他所有 Android 设备都进入 Google Play。

移动端重定向到移动网站#

“移动端重定向”的另一种含义，是把来自手机的访问者从 www.example.com 发送到一个独立的移动站点，例如 m.example.com。Google 的建议是：如果可以，尽量避免这种设置：

• 优先选择响应式设计。 Google 推荐响应式网页设计，因为这是最容易实现和维护的模式^[3]：每种设备共用一个 URL 和一个 HTML 页面，因此无需重定向。
• 如果你保留独立的移动站点， 请将每个桌面版 URL 重定向到其对应的移动版 URL，切勿把所有页面都重定向到移动首页。重定向到无关页面的页面可能会从索引中消失。
• 将两个版本关联起来。 桌面版 URL 是规范版本，移动版 URL 是其替代版本；在移动页面上使用 rel="canonical"，在桌面页面上使用 rel="alternate"。
• 在同一 URL 上提供不同的 HTML （动态服务）需要带有 Vary: User-Agent 的响应头，这样缓存和爬虫就知道页面会因设备而变化。

只要链接是专门的活动 URL（例如 /app 或 go.mybrand.com/app），而不是你希望排名的内容页面，应用商店重定向就不会有这个 SEO 问题。不要在移动端把主页或博客文章重定向到应用商店：这样会让手机访客以及 Google 的移动爬虫看不到这些内容。

RedirHub 的作用#

RedirHub 本身不会按设备自动选择商店；这个决定应由你的“获取应用”页面或服务器规则来负责。RedirHub 增加的是前面的链接：一个位于你自己域名上的简短、可信地址，你可以打印、分享，并在以后更改其指向。

• 你域名上的一个链接。 go.mybrand.com/app 是一个品牌短链接，在广告、个人简介和电子邮件中都像是你的链接，而且你以后可以把它指向新页面，而无需更改链接。
• 无需重新打印的二维码。 勾选“同时制作二维码”，同一个链接就会变成一个可在打印后更新的二维码，因此当页面地址变更时，包装和海报仍能继续使用。
• 查看有多少人点击。 按国家、设备和操作系统统计点击量与独立访客，并过滤掉机器人，这样你就能看到有多少点击来自 iPhone，而不是 Android 手机。
• 在各处都能快速且安全地访问。 通过 130 个全球边缘节点（PoP）提供服务，靠近每位访客，并为你的链接域名签发和续期自动 HTTPS。只有该子域名的 DNS 记录会更改；你的网站和邮箱仍保持原状。
• Pro 版无需页面托管。 自定义 HTML 重定向类型（Pro 方案）会在链接地址展示你自己的 HTML，这足以做一个简单的徽章页面。

要在 RedirHub 仪表板中创建链接：

1. 在 Hostnames 下连接你的链接域名，例如 go.mybrand.com，并按照 Connect DNS 的指引操作。
2. 创建一个新的品牌链接。
3. 在 Destination URL 中，输入你的“获取应用”页面，例如 https://mybrand.com/get-the-app。
4. 在 Short link 中，选择 go.mybrand.com 并输入 app。
5. 如果该链接将被印刷，请勾选 Also make a QR code。
6. 点击“创建链接”，然后在任何地方分享 go.mybrand.com/app。

如果您需要延迟深度链接或安装归因，深度链接平台是更好的选择。如果您只需要一个可信赖的链接和二维码，把人们带到您的应用，并在 RedirHub 链接后面使用上面的脚本来显示徽章页就足够了；如果您不需要跟踪或更改链接，那么自己网站上的免费徽章页本身也足够。

常见的应用商店重定向错误#

• 使用 301。 正确的目标取决于设备，因此请使用 302（参见 301 与 302 重定向）。
• 没有桌面端备用方案。 把桌面访问者送到 Google Play 或 App Store 会浪费点击；应显示徽章页和二维码。
• 忘记 iPad。 iPad 上的 Safari 通常会请求桌面网站，所以简单的“iPhone|iPad”检查会漏掉它。请添加选项 B 中的触摸检查，或者让徽章页来捕获它。
• 浏览器历史中的重定向循环。 使用 location.replace()，这样“后退”就不会再次把人们送回商店。
• 失效的商店列表。 如果应用被移除或在某个国家/地区不可用，商店会显示错误。每当您更改列表、地区或包名时，请重新检查这两个 URL。