redirect - 服务器如何知道何时提供放大器页面

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当然是一种完全不同的动物，既是开源的又是一种网络技术，与内容的 native 应用程序平台相反，但网络和 native 平台相互对立，而谷歌提供了大量的应用程序， ServiceWorker 等技术清楚地表明，他们正在插入将网络作为一个内容平台——这应该不足为奇，因为花在 Facebook 或 Apple 应用程序上的时间是花在谷歌搜索及其广告上的时间，而谷歌则从中获得收入。

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

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

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

这似乎是对过去习惯的回归，你这么想是对的。尽管 AMP 的页面优化以及 HTTP 响应/传输时间很有值(value)，但重定向将立即减慢旅程的速度。在响应式网页设计出现和当前的顶峰之前，这就是满足移动用户的方式，尤其是在 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 会流行起来并成为一个长期存在的产品，浏览器最终会实现它。

想想看，如果您向移动设备提供内容，向使用旧版 Windows Phone 或 Blackberry 设备的用户提供 AMP 页面可能是不负责任的 whose browsers may not even properly support AMP .

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

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

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