Accelerated Mobile Pages, or AMP, is a web technology championed by Google with the goal to improve the browsing experience on mobile devices. From its onset, the platform was controversial, leading many developers to question whether it was worth implementing. However, Google feature-locked a few of the more beneficial avenues for site discoverability to sites using AMP. As of the middle of this year, however, this is no longer the case. If you already have it set up however, is it worth the effort to remove it, and will removing it impact SEO? Throughout this article, I'll outline a few of the issues that led me to ditch AMP when I felt it wouldn't impede my site's SEO.

Why I ditched AMP

Development overhead

When most engineers write a site using AMP, they create a separate stripped down version of their page, utilising AMP-specific features. While that’ll lead to the best results, I'm just one woman; I don't want to double the effort of any modifications to my personal site that I work on in my spare time. What I instead did, was make use of the Gatsby plugin gatsby-plugin-google-amp. While there are a fair few AMP plugins for Gatsby, I found this one easiest to maintain. While other plugins promised a much more automated setup, I found none of them produced valid AMP pages that reliably recreated the original content. I wrapped the Gatsby createPage function to generate an AMP variant and passed in some context to tell the page that it's an AMP page. Whenever something wasn't AMP compatible, I'd switch it out using the context.

This was all well and good, but as I started adding more complicated features to my blog, such as a floating table of contents and share box, maintaining an AMP variant became difficult. AMP luckily has a component called amp-social-share which I could switch out most of my share bar for, with only a minorly different feel for the user. However, I encountered major problems when using gatsby-plugin-image, Gatsby's automatic image optimisation plugin. Every time I updated that plugin, it felt like a different thing broke. By the end, I had a patch file hundreds of lines long just to get valid AMP page output.

While my example above is reasonably specific to Gatsby and the setup I had, short of creating a separate AMP site, no matter how you set it up you'll likely run into some form of these complexities.


I did not trust any analytics data that had touched AMP pages. I'm unsure if this was an issue in my setup, but even in that case, it's another added complexity to solve when using AMP. My Google Analytics data for AMP users would always feel wildly inconsistent compared to other metrics I had, such as the number of users who'd clicked my site from "Discover", a system that was AMP-only at that time. I also noticed many cases of users on an AMP page who then clicked a link on the site, taking them out of AMP. These instances would always be marked as two separate users, inflating my user count on the analytics. In fact, since removing AMP, I've noticed my user counts are significantly more stable day to day, as well as slightly higher. This finding is, of course, just correlation; we can't draw any real conclusions from that.

AMP Pages are safe to remove

When I heard the news that any site could access the Google features previously hidden behind AMP, the biggest concern I had was whether removing the pages would temporarily confuse Google and damage my SEO. After a particularly painful AMP-related problem while updating dependencies, I took the plunge. And... everything was fine? After removing the pages, I noticed no issues on Google Search Console and no drop in traffic. The traffic that previously used AMP was just all served normally.

In saying this, I did take extra special care to remove all mention of AMP from my site. In particular, I ensured that no amphtml link tags existed on my site. My experience doesn't mean it's impossible for removing AMP to cause an issue, but it looks to be perfectly safe if done cleanly.

AMP is slow

Once I removed AMP, my average page load times actually improved. I'm sure I could have optimised my AMP pages more, or maybe my non-AMP site was more optimised than what Google used as a comparison benchmark for AMP. Either way, keeping AMP around was a detriment to the user experience, not an improvement. Sadly, this is not an uncommon occurrence.


Given the above factors, removing AMP was a natural decision. The only outlying question I really have is why didn't I remove it sooner. I'm sure I could have written a much more performant and maintainable AMP site, but that would’ve required more effort than I wanted to put into my personal website. I didn’t want to spend my time and energy maintaining the site itself, I wanted to spend it writing and creating things to put on the site. I set up AMP with the hope of improved SEO and held off removing it for fear of harming my SEO. Whether technology like this has a place in the future of the web or not, I'm glad that AMP is no longer a prerequisite for being shown in various parts of Google.

About the Author

Maddy Miller

Hi, I'm Maddy Miller, a Senior Software Engineer at Clipchamp at Microsoft. In my spare time I love writing articles, and I also develop the Minecraft mods WorldEdit, WorldGuard, and CraftBook. My opinions are my own and do not represent those of my employer in any capacity.