要点：

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当然是一个完全不同的动物，既是开源的又是网络技术，而不是内容的原生应用平台，但是网络和原生平台相互对立，而Google提供的数量很多对于应用程序而言，从ServiceWorker等技术中可以清楚地看出，他们正在推动网络作为内容平台 - 这应该不足为奇，因为在Facebook或Apple应用程序上花费的时间远离Google搜索及其广告，谷歌从中获得收入。

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

理论上，它可能有一天会在浏览器级别实现，但它需要浏览器供应商足够长的时间来标准化基本的布局/样式属性和JavaScript API，更不用说当前AMP的随机非标准考虑因素了。苹果公司将在浏览器方面拖后腿，因为它会与自己的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 ）。这些＆＃34;基本＆＃34;页面保留用于低屏幕分辨率的设备，我们可以从这一行看到：

<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设备的人whose browsers may not even properly support AMP提供AMP网页可能是不负责任的。

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

了解Google提供的更多information about separate mobile sites, you can read this documentation on the subject。

有关如何配置网络服务器以检测移动用户代理并将其发送到其他子域的示例，如果您搜索它们，则可以非常轻松地找到articles或code samples。

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代码段。

它使用Mobile-Detect（下载量超过2300万），其中包含令人难以置信的完整且最新的用户代理字符串列表（应该易于适应任何编程语言）。

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

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

3 个答案:

要点：

完整答案：