With the most common AMP configuration, your most frequent visitors will get a worse experience than drive-by, random visitors. How can this be?
Default AMP setup
The most common, default, setup for AMP pages is to deploy them alongside your existing non-AMP site. You add a
<link rel="amphtml" ...> tag to your existing pages that points to the corresponding AMP page. And you add a
<link rel="canonical" ...> tag to your AMP pages that points back to the existing page. Now, any web crawler or service that cares about AMP will know that these two pages are related.
Third-party AMP routing
If such a third-party service needs to direct a visitor to your site, it may route users to your AMP pages OR your non-AMP page, based on the user’s context. So, this is great: visitors to your site that arrive via these services will get the mobile-optimized AMP page if appropriate, and the non-AMP page otherwise.
You might be familiar with this kind of routing behaviour from clicking on AMP links in Google search, or similarly following an AMP link from Twitter. These services figured out that you were on a mobile device, and showed you the AMP URL instead of the non-AMP URL.
So far, so good. But what about visitors to your site who don’t arrive via social media or search results. These visitors will include your most frequent visitors. Think about it: how do you get to your favorite sites? If you’re like me you just start to type the URL and hit go at the earliest moment when the browser autocompletes the URL. And then you head directly to your favorite site, with no search engine or social media service to route you to an AMP version.
So, while random visitors on mobile devices arriving via Google and Twitter will get the mobile-optimised AMP page, your most frequent visitors will get the non-AMP page.
But, it doesn’t have to be this way!
Self-service AMP routing with device detection
If you went to the trouble to build an AMP page, you should be able to serve it to your visitors when appropriate, without having to rely on third-parties to decide how to segment your traffic.
This is one of the things that device detection is very good at. A really simple use case is to determine the device type—mobile or not—and use this information as the basis for routing a visitor to the AMP or non-AMP page.
We wrote about this solution to AMP routing just over a year ago. One year on, it still feels odd that your most frequent and loyal visitors don’t benefit from your AMP investment in the same way that a random visitor does.