How does the server know when to serve an amp page

Question

I understand that there will be a version of a site with HTML designed for desktop devices and then the AMP pages.

Is there anything I need to do so that the site serves AMP content to mobile devices?

Nattie

Answer 1

Good question!

Summary:

• AMP supplies no automatic means of redirection, only necessary markup for its search engine (and potentially other websites/apps/search engines to send their users to the AMP page
• Old methods of redirecting mobile users to mobile sites could be used, typically by detecting mobile user-agents and redirecting them via 301/302 redirect to the AMP page
• Redirecting mobile users might not be worth doing because the aforementioned old methods kinda suck

---

Full answer:

In terms of Google and the search engine results page (SERP), you will need to include this in your desktop markup:

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

and this in your AMP markup:

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

so that Google and other high-traffic networks like Twitter, LinkedIn or Pinterest, will detect the amphtml signature and direct mobile browsers to the AMP page accordingly. I would say Facebook but since AMP is a competitor product to Facebook Instant Articles, I suspect they will drag their heels.

AMP is of course a completely different animal, being both open-source and a web technology as opposed to a native app platform for content, but the web and native platforms stand in opposition to one another and while Google provides a great number of apps, it's clear from technologies like ServiceWorker that they are pushing for the web as a content platform—which should come as no surprise because time spent in Facebook or Apple apps is time spent away from Google search and its advertising, from which Google derives its revenue.

But I digress: obviously this rel="amphtml" declaration will only instruct Google et al. to redirect this result to mobile users from their pages. This is because a redirection policy was not the intention by Google or the AMP team, who rather envisage a world where everybody goes through Google or other big player rather than being visited directly or linked directly by email or something.

In theory, it might one day be implemented at the browser level, but it takes browser vendors long enough to standardise essential layout/styling properties and JavaScript APIs, let alone random non-standard considerations as AMP currently is. Apple will drag its heels when it comes to the browser because it would compete with their own News app.

We can probably expect that AMP redirection will be implemented in the Chrome browser (and therefore Opera), but even that could be a while yet. So, in order to force mobile devices to redirect to the AMP pages as opposed to your standard ones, you'd ultimately need to configure your web server to sniff for mobile user-agents (or less commonly supported MIME types) and redirect (use 302 for the sake of SEO) them to the AMP pages.

This may seem like something of a regression to past habits, and you'd be right to think so. The redirection will immediately slow the journey down a little bit, though AMP is valuable for its on-page optimisations as well as its HTTP response/transport time. Before the advent and current zenith of responsive web design, this is how mobile users would be catered for, especially in the WAP days. Websites would serve a mobile-friendly version served under a subdomain like mob.website.com or m.website.com. There were flavours of XHTML targeting mobile devices, which are still used by Google+ for its "basic" pages (note the DOCTYPE). These "basic" pages are reserved for devices of a low screen resolution, as we can see from this line:

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

This approach may have even served as an inspiration for AMP.

A similar redirection practice should hopefully not present a difficulty for you, because you probably intend to use amp.website.com or perhaps a subdirectory for your AMP pages anyway.

Since all websites should be responsive anyway — in terms of SEO, and because targeting only mobile devices is made more difficult by the unreliability of redirection techniques and of using user-agents and MIME types as a detection method — you might be tempted to try to estimate the connection speed or physical location of the visitor.

Then, if the connection speed is low, or if the user is located far from your origin server, it might be best to redirect them to the AMP page (since it is served from Google's CDN and uses HTTP/2 + heavy caching to serve content faster).

However, any CDN can be used for all pages to deliver them faster to everybody, not just slow connection users or people located far from your origin server; the point of AMP is only partially to deliver content via CDN and perhaps more about serving responsibly constructed pages to devices which are well known for their crappy JavaScript execution times, like mobile phones.

Ultimately, I wouldn't enforce a redirect for all mobile users. I would leave it to Google to direct visitors arriving via its search engine to be sent to the AMP pages. If AMP is going to catch on and be a long-lived product, browsers will implement it eventually.

Come to think of it, if you're serving content to mobile devices, it might be irresponsible to serve AMP pages to people using older Windows Phone or Blackberry devices whose browsers may not even properly support AMP.

There's a lot to think about but I hope I have provided an answer to your question, and if not, at least some considerations to bear in mind before deciding on the right answer for your product.

---

For more information about separate mobile sites, you can read this documentation on the subject provided by Google.

For examples of how to configure your web server to detect mobile user-agents and send them to a different subdomain, you can find articles or code samples quite easily if you search for them.

Eleanoraeleanore

Nice in depth answer. I would say that serving AMP version may not always be the best. AMP pages are intentionally limited by design and may not be as fully featured as non-AMP versions. To me AMP has a few benefits: 1) preferential treatment (either being called out separately or with extra UI like lightning bolts) and 2) instant loading as calling site (Google, Twitter... etc) can preload them. So outside of these sites (e.g. a visitor going directly or from another link) you lose those two benefits. The performance benefit is of course there too but non-AMP pages can be just as performant. – Forelli

Additionally amp pages do not need to be served from Google cache - and in fact may be an old stale version of it is. If you want to redirect could just as easily redirect to the version on your site that Google cache reads from anyway. – Forelli

Reading an article on The Guardian AMP this morning, they would help themselves and me if their outgoing links to other articles would link to the AMP pages rather than the full desktop pages. I don't read an article and then return to Google to find another article, I follow links on The Guardian's page that might look interesting. – Eleanoraeleanore

And that's where AMP (and its insistence on inlining CSS) fails for me as I wrote about here: tunetheweb.com/blog/inlining-css-is-not-for-me. AMP is designed for one page views. Benefits Google and Twitter more than site IMHO. – Forelli

Answer 2

Just for completitude, I used the following redirect to serve AMP pages to certain user agents, it's a .htaccess for an apache web server with mod_redirect enabled:

<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>

Bartolommeo

Answer 3

IMHO this question deserves more interest. amdouglas answer is great and fully covers the front-end aspects. As for Server-side, Jesús Diéguez Fernández is a good start but would require to be maintained overtime to remain accurate (user agent signatures).

To complete this (and even if it was not a PHP related question), here below is a PHP snippet I use server-side to redirect mobile-devices requests.

It uses Mobile-Detect (+23M downloads), which holds an incredibly complete and up-to-date list of user-agent strings (that should be easily adapted to any programming language).

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

Cosmism

How worth is that? AMP isn't supported for all mobiles devices. AMP site says "In general we support the latest two versions of major browsers like Chrome, Firefox, Edge, Safari, Opera and UC Browser. We support desktop, phone, tablet and the web view version of these respective browsers. Beyond that, the core AMP library and built-in elements should aim for very wide browser support and we accept fixes for all browsers with market share greater than 1 percent." What do you think about that? – Possessive

@LucasVazquez AMP is for front-end: a specific HTML version (often designed for mobile devices). Here we're talking from a back-end perspective: how to know which version to serve (AMP or non-AMP). – Declare