Google AMP, or rather, the Google AMP Cache, is rolling out to users right now. It’s been in use for Google News searches for a little while, but now general Google searches are becoming infected by it, and there’s no way to turn it off.
The intention of the AMP project is noble enough: Make mobile pages work faster. On the webmaster side of the project, some work needs to be done in order to make mobile versions of their pages AMP compliant. For many folk, this is little more than triggering a plugin for their CMS, but for those who code sites a little closer to the metal, there are specific AMP HTML pages to create and check. You know how HTML5 and the likes of Bootstrap helped unify devices, so they only need a single page regardless of screen type or viewport size? Well, it seems AMP reverses that.
I don’t pretend to understand it all. But I don’t need to in order to find faults with Google AMP Cache. What this does, is (as the name implies) cache AMP pages. It rolls them up and spits them out quickly to your phone when you access them.
The Google AMP Cache is a proxy-based content delivery network for delivering all valid AMP documents. It fetches AMP HTML pages, caches them, and improves page performance automatically. When using the Google AMP Cache, the document, all JS files and all images load from the same origin that is using HTTP 2.0 for maximum efficiency.
(That’s from here)
Which would be good, only it isn’t. When you use Google on your mobile device to search now, AMP pages are preferred in the results list so generally appear at the top – even if the content is “better” on a non-AMP page. When you tap the link, you get Google’s cache of the page, and herein lie most of the issues.
It’s cached, so inherently isn’t necessarily the newest content. You also don’t get the correct link from the page – the URL bar shows a Google URL. For example, instead of:
If you then decide to pass this link on to someone not on a mobile device, then you end up passing on the AMP’d link instead, only it doesn’t work. Just copy and paste that second link into your desktop web browser URL bar and see. Not only do you not get taken to the page, you get sent to a page of search results for which the top match isn’t even the correct site 1:
It’s even worse than that. Without hacking apart the AMP Cache URL, you can’t even find a link to the correct “real” page to pass on or save. The cached pages also tend to strip out certain content, such as adverts or input forms. This may be a bonus, or may be because of the ineptitude of the webmaster, but it doesn’t matter either way: Content is not served up correctly and that is a problem.
But things are worse still. Because the Google AMP Cache is, by their own definition, “a proxy-based content delivery network” it can be used to bypass web filters and restrictions. Page blocked by your school? Just access the AMP Cache version of it on your mobile device. In fact, you’ll bypass the filter automatically and inadvertently, potentially breaching an acceptable use policy.
The worst bit of all? You can’t turn it off. There’s no switch in your browser or your Google account settings. You can block access to google.com/amp (or .co.uk/amp, or other country specific variations), but that stops search from working properly. You can ask webmasters to disable AMP support, but there are so many using it now that isn’t going to happen. I do wonder if many webmasters were hoodwinked into this: They saw the benefits of AMP, so embraced it, and now Google have screwed them over by forcing the cache and breaking their content. How does advert revenue work now for those people, if the adverts are cached? Clickthroughs and hits? Did webmasters realise this was the endgame, because when I looked into AMP a while back for WordPress I certainly didn’t. Is there a legal issue with Google AMP Cache essentially cloning your content and serving it up from their server? It’s a mess.
And what if you do manage to convince a webmaster to turn it off? What happens then? This: 404s everywhere. That’s Google’s answer.
The situation now is that mobile search, via Google, is effectively broken just so we can get a page on the screen a few milliseconds faster. This is not progress.
- Note that it’s Google who redirected to this search – I didn’t stupidly just put the URL in the search box! ↩