Google AMP Explained

First, and then you can teach us all about AMPs.

Yes, I will do that. Let's share my screen. Can everybody see my screen?

Yep, yep, I can see your screen.

Excellent. So yes, Google AMP, Accelerated Mobile Pages. Let's talk about that for a bit. Well, let's introduce myself a little bit first for those who don't actually know me. I'm surprised people still out there who haven't heard of my profane rants and Twitter arguments, but there you go. I've been doing SEO in one way, shape, or form since about 1998, which means I've lost quite a bit of my sanity along the way. And as a result, I have very limited social filter. So there might be some swearing at some stage. I apologize in advance. I started my own business 2 and a half years ago doing pure SEO as Polemic Digital. And I'm also one of the co-chiefs of State of Digital. And I do get around on the conference circuit. For some reason, they keep asking me back despite my profanity, so I must be doing something right. But that's enough about me. Let's talk about AMP, Accelerated Mobile Pages. I think you'll have to be hiding under a rock for the last year or so to not know that AMP is on the scene. But what I do realize is that a lot of people don't really understand what Google is trying to accomplish with AMP. And what it actually is and how it impacts on what you should be doing for your mobile websites. So let's talk a little bit about what AMP actually is and how it all works together. An Accelerated Mobile Page is basically an alternative version of your static web pages, of your content pages, that is built specifically for speed and mobile viewing. It is a mobile-only standard, so it is primarily and exclusively aimed at mobile devices, smartphones specifically. It is its own standard. While it does use standard HTML5 markup, it is actually a new standard developed primarily by Google. It is an open source project in all but name, but it's primarily Google which is the driving force behind Accelerated Mobile Pages. And it is quite a restrictive standard. It's pretty much an all-or-nothing standard. Either you have valid AMP content or it's not valid. And if it's not valid, you don't get included in all the various ways which AMP is being shown in search results. We'll talk a little bit more about how AMP is currently being shown in search results and what the future plans are. This makes it very different from the web because Google as a search engine has historically had to work around different standards on the web and had to try its best to interpret web pages and how it's been marked up and how they've been coded. To try and get them indexed and included in its index. And that's a bit of a hassle, and Google has historically always struggled with it, which is why technical SEO has been so important over the years to make sure that Google can actually properly crawl and index your web pages. With AMP, it sort of turns things on its head. Rather than Google making all the effort to try and understand what your web pages are saying, you have to now put the effort in yourself. To make sure you create AMP-valid versions of your content so that Google can include it in its AMP carousels and other search features. If your content, if your pages aren't perfectly valid, you simply don't get included. It's as simple as that. It puts the onus squarely on you rather than on Google. You either have valid AMP pages and you get included in all the juicy carrots that Google is dangling in front of you, Or you don't have valid AMP pages and you get none of that. You'll have to stick with standard mobile traffic. Now, why is Google actually putting so much effort behind AMP? This is something that I think a lot of people misunderstand and where a lot of the confusion about AMP stems from. When we look at apps on mobile devices versus mobile web pages on mobile devices, we see that while mobile web pages on average get a lot more monthly unique visitors, apps tend to dominate the time that people actually spend on their smartphones. And you know this as well as I do, when you look at your own smartphone usage, you know, you spend a lot more time in the Twitter app or the Facebook app or maybe a specific news app that you might have versus on the mobile web browser. You might use the web browser on occasion to look stuff up, maybe look up on Wikipedia or find a local business, but then you immediately switch back to an app to maybe share the link or do whatever else with it. So people spend a lot more time in apps than they do in mobile web pages. And this is quite a significant existential risk for a company like Google, which has built its search platform on the web, not necessarily on apps. And that is where Accelerated Mobile Pages come in. As we see here in this graph, engagement is the strongest in apps and discovery is where you use mobile web pages. And Google is fully intending to use AMP, Accelerated Mobile pages to bring the mobile web experience up to par with native app experiences in terms of speed and ease of use, so that you don't have to go to a specific app to discover your news or read content or do whatever. You can just stay in your mobile browser with the knowledge that any content you want to see will load nearly instantaneously, and you'll have a very smooth and seamless experience. Even with fully optimized mobile web pages, they don't actually come close to the experience that AMP can offer. AMP has something very different, and we'll talk about that in a minute later, which Google is utilizing to full effect to make sure that the AMP experience in a mobile browser is almost on a par with that of the experience you get in most native apps. So let's look at how an accelerated mobile page is actually composed. I'll take an example from The Guardian because I think they are really stretching the boundaries of AMP in terms of what you can do within the constraints of the standard. The Guardian's AMP pages look nearly identical to their mobile optimized pages. So they're doing really, really well with their design and their layout. This is a standard AMP page, as you can see. I've just taken an article from The Guardian and looked at the source code of the specific AMP version of it. It all starts with the declaration of AMP in the HTML declaration at the top. You can just write HTML AMP or you can use the AMP lightning icon that you will see in a lot of AMP example files as well. This basically tells Google that, right, I need to verify this page as an AMP page versus a standard HTML page. What we also see is that structured data, and specifically JSON-LD data, is fully integrated in AMP. Your AMP page will not validate unless you have valid JSON-LD markup in there to tell the search engine exactly what kind of content it's looking at. This, of course, makes it much easier for Google and other search engines to index the AMP content and know exactly what it is, what the publisher is, what kind of usage might be associated with that specific piece of content. So structured data is integral to the AMP experience. We also see that any markup, any formatting that you do on an AMP page has to be with inline CSS. Historically, web pages tend to use external style sheets, style files for their markup. Not so with AMP. With AMP, it all has to be inline because AMP wants as little external dependencies as possible. So all your CSS markup is inline right there in the source code to look at and to use for the formatting of your specific web page. Of course, we want some functionality beyond just static HTML on web pages. But there again, AMP is quite restrictive and only allows you to use specific pre-approved JavaScript libraries. For example, if you want to use custom fonts or you want to have social sharing functionality or want to embed YouTube videos or want to show advertising, you will have to fall back on AMP's own approved JavaScript files. And use their functionality. If you want to do something that is currently not part of that functionality, you can pretty much kiss it goodbye. It's not going to happen. Having said that, AMP is a very fast-moving standard that is constantly being developed and improved and expanded. So if you want certain features and functionality in your AMP pages that doesn't yet exist, do keep an eye on the roadmap for AMP because it's likely it will be implemented at some later stage. We'll talk about the roadmap towards the end of the talk. Of course, web analytics is very important. And again, AMP does allow you to do this. It integrates with all kinds of web analytics platforms like Google Analytics, but also Comscore and Beacon and Omniture and other platforms. It does require some custom coding. So it's not just standard Google Analytics coding. But again, AMP will actually allow you to properly track all your web pages in Google Analytics. So the key features of AMP are indeed that it uses standard HTML5 and will render in most modern browsers. There's very few browsers who don't actually support AMP pages at the moment. It has limited external dependencies, so you can't do everything with it. You have to depend on Google's AMP JavaScript libraries and inline CSS. And structured data is fully integral to AMP pages. Without structured data, the pages simply won't work. Now, the key feature of AMP, which is what is really the driving force behind its speed, is the Google AMP Cache. I think this is where a lot of the confusion also stems from. It's not just about making very fast-loading pages in Google AMP, it's also about those pages being served from Google's own AMP cache whenever you want to look at an AMP page. Google will take your AMP pages and when they're properly valid, they will host them on their own servers spread out throughout the web. And whenever someone goes to a mobile search result where your page is being shown, that page will be served from Google's own server network. So not from your own web server. Your website will still get the credit, of course, with the Google Analytics code, but the user actually never touches your web server. It is all served from Google's own infrastructure. The AMP cache is its own product as such for Google, and you can actually talk to it through an API. So it's not just restricted to Google's own search results. You can talk to Google's AMP cache directly through their API. And load pages from there for your own purposes. So it's not just Google that can make use of this. So how does it actually work in a day-to-day environment? Now, what happens is that Google will crawl your AMP content and will load them in the AMP cache, as we see here. Then when someone does a search on a mobile device and your AMP content is triggered, what actually happens is that in the search results pages, Google will actually prerender your AMP content from the AMP cache. So the pages, your AMP pages, will already be loaded in that mobile browser before the person is actually even looking at your content. And Google will only, of course, prerender it if it trusts that you are serving completely valid AMP pages. And it can only do that if it has validated your AMP pages and has loaded them in its own cache. And that's why the cache is such an integral part of Google AMP. If Google doesn't trust your AMP pages, it won't pre-render them from your own website, of course. It'll just pre-render it from its own cache. I think Danny Sullivan wrote an article the other day about why Google won't just use publisher URLs but insists on using its own AMP cache URLs for AMP. Well, this is exactly why. Google doesn't necessarily trust you to serve AMP pages or that you are Have it made a change to your AMP content since the last time it checked it? It will preload your pages in its AMP cache and will prerender them from its own browser to enable that very fast, seamless mobile browsing experience. This is absolutely fundamental to how AMP works and how Google has implemented it. So the question of why Google won't use publisher URLs is a bit of a moot point and I think shows the confusion about what AMP actually is. And how Google is using it. The AMP cache is absolutely fundamental to the whole AMP experience. And Google will not prerender pages unless they are served from the AMP cache because it can't trust those pages unless they've been validated and loaded in the AMP cache. As a side benefit of this whole process, how Google serves AMP pages, this tends to defeat most ad blockers as well, which is very interesting for news publishers, of course, who have struggled with ad blocking. In recent years. You can still block ads on the network level, but on a browser level, because the content is served from Google's own AMP cache, you can't block AMP pages unless you block ads on AMP pages, unless you block the entire AMP cache. So this tends to work in the advantage of publishers that struggle with ad blocking and see their ad revenue decline and could be a way for them to reclaim some of that revenue. So how does AMP actually look in search results? Well, of course, we all now know that when you do a search on a mobile browser and there's newsworthy content, the AMP carousel, we see it on the left-hand side, will be the first thing that pops up. These are just the stories that are triggered by Google News and that have an AMP version that Google will then show in a carousel. Now, like I said, these will all be pre-rendered and preloaded in your mobile browser so that when you tap on one, you can swipe between them very quickly and basically have a seamless news viewing experience, the same as you would get in most native apps, but then directly in your mobile browser. Now, Google is also rolling AMP out for specific rich cards. The example shown there is about specific movies and movie content powered by AMP. News and weather is also powered by AMP. Specific AMP cards you will see there. And what we see more and more often is AMP pages being shown as part of the normal set of blue links in Google search results. And this is a very interesting development, I feel, because once users start to understand that an AMP page has speed advantages over a standard mobile page, you could see a potential shift in user behavior that users start to prefer AMP pages over regular mobile pages. And that implicit user behavior signal will also have effect on the rankings where AMP pages, because they are more engaging and see more clicks from users, might start to outrank non-AMP pages. So that's definitely something worth keeping an eye on and seeing how that develops. At the moment, most users won't necessarily recognize the AMP icon, but Google is working on changing that. I'll skip a slide to very quickly show you that. Here we see how Google is actually educating users on what AMP actually is and what the advantages of it are. Because it realizes that for AMP to become a success, it will need to get a certain critical mass of adoption. And it's not going to get that unless all websites see the value of AMP. And websites won't see the value of AMP unless there is a very clear advantage to them implementing it versus not implementing it. And that all starts with users themselves preferring AMP pages over non-AMP pages. So this education piece is very important and will be critical to the success of AMP, whether or not it's going to really take hold in the next few months or years. For publishers, AMP is incredibly powerful. There's a set of reports from Search Analytics from one of my publisher clients which shows the performance on mobile devices for pages that are AMP versus pages that are not AMP. And as we can see, the AMP pages have generated 10 million clicks from 170 million impressions versus the non-AMP pages have generated just under 5 million clicks from 86 million, nearly 87 million impressions. So what we see here is that AMP outperforms non-AMP in the mobile browsing environment for this particular news publisher by more than 100%. Now, your mileage may vary. News is a very specific niche, and Google has gone very heavy with the AMP carousel for news stories. So for now, AMP works best in the environment of online news, but we are seeing that slow shift towards normal blog content or static content in Google's mobile search results now also having that AMP icon. And like I said, Google educating its users on what AMP actually is, hoping to trigger that sort of a user feedback loop where users start to prefer AMP pages, encouraging more and more websites to adopt AMP themselves, and thus creating that spiraling effect that AMP will really take off as a standard. Whether or not that will actually happen, that remains to be seen. I think 2017 is going to be a very important year for AMP, whether or not they're going to get that critical mass, going to get that momentum amongst websites and web developers and SEOs as well to really make it worthwhile implementing, or whether it will remain a niche thing for news publishers, in which case it might die out in the next 2 or 3 years as we've seen with other aspects of Google products. Google has hinted that it wants to give expanded exposure to AMP pages. Now, they wrote a blog post about that back in September. That hasn't actually materialized now, and we're already in the middle of December. So I don't expect any major changes to happen until at least 2017. I think Google might have been a little bit optimistic about AMP capabilities, especially around things like e-commerce. But so far, the adoption rate hasn't been strong enough. And to be honest, the AMP standard itself hasn't evolved enough to make that a perfectly viable road for implementing on e-commerce websites and other types of content websites, rather than just purely news websites. So it's not going as fast as Google wants it to, but still worth keeping an eye on to see what is actually going to happen in the next couple of months to see whether or not you need to jump on that bandwagon, whether it's something you can safely ignore for the time being. How to implement AMP is becoming more and more easy as well. If you have a WordPress website, it's a matter of installing one or two plugins. The PageFork plugin combined with the semi-official AMP plugin tends to be enough. On my own website, that's pretty much a very smooth implementation and took almost no time at all. There are plugins in the works for other websites as well. I think there's now one or two plugins for Magento websites. Again, purely for static content at the moment. And some other content management systems are working on plugins as well. So that makes it fairly straightforward and fairly easy to implement AMP for WordPress. Other websites might just have to do it manually or the hard way, in which case you will have to make that evaluation if it's worth doing or not worth investing that developer time on. There's a great resource called AMP by Example, which basically has all kinds of different templates that you could just copy and then put your own content in to create very basic, straightforward AMP pages. A lot of different AMP scenarios will be explained there as well, like different forms or live updated feeds or how you embed videos in AMP and social sharing. So it really takes away a lot of the guessing game and will save your web developers a lot of time of having to look stuff up on Stack Overflow. And instead, they can just copy and paste these AMP templates and customize them for your specific website. The Search Console reports are also very useful because Google will tell you exactly how many of the AMP pages it has actually indexed. And which of those it has issues with or not. Now, this is one of my publisher clients. It has a lot of indexed AMP pages. You can also see exactly when the AMP plugin that was used by this website was updated and promptly broke AMP. And then when we very quickly rolled back that plugin to the previous version to fix AMP again. It's worth keeping an eye on this because if your pages aren't valid, if there's an issue with it, Google simply will not index it and will not show it in its AMP carousels. Like I said before, it's an all-or-nothing standard. Either your content is fully valid or it's not valid. And if it's not valid, it simply will not be shown and you miss out on that prime screen real estate that Google is currently giving to the AMP carousel. So if you are working with AMP and have implemented it, do keep a sharp eye on this Google Search Console report and revisit it regularly because an update to WordPress or an update to the plugin could very easily break your AMP pages. Or maybe even you adding a new social sharing plugin or a new form plugin or whatever it is could also mess up your AMP and make your pages invalid all of a sudden. There's also an AMP Validator where you can just throw web pages into and look whether or not they are valid AMP or copy and paste HTML code directly in to see if it validates as proper AMP. Very useful to make sure you can test your AMP pages before you actually roll them out. There's also a Chrome plugin which is very handy. You can just install that in your browser and whenever you visit a web page that has an AMP version, it'll light up blue with a little link icon. You click on that and you'll visit the AMP version of that page. And then if there's any issue with validation of that AMP page, Google will— or the AMP Validator plugin will show you exactly what the error is itself. I thought this was quite ironic. This is an article on Search Engine Land that talks about AMP, but the AMP version of that article itself is not valid. I like a little bit of irony. Also, Chrome has really good developer tools. And if you open an AMP page in Chrome developer tools and open the console, you will see whether or not it is valid AMP. That is built into Chrome browser now. So you don't necessarily have to use a plugin. Plugins make it a bit easier to validate and troubleshoot AMP pages. But you can just use the Chrome browser itself with the developer tools to see whether or not you're serving valid AMP content. So what currently works in AMP? Quite a lot actually. Most web analytics would work in AMP. Advertising works in AMP. Videos work in AMP. You can use GIF animations, WebP animations in AMP. Carousels, although outside of Google News carousels on search results, you don't really want a carousel on your own website because people tend not to use them very much. Most social sharing plugins will work in AMP with some restrictions. Basic form fields, like you can have lead generation forms, they work in AMP. You can even have paywalls in AMP now. You can have iframes, sidebar navigation links, browser notifications, etc., etc. There's a lot of stuff that now works in AMP. A lot of stuff that doesn't quite work yet. The list of stuff that does work is shorter than the list of stuff that doesn't work. So that's why I said keep an eye on the roadmap. This is a screenshot of the latest version of the roadmap. Hasn't been updated for Q1 of next year yet. But there's a lot of stuff that is still in the works and in the pipeline. End-to-end e-commerce doesn't work yet, although that too is definitely on Google's radar for implementation. Most JavaScript-based interactivity that you might want to implement on your website simply will not work yet. It is still a fairly static standard, doesn't have a lot of flexibility. But like I said, a lot of development effort behind this. So it is a constantly evolving standard and worth keeping an eye on to see what's new and what's happening. Also very interesting that Google is working on making AMP work with progressive web apps, which would make for very interesting applications indeed where you can have lightning-fast web apps serving AMP HTML and with interactivity functionality that you tend to only see in native applications at the moment. This is again something Google is wanting to emphasize because it wants to mitigate the risk it currently has from native apps. It wants to keep its users using mobile websites and using mobile search rather than going into native apps, which is where progressive web apps become very, very powerful opportunities for Google to make sure that it doesn't lose audience to native apps but can keep them using mobile web browsers. So to wrap up, there's a lot of extra reading if you want to learn more about AMP. The ampproject.org website is probably your best starting point. From there on, you can follow the AMP HTML official Twitter account. The AMP by Example website, like I said, has great examples to copy and paste. If you want to know more about the AMP cache, Google has its own section on that on its developers website. All the Updates to AMP are themselves posted in GitHub, so you can just subscribe to that and keep an eye on that. There's a Google Group for discussion about AMP, and Stack Overflow also has its own session, its own tag for any AMP-related questions in case you can't find it out yourself. So that's it from me. I hope you found that useful and somewhat enlightening. I want to open the field to questions now.

All right, Barry Adams, Bad Adams. Barry, thanks so much for the very much in-depth AMP overview over there. I think that helps a lot because AMP is not something that can be grasped super easily. It's very useful that you put this together for us. So one question for you, this is a short one since we're running a little bit behind, is actually this one. So who's behind AMP? I mean, other than Google, is there anybody else who's behind AMP?

Well, you can look at yourself in the GitHub repository who is making commits to the AMP repository there. But generally speaking, it is a Google project. It's nominally open source. Google really is the driving force behind it. And there's not any company that I know of which has officially endorsed AMP as a standard. There's other companies who are playing around with it, like eBay, currently working in partnership with Google to try and get AMP working in the context of e-commerce. But Google really is the primary driving force behind AMP at the moment.

Okay. Yeah, I mean, I guess that's kind of what we thought, but just wanted to make sure that's the case. So, all right, well, Barry, I want to wish you a Merry Christmas and keep rocking the Santa hat. That's awesome. So we'll stay in touch.

Absolutely. Thanks for having me, Sergej, and good luck with the rest of the event.

Excellent. Thanks, Barry.