服务器如何知道何时提供 amp 页面

Question

我知道会有一个版本的网站包含专为桌面设备设计的 HTML，然后是 AMP 页面。

为了让网站向移动设备提供 AMP 内容，我需要做些什么吗？

Answer 1

好问题！

总结：

• AMP 不提供自动重定向方式，仅为其搜索引擎（以及可能的其他网站/应用/搜索引擎将其用户发送到 AMP 页面）提供必要的标记
• 可以使用将移动用户重定向到移动网站的旧方法，通常是检测移动用户代理并通过 301/302 重定向将它们重定向到 AMP 页面
• 重定向移动用户可能不值得这样做，因为上述旧方法有点糟糕

---

完整答案：

就 Google 和搜索引擎结果页面 (SERP) 而言，您需要将其包含在桌面标记中：

<link rel="amphtml"
      href="https://www.example.com/url/to/amp/document.html">

这在您的 AMP 标记中：

<link rel="canonical"
      href="https://www.example.com/url/to/standard/document.html">

以便 Google 和 other high-traffic networks like Twitter, LinkedIn or Pinterest 检测到 amphtml 签名并将移动浏览器相应地定向到 AMP 页面。我会说 Facebook，但由于 AMP 是 Facebook Instant Articles 的竞争对手产品，我怀疑他们会拖后腿。

AMP 当然是一种完全不同的动物，它既是开源又是一种网络技术，而不是用于内容的原生应用平台，但网络和原生平台相互对立，而谷歌提供了大量在应用程序中，从 ServiceWorker 等技术可以清楚地看出，他们正在推动将网络作为一个内容平台——这不足为奇，因为花在 Facebook 或 Apple 应用程序上的时间是花在谷歌搜索及其广告之外的时间它的收入。

但我跑题了：显然这个 rel="amphtml" 声明只会指示 Google 等将此结果从他们的重定向到移动用户页。这是因为重定向策略不是谷歌或 AMP 团队的意图，他们宁愿设想一个每个人都通过谷歌或其他大玩家而不是直接访问或通过电子邮件或其他东西直接链接的世界。

理论上，它有朝一日可能会在浏览器级别实现，但浏览器供应商需要足够长的时间来标准化基本布局/样式属性和 JavaScript API，更不用说像 AMP 目前那样随机的非标准考虑因素了。 Apple 在浏览器方面会拖后腿，因为它将与他们自己的 News 应用程序竞争。

我们可以预期 AMP 重定向将在 Chrome 浏览器（以及因此 Opera）中实现，但即便如此也可能需要一段时间。因此，为了强制移动设备重定向到 AMP 页面而不是标准页面，您最终需要将 Web 服务器配置为嗅探移动用户代理（或不太常见的 MIME 类型）并重定向（使用302 for the sake of SEO) 到 AMP 页面。

这似乎是对过去习惯的一种回归，你这样想是对的。尽管 AMP 对页面优化以及 HTTP 响应/传输时间很有价值，但重定向会立即使旅程减慢一点。在响应式网页设计出现和达到顶峰之前，这就是满足移动用户的方式，尤其是在 WAP 时代。网站将提供在mob.website.com 或m.website.com 等子域下提供的移动友好版本。有一些针对移动设备的 XHTML，which are still used by Google+ for its "basic" pages（注意 DOCTYPE）。这些“基本”页面是为低屏幕分辨率的设备保留的，从这一行我们可以看出：

<link rel="alternate" 
      media="only screen and (max-width: 640px)"    
      href="/app/basic/+SOME_PAGE">

这种方法甚至可能成为 AMP 的灵感来源。

希望类似的重定向做法不会给您带来困难，因为您可能打算使用 amp.website.com 或者可能是您的 AMP 页面的子目录。

因为无论如何所有网站都应该是响应式的——in terms of SEO，并且因为unreliability of redirection techniques 和using user-agents and MIME types 作为一种检测方法，只针对移动设备变得更加困难——你可能会尝试估计连接访问者的速度或物理位置。

然后，如果连接速度较慢，或者如果用户远离您的源服务器，最好将他们重定向到 AMP 页面（因为它是从 Google 的 CDN 提供的并且使用 HTTP/2 + 重缓存以更快地提供内容）。

但是，任何 CDN 都可以用于所有页面，以便更快地将它们交付给所有人，而不仅仅是连接速度慢的用户或远离源服务器的人； AMP 的重点只是通过 CDN 提供部分内容，或许更多的是为以糟糕的 JavaScript 执行时间而闻名的设备（如手机）提供负责任构建的页面。

最终，我不会对所有移动用户强制执行重定向。我会把它留给谷歌来引导通过其搜索引擎到达的访问者被发送到 AMP 页面。如果 AMP 要流行起来并成为一个长期存在的产品，浏览器最终会实现它。

想一想，如果您正在向移动设备提供内容，那么将 AMP 页面提供给使用旧版 Windows Phone 或 Blackberry 设备whose browsers may not even properly support AMP 的人可能是不负责任的。

有很多事情要考虑，但我希望我已经为您的问题提供了答案，如果没有，在决定适合您的产品的正确答案之前，至少要牢记一些注意事项。

---

更多information about separate mobile sites, you can read this documentation on the subject由谷歌提供。

有关如何配置您的网络服务器以检测移动用户代理并将其发送到不同子域的示例，如果您搜索它们，您可以很容易地找到它们。

Answer 2

为了完整起见，我使用以下重定向将 AMP 页面提供给某些用户代理，它是启用了 mod_redirect 的 apache Web 服务器的 .htaccess：

<IfModule mod_rewrite.c>
RewriteBase /
RewriteCond %{REQUEST_URI} !/amp/$ [NC]
RewriteCond %{HTTP_USER_AGENT} (android|blackberry|googlebot\-   mobile|iemobile|iphone|ipod|\#opera\ mobile|palmos|webos) [NC]
RewriteRule ^([a-zA-Z0-9-]+)([\/]*)$ https://www.yoursite.com/$1/amp/ [L,R=302]
</IfModule>

Answer 3

恕我直言，这个问题值得更多关注。 amdouglas 答案很棒，完全涵盖了前端方面。至于服务器端，Jesús Diéguez Fernández 是一个好的开始，但需要加班维护才能保持准确（用户代理签名）。

为了完成这个（即使它不是与 PHP 相关的问题），下面是我使用服务器端重定向移动设备请求的 PHP sn-p。

它使用Mobile-Detect（+23M 下载量），其中包含极其完整且最新的用户代理字符串列表（应该很容易适应任何编程语言）。

<?php
require_once "libs/Mobile_Detect.php";
$detector = new MobileDetect();
$is_mobile = $detector->isMobile();