I am a big fan of a faster web, and I have nothing against AMP-technology-as-a-framework used to build web pages, but I have to admit to being happy to be able to predict the end of standalone AMP versions sitting alongside regular web pages.
I’d love to hear others’ perspectives on this, so come and discuss with me on Twitter:
So all this stuff about AMP.
— Will Critchlow (@willcritchlow) November 5, 2021
Some of our customers have tested moving away from AMP.
There were no detectable negative impacts on search performance.
That's it. That's the tweet.
Accelerated Mobile Pages (AMP) were controversial from the outset because of the close ties to Google, a range of specific early architectural decisions (lack of support for other ad networks, analytics, Google cache display URLs and more), and probably most of all for the “incentives” for adoption that appeared to prioritise the uptake of Google’s pet technology over the supposed real goal of speeding up the web. When you could only appear in Top Stories by using AMP, no matter how fast your own technology was, it was hard to defend as a purely user-centric play.
Over time, many of the architectural issues were resolved, and the platform that remained, while still closely tied to Google, did less to encourage the most egregiously intimate integrations. You were less likely to have your content indexed on Google cache URLs for example.
According to public statements, the “incentives” were rolled back as well: Google said in May that inclusion in Top Stories no longer required publishers to use AMP. What reportedly did not go away was an internal focus on continuing to push AMP including, allegedly, adding a 1s delay to non-AMP ads to give AMP a “nice comparative boost” [PDF].
It seems now as though the focus is on AMP as a framework for building regular web pages but it has stuck in most people’s minds as a way to build “amphtml” duplicate versions of pages on your main site, with a canonical link back to the original page. This dual codebase setup added to its unpopularity. A huge amount of effort and energy was expended on building and maintaining these parallel sets of pages.
The mindset of this being “another thing we have to do” rather than an opportunity was, in my opinion, cemented by the approach initially taken with analytics. To begin with, Google set defaults and encouraged marketers to think about traffic from their own AMP versions of their own pages to the main website as a “channel” (i.e. similar to referral traffic) rather than thinking about the source of traffic to the AMP versions themselves. This never made sense to me if they wanted publishers to think of this as a tool for making their website fast, rather than a requirement for inclusion in Top Stories carousels. I always felt that the goal should be to think about AMP versions as if they were owned-and-operated pages ranking in search results, being emailed and linked etc. Thinking of them as a channel emphasised the feeling that they were hosted on Google’s infrastructure, and were more like an advert for your content than the content itself.
In sum, then, we had:
- A Google-controlled platform
- That introduced a huge amount of technical work and maintenance of two codebases
- With, at least initially, a lot of technical limitations and missing features
- Being pushed via transparent and less transparent incentives and boosts
It’s no wonder that many publishers felt that this was something they had to do, but that they wished they could just ignore.
We are seeing the decline of AMP
I heard from many publishers that they wished they could deprecate their AMP versions. They kept them under duress, for the traffic benefit they brought, but organisations really wanted to deploy the dual maintenance effort into improving their main websites. Unfortunately, for a long time, the AMP requirement for inclusion in Top Stories was an undeniable traffic driver, and the decision to keep AMP around was a no brainer. They might have been reluctant, but the decision was clear.
When Google made the announcement that AMP was no longer a requirement, it was a high priority for some of our customers to test whether they still needed to keep their AMP versions. As I said on twitter:
Some of our customers have tested moving away from AMP.
There were no detectable negative impacts on search performance.
Many publishers are still digesting the changing technical requirements, and the revelations coming out of the litigation mentioned previously [PDF]. I believe that those alone might be enough to push some publishers away from continued investments in developing AMP versions, but when you combine it with the data we are seeing about the lack of an incremental traffic opportunity, I predict that we are going to see a rapid drop in major publishers maintaining AMP versions of their content.
Other tech companies are seeing the writing on the wall
Tech companies like Twitter had also embraced AMP, but in general had simply used it when it was present and not when it was not, rather than artificially incentivising its use. The tide may be beginning to turn at companies other than Google, though with Twitter announcing that they were “discontinuing support for [AMP]” (see write-ups with more context at SearchEngineLand and The Verge).
Summary
AMP was a relatively unpopular project from the outset that nevertheless got huge early adoption by providing exclusive access to incremental traffic opportunities. As those opportunities become not exclusively available to AMP technology, I expect to see the downsides of duplicate maintenance effort and suspicion about Google’s motives lead to a gradual phasing out of AMP from more and more major publisher architectures.
If you are a publisher that wants to test whether you need to continue maintaining AMP versions of your pages, get in touch.
Image source: Johannes Plenio.
