Did you also notice that your accelerated mobile pages (AMP) point to Google cache and not to your site? This is an issue that more and more small publishers become aware of these days as the AMP project grows steadily. So, what is happening?
Understand AMP
It comes as a surprise for most small-scale publishers, what happens when enabling AMP…
As many others, you might have thought that AMP simply does something to your site, like creating a lightweight and fast version of posts that is then served on mobile devices.
This can, however, not be more wrong.
What happens in fact is that an AMP version of posts is indeed created and you can view your accelerated mobile pages by typing /amp/ after your posts’ URL. Google caches then the AMP version of your posts and makes it available to users via their worldwide CDN.
If you typed a search query that should return a URL from your site, you will see that both the “normal” and the AMP result look just as usual, featuring your site’s name and URL.
Try clicking on the link. Here’s where something odd happens. Somehow you end up on Google’s domain with a URL looking something like https://google.com/cache/amp/yoursite/yourpost/amp or https://cache.google.com/yoursite/yourpost/amp/.
AMP is a cache project in its essence. It caches AMP content and serves the cached pages to users worldwide from Google’s cache bypassing your server and original content. That’s the reason why accelerated mobile pages point to Google cache and not to your domain when loaded.
How Does That Affect Me?
In many ways.
Firstly, the AMP Plugin is far from optimized and for you this means that:
- You have to double-check your structured data and whether it works with the plugin. You can check your structured data with Google’s testing tool here.
- You have to check whether the AMP output includes essential features as links to your original site, logo, menus, comments, etc. If not, try installing an optimizing plugin as Custom AMP. It’s pretty easy to use and gives you the opportunity to add logo, menu, and analytics out of the box and include custom CSS and HTML code, depending on your abilities.
- You have to check for plugin incompatibility. Even though there’s a collaboration between the AMP project and WordPress, there’re still issues with compatibility.
- You have to check whether ads are displayed and function properly. If not, this might have serious implications for your ads revenue.
- You have to be prepared to lose some of your page’s functionality. Make though sure that essential features work as they should.
Secondly, you have to keep an eye on analytics data. It’s not only a question of whether analytics is installed properly on AMP but also a question of how click-through to Google cache instead of your site is interpreted both by your analytics software and Google itself.
Even though the team behind the AMP Project states that no stealing of traffic occurs, as Alex Kras fears, and you can avoid a lot of the shortcomings of the AMP plugin by installing an additional plugin, there’re still a lot of questions unanswered regarding SEO.
As SEO expert Dan Petrovic points out, there’s still not enough clarity regarding the SEO implications of loading your content from Google cache instead of your server. While he explains that it’s only the HTML part of your pages that gets cached, meaning that everything else loads from your server, he doesn’t exclude the possibility that traffic stats of your site do get affected by this.
Alex Kras reached the same conclusion after his lunch with the AMP team: some mobile traffic may get lost in the process.
While all of this isn’t a top priority for the major publishers as their SEO is through the roof already and a slight drop in traffic stats wouldn’t affect their revenue or SEO standing, for small publishers, bloggers, and newcomers this might have some serious SEO implications.
Additionally, AMP works by creating a lightweight version of your content resulting in duplicate content. Even though this issue seems to have been fixed by canonicalization of your original URL, it still presents a whole set of issues.
You end up with two separate pages that might end up competing in search, which I already have witnessed with the AMP URL appearing just above the identical non-AMP URL. Whether this is a bug I don’t know but the fact that the non-canonical AMP URL appears above the canonical one seems problematic.
Matt Cutts announced otherwise back in 2006 that canonical URLs are the ones favored by Google as they are treated as destination URLs. He mentioned that it’s still a work in progress but halfway done. Now, 11 years later one would believe that there isn’t a doubt about which URL should appear in search – and yet.
The duplicated content issue is also relevant in terms of pure SEO. One of the important SEO factors is page traffic as part of site traffic. No matter how Google shows your URLs in search, the fact that a portion of internet users will click on one page and another – on another one with identic content means simply that the CTR of your pages will drop.
Not to mention, analyzing web traffic becomes quite intricate as you’ll have to follow up on traffic to two different pages for each one of your original pages in order to gather trustworthy data.
Last but not least, even with an optimized AMP template, a not fully established publisher risks their branding efforts every time an accelerated mobile page points to Google cache’s URL instead of your domain.
I assume that this wouldn’t be an issue once internet users get used to the fact that AMP points always to Google cache but for the initial stage of the project, some confusion is inevitable.
Implications
First of all, it’s important to understand that AMP isn’t a ranking factor according to Malte, the tech lead of the AMP project for Google. That is, your non-amp content should appear in search at the same spot as it would if AMP didn’t exist. AMP provides simply an opportunity for additional visibility via features as Top Stories Carrousel.
Secondly, no traffic or ad revenue should be attributed to Google, even though the accelerated mobile pages do point to Google cache, according to AMP’s website. Some loss of traffic or problems with advertiser networks can though occur due to errors or unclear procedures, especially in the initial stage.
Additionally, you’ll in all cases lose functionality and design features when converting to AMP format. You can customize and optimize up to a point but don’t expect miracles so early in the AMP project’s development.
Not to forget, you’ll have to keep a close eye on analytics and figure out whether AMP isn’t causing more damage than doing good.
Last but not least, you’ll have to suffer knowing that accelerated mobile pages point to Google’s domain and not to yours – with all branding-related implications.
On the bright side, your site might get some additional visibility or reach an audience that would have never waited for your original pages to load. Speed is indeed important.
Should I Enable AMP?
This isn’t an easy question. You should do some testing by implementing AMP for a certain period, for example a few months, and checking results at the end of the period. Keep though in mind that caching AMP content takes time. Check under the Search Appearance report in your Google Search Console when all or most of your site’s AMP content gets cached.
The only cases where you clearly shouldn’t enable AMP are where important functionality gets lost, ads don’t appear, or there’s strong need to show up-to-date content.
