On August 31st 2016, Google announced the removal of “mobile-friendly” tags from search results.
Since then, they have been pushing AMP aggressively.
The primary focus of the project is to resolve a significant issue for the current online ecosystem: mobile loading speed.
In the beginning, there were a lot of bugs and features that didn’t work and had to be solved by the developers.
Still, it caught on, especially on well-known publishing sites. Online publications like New York Times, The Guardian, BBC, CNN are among the AMP pioneers.
At first, it was showing up only on news queries, at the top of the search results in a carousel. You could easily swap among articles using your phone.
Here is a flow example for the user navigating through Accelerated Mobile Pages:
There are a lot of different opinions about implementation, impact on SEO, monitoring the traffic and so on. We have been getting with a lot of questions lately regarding Accelerated Mobile Pages.
So we decided to write about some of the most relevant issues we encountered and how we solved them.
Also, hang on tight for some juicy Google Analytics insights!
How do we implement Accelerated Mobile Pages?
There are three handy tools to help with the debugging of AMP elements:
- the test tool from the official website: https://validator.ampproject.org/ (also with an add-on for Google Chrome)
- the test tool from Google: https://search.google.com/search-console/amp
- the Google Chrome Developer Tools Console: you have to add “#development=1” at the end of the URL to get details about errors.
Keep in mind that all the elements must use the AMP format. Otherwise, your page will not pass validation. Be very careful with pop-ups, notifications like the European cookie law and so on.
AMP errors and how to avoid them
Some common mistakes we encountered:
- using inline CSS -> you are not allowed to use inline CSS when building Accelerated Mobile Pages; all the custom CSS must be in the
<head>section using the
- using custom HTML elements such as
<img>-> you have use the AMP
Most pages were removed from Google’s index which resulted in a substantial traffic loss. After fixing the errors, the organic came back up.
Furthermore, you should be careful how you deliver the static resources like images, JS/CSS files, videos, etc.
If you have an SSL certificate installed, provide the resources from the HTTPS:// version; if not provide them using HTTP://.
Here is an example of incorrect delivery of static files. The SSL certificate was not installed, and the static resources were delivered via HTTPS://, which resulted in 404 errors.
If you get loading errors such as the above Google will remove AMPs from search results, and you will end up losing traffic.
Nobody likes that!
You can keep track of your index status in Webmaster Tools: there is a special section dedicated to Accelerated Mobile Pages.
Above is an example of AMP de-indexing because of resource delivery through HTTPS://. After fixing the errors, it took Google around 24 – 48 hours to rebuild the cache for all the pages.
After the re-cache, Google started to re-include the URLs in the index.
The Google Analytics timeline for the AMP organic traffic:
As you can see, Google is very quick to react to AMP changes. You can use the dedicated section in Webmaster Tools to track the errors and the evolution of Accelerated Mobile Pages.
Also, you should get messages in Webmaster Tools if anything goes wrong.
[IMPORTANT] Please keep in mind that the HTTPS:// errors were not mentioned in any Search Console message or e-mail. We spotted the issue by checking it on our own.
We recommend a weekly checkup for Google Analytics and Google Webmaster Tools. This way you will be able to spot such issues as they happen.
A few minutes a day/week can save you from a lot of headaches.
What about structured data for AMPs?
Does it matter? It’s vital!
If the structured data is not implemented correctly, your AMPs will not be tagged by Google, and they will not appear in the carousel.
So what can we do?
Start by reading the documentation for AMP structured data. There are few types of pages that support AMP structured data.
For each type, you can find a documentation of the supported data structured elements. Of course, you can test the implementation with Google’s tool.
Do not be discouraged by the few types of pages. As mentioned, the AMP project is under development. In time, there will be new kinds of Schema.org pages available.
Anything tricky with structured data?
We got the following message in Webmaster Tools. It mentioned that we needed to add required structured data elements.
We checked the URL that was mentioned and got no errors in Google’s tool. Also, the documentation does not say what elements are mandatory.
So what now? We started testing with different implementations for structured data elements.
Keep in mind that you must always mention the publisher, especially for video and article pages. We learned this lesson the hard way.
Deprecated tags and attributes for video
Remember how we mentioned that the AMP project is in constant development?
We got the following message by e-mail: Use of deprecated tags or attributes (Non-critical issue). Below you can find several examples:
We found that the implementation of
<amp-video> tags was incomplete.
We ommitted the following:
- the fallback: “your browser doesn’t support HTML5 video”
<source type="video/mp4" src="/video/file.mp4">
Here is the complete implementation for video with two examples.
How can we track the AMP traffic?
As you know, Google delivers Accelerated Mobile Pages from their own domain.
So, the first question the pops into mind is: will the traffic show up in Google Analytics?
The answer is: YES. In fact, Google Analytics for AMP can be set up quickly. Here you can find out how.
Here is an excellent example of implementing with triggers. You see the triggers being fired in the bottom-right of the screen.
Also, you don’t need to create new goals for AMP. Use the ones you have already set up in Analytics, just filter the traffic for the AMP content.
The Accelerated Mobile Pages URLs can be designed adding suffixes or prefixes to the original URL like “amp”, “amp-view”, “ampview”, etc.
To see how much traffic you have for AMPs you can create a Landing Page filter in Google Analytics.
It’s that simple!
But, to make it easier, we recommend creating a new view in Google Analytics. You have to add a filter on top of it for the AMP traffic.
Looking at Search Analytics in Google Search Console
There is a special section for AMP search results in Google Search Console under “Search Traffic” -> “Search Analytics”.
You can evaluate the AMP traffic the same way you do for regular traffic. We recommend looking at it by content group: separating the different types of pages.
Let’s say you implemented the AMP for category pages and product pages. You should check the results for each page type.
There is also a filter under “Search Appearance” with URLs that show up as rich results in Google Search.
Another question we get a lot is regarding Accelerated Mobile Pages in Google Adwords: Will the mobile traffic from Google Adwords move to the Accelerated Mobile Pages?
The mobile traffic from an Adwords campaign will not go to AMP unless you explicitly set the landing pages.
If you do, keep in mind that the regular conversion tracking code will not work, you will have to use specific AMP tags. More info on this at this link.
In fact, the majority of the AMP traffic should come from Google organic (at least 90%), because AMP was built for Google organic.
If you do not have this percentage, you could be doing something wrong.
After you set up Google Analytics for AMP, start checking for issues. Because you might find something like this:
This is the evolution of the direct traffic after AMP implementation.
Let’s have a closer look!
The site is using AMP URLs for mobile users that reach the non-AMP site. When you click on an AMP URL Google Analytics will create a new session and tag it as direct traffic.
It is best to follow the documentation on AMP discovery and nothing more.
Google’s recommedation is to:
- add the following to the non-AMP page:
<link rel="amphtml" href="https://www.example.com/url/to/amp/document.html">
- add the following to the AMP page:
<link rel="canonical" href="https://www.example.com/url/to/full/document.html">
A similar situation happens when a user clicks on a non-AMP link from the AMP page. Analytics tags as Referral traffic the session coming from AMP.
The metrics of Accelerated Mobile Pages
Of course, after the implementation, we want to see some statistics! The easiest to check are the basic ones like session count, bounce rate, pages/session, session duration, etc.
No surprises here, you can analyze everything like regular traffic. You can also extend your search to new sessions/users.
Bounce Rate and Session Duration stand out
The first interesting aspect you might notice is the higher than typical bounce rates. Let’s examine a bit on what the reasons might be.
You can exit the page in at least three easy ways:
- the “X” from the AMP interface;
- slide to another website (if the traffic comes from the news carousel);
- back from the mobile browser (when you star scrolling up, the browser menu appears)
Our belief is that Google will remove the bar at the top in the future, or at least improve it.
Let’s hope for fewer bouncers!
At least we get a link sharing option
In the screenshot above, we mentioned the share button.
Not too long ago, if you wanted to share an URL from an AMP, you would share Google’s cached URL, not the site’s actual URL. Now you can share the site’s URL.
Still, the bounce rate might seem a bit unfair.
So what can we do?
First, we can implement “Adjusted bounce rate” to see numbers closer to reality (regarding bounce rate and session durations).
Google says that if one of the followings applies, a visit is not considered a bounce:
- the user must click on an internal link which goes to the same domain, not a subdomain (in other words, go to another page)
- the user must stay on that page for 30 minutes; these effects are very noticeable publishing sites (e.g.: a user reads for 5 minutes, gets the information then back to Google search)
Not fair, right?
This is when the adjusted bounce rate comes in. We can send a custom event to check if the user is still on the page 15 – 30 seconds after the page is loaded.
How to implement:
- with Google Tag Manager: here is a great article on how to do it
- with the AMP Analytics code, using a timer like in this example:
If you’re interested in learning more about exit behavior, we recommend having a quick look at our bounce rate vs exit rate article.
What do we get for all this work? Is it worth the hassle?
Let’s take a look!
In the begging of the article, we promised that the speed would drastically increase on mobile. So we compared: the loading time of the AMP vs. mobile traffic using Google Analytics.
Here’s how you can compare loading times: in GA go to “Behavior” -> “Site Speed” -> “Page Timings”. On this report you can apply the following filters:
- select “Medium” as a “Primary Dimension” (by clicking “Other”).
- select “Device” as a “Secondary Dimension”
- after that, we can create an “Advanced Filter”
- for “Medium” we type “organic”.
- for “Device” we type “Mobile”.
- by landing page. How are the AMP URLs built? With prefixes or suffixes like: amp, amp-, amp-view?
- select “Landing Page” as “Primary Dimension” (we do it by clicking “Other”)
- by creating an “Advanced filter”: enter the suffix or the prefix to select the landing pages
- by landing page. How are the AMP URLs built? With prefixes or suffixes like: amp, amp-, amp-view?
Speed in real-life
Speed Case 1: these are the results for a video page.:
At the time, there were no ads on AMP. Now you have a lot of options to choose from -> here is the complete list.
Speed Case 2: this is the result for a small site. We included this example to show that AMP is not useful only for large-scale websites.
What’s the impact on SEO?
SEO Case 1: this the impact on organic traffic for a small WordPress site:
It slowly increased over time, and the only downfall happened during the Christmas period.
SEO Case 2: here is the traffic evolution for a large video-based website (AMP for the video objects).
There are some downfalls, some of them were explained earlier in the article.
SEO Case 3: last but not least, canonicalized.com. Something interesting is happening here. As you can see below the implementation of the AMP did not have a huge impact:
The big question is: WHY?
We can find the answer in the audience specifics.
By looking at the device categories and demographics reports, we found that our readers are doers like developers, site owners, individuals working to grow eCommerce businesses. People who are actively using the site for practical help.
As you can see, most of you are using desktop devices to access the website, so the AMPs are not very popular.
The AMP project is constant development. It will take some time until we can get our hands on a very stable version.
Constant changes happen regularly. The correct implementation will be different almost every time.
Don’t be surprised if AMP fades away! It might happen.
It’s important to ride the wave while it lasts. Even if tomorrow there will be no AMP, we are positive you will earn a good experience by looking at things differently.
But if it doesn’t go away, the upside can be huge!
For the moment keep an eye on the main factors using the reports on errors, index status, and traffic evolution.
And always have a developer ready to do changes fast. If you act on them on the spot, you will not lose traffic.
The main author of the Canonicalized content.
I am highly passionate about data analysis, visualization and whatever helps people reach informed answers faster.
I love what I do, and I am working to improve speed in every aspect of my life.
I find comfort in helping people so if you have a question give me a shout!