The Problem With AMP

Kyle Schreiber:

The largest complaint by far is that the URLs for AMP links differ from the canonical URLs for the same content, making sharing difficult. The current URLs are a mess. They all begin with some form of https://wwww.google.com/amp/ before showing a URL to the AMP version of the site. There is currently no way to find the canonical link to the page without guessing what the original URL is. This usually involves removing either a .amp or ?amp=1 from the URL to get to the actual page.

Make no mistake. AMP is about lock-in for Google. AMP is meant to keep publishers tied to Google. Clicking on an AMP link feels like you never even leave the search page, and links to AMP content are displayed prominently in Google’s news carousel. This is their response to similar formats from both Facebook and Apple, both of which are designed to keep users within their respective ecosystems. However, Google’s implementation of AMP is more broad and far reaching than the Apple and Facebook equivalents. Google’s implementation of AMP is on the open web and isn’t limited to just an app like Facebook or Apple.

Back in October I asked why websites are publishing AMP pages. The lock-in aspect makes no sense to me. Why would I want to cede control over my pages to Google? AMP pages do load fast, but if publishers want their web pages to load fast, they can just engineer them to load fast. Best answers I got were that it wasn’t really strategic — publishers are going with AMP just because their SEO people are telling them to, because Google features AMP pages in search results. I suppose that is a strategy, but ceding control over your content to Google isn’t a good one in the long term.

As Schreiber points out, with things like Facebook Instant Articles and Apple News, the canonical URL for each story remains on the publisher’s own website. With AMP, from the perspective of typical users, the canonical URL is on google.com.

Tuesday, 17 January 2017