If you’ve been in the web business for a while, you probably remember AMP. Google announced Accelerated Mobile Pages in late 2015 with a simple pitch: mobile web pages are too slow, so let us strip them down and serve them from our servers. The web will be faster. Everyone wins.
Except that’s not quite how it played out.
I want to tell you two stories here. One is about a client who asked us to remove AMP after it started getting in the way of business goals: better performance scores, reliable analytics, and faster website updates. The other is about AMP itself, a format that went from feeling mandatory to becoming obsolete. Both stories end the same way: with a faster site, and fewer roadblocks to growth.
What AMP actually was
For those who might not remember or never had to deal with it, AMP was a restricted HTML framework. You couldn’t use your own JavaScript. Your CSS was capped at 50KB (later raised to 75KB). Your pages were cached and served from Google’s CDN, which meant your content lived on Google’s domain, not yours. In exchange, you got a lightning bolt icon next to your search results, and for news publishers, access to the Top Stories carousel was AMP-only until 2021.
The trade-off sounded reasonable in 2015, when mobile networks were slower and most websites were bloated with tracking scripts and unoptimized images. But the restrictions were harsh. Building anything beyond a basic contact form was a fight. Custom analytics required workarounds. Interactive features your users expected were often impossible to implement. And you had to maintain two separate versions of every page on your site. One for AMP, one for everyone else.
Our client’s situation
One of our clients ran a WooCommerce-based online shop that had been built with deep AMP integration years earlier. At the time, it made sense. But by the time they came to us, AMP had turned into a problem. Their Google Page Speed Insights scores were suffering because of it, and every time they wanted to add a new feature or update the store, they ran into AMP’s restrictions.
The theme was the biggest issue. It had been heavily customized to work with AMP, and that meant the developers who built it had introduced a lot of workarounds, things like frontend styling baked into backend modules and inline CSS scattered across templates. Several plugins had been modified specifically to accommodate AMP. The mini-cart had its own AMP implementation that made the mobile layout behave unpredictably, including a bug where the mobile menu would flash on screen for a split second when loading the cart page. Product pages had content layout shift issues flagged by Google, partly caused by how AMP handled image loading.
Analytics were split too. Google Analytics and Facebook tracking had been configured through AMP’s own setup, which meant the data pipeline would need to be rebuilt from scratch once AMP was gone.
The store had accumulated what you’d call technological debt. AMP wasn’t helping performance anymore. It was actively getting in the way.
The bigger picture: why AMP was already dying
Our client wasn’t alone. By the time they came to us, AMP was already in decline, and the reasons went far beyond technical annoyances.
In 2021, Google removed AMP as a requirement for appearing in Top Stories. That was the single biggest reason most publishers had adopted AMP in the first place. The same year, Google rolled out its Page Experience update, which made Core Web Vitals the new standard for measuring site performance. You didn’t need AMP to score well on those metrics. You just needed a well-built website.
The lightning bolt icon that used to appear next to AMP results in Google Search? Gone. The preferential treatment in rankings? Gone. Major publishers started pulling out. The Washington Post, once featured as an AMP success story on Google’s own website, quietly dropped it. Search Engine Land, a publication that covers Google for a living, turned off AMP in late 2022 and wrote publicly about why.
And then there were the antitrust revelations.
The part that made everyone angry
In late 2021, a mostly unredacted version of an antitrust lawsuit led by the State of Texas against Google was released by court order, and what came out was ugly. The complaint alleged, based on internal Google documents, that AMP wasn’t just about making the web faster. According to the filing, Google had identified “header bidding,” a technology that let publishers sell ad space to the highest bidder, as an existential threat to its advertising business. The complaint also alleged AMP was designed to be incompatible with header bidding.
The complaint went further. It alleged that Google intentionally added a one-second delay to non-AMP ad loading to make AMP look faster by comparison. Internal Google communications reportedly showed employees discussing how to publicly justify making something slower. The filing also cited internal documents showing that AMP pages generated 40% less ad revenue for publishers compared to their regular pages.
Google called these claims inaccurate. But the damage was done. For many publishers, trust in AMP appeared to erode further. And the signs had been there before the unredacted complaint even dropped. Just two months earlier, Jeremy Keith, a well-known web developer who had served on AMP’s advisory committee, resigned. His reason: AMP was functionally a Google product with only a small subset of pieces that could be considered open source. The unredacted complaint intensified concerns many in the community had raised for years.
How we handled the removal
Back to our client. We didn’t just flip a switch. With AMP woven this deeply into the theme and plugins, removing it meant touching almost every part of the store. We treated it as evolution, not revolution, deploying changes step by step rather than doing one massive, risky release.
We set up a staging environment that mirrored production as closely as possible. This let us work without interfering with the client’s live site or any other development happening in parallel.
We started with the plugins. Some had AMP-specific features that needed to be stripped out. One plugin handling product reviews required updating its styles, JavaScript, and templates to drop all AMP elements while keeping the existing data structure intact. A consent management plugin that had been built around AMP was replaced with a standard solution already in use on the client’s other sites. A couple of plugins turned out to have no AMP dependencies at all, so we left those alone.
The theme was where the real complexity lived. We went through the WooCommerce templates first, product pages, category pages, and the cart, since those were the most heavily AMP-dependent parts of the site. On category pages, we replaced the old AMP-based sorting and filtering with a modern setup. The cart needed particular attention because of the mini-cart’s AMP implementation. We had to partially redo the layout and fix the mobile menu flash bug that had been annoying users.
While we were in there, we cleaned up the code. Frontend styling that had been stuffed into backend PHP modules got separated out. Inline CSS was moved to proper stylesheet files. JavaScript errors that had been quietly accumulating in the console got fixed. We set up image preloading for above-the-fold content on the homepage and product pages, and made sure lazy loading was defined for everything else.
We also addressed the Core Web Vitals issues that Google had been flagging. Content layout shifts on product pages were fixed. We worked on improving First Contentful Paint and Largest Contentful Paint scores, which had been dragged down by AMP’s overhead. Google and Facebook Analytics were reconfigured to work without AMP’s intermediary layer.
On the SEO side, we handled the standard AMP removal steps: setting up 301 redirects from AMP URLs, updating canonical tags, removing rel="amphtml" references, and submitting a clean sitemap to Google Search Console.
The results
The store came out the other side in better shape. Page Speed Insights scores improved once the AMP overhead was gone, especially in FCP and LCP metrics that had been dragged down by AMP’s mandatory JavaScript and the workarounds it required. The content layout shifts that Google had been flagging on product pages were resolved.
The store was no longer held back by AMP’s limitations. New features could be implemented directly, without checking whether they were “AMP-compatible” first. The codebase was cleaner, too. Frontend code wasn’t hiding inside backend modules anymore. Inline styles weren’t scattered across templates. Analytics were unified and reliable again.
The client’s development team could move faster. What used to require careful testing across two parallel versions of the site now only had to work once.
AMP in 2026: officially a legacy technology
As of now, AMP is widely considered dead for web pages. The AMP project still technically exists as an open-source framework, but it hasn’t received meaningful updates from Google’s search team. No new sites should be implementing it. If you’re still running AMP, you’re maintaining extra code for zero benefit.
The web caught up. Core Web Vitals gave everyone a clear, measurable set of performance targets. Modern image formats cut file sizes dramatically. CDNs and edge caching made content delivery fast without requiring you to hand your pages over to Google. Modern JavaScript frameworks, combined with server-side rendering and smart code splitting, deliver everything AMP promised without the trade-offs.
What this means if you’re still using AMP
If you have AMP on your site right now, it’s worth having an honest conversation about whether it’s doing anything for you. Check your Google Search Console. Look at how much traffic is going to AMP URLs versus your regular pages. Compare engagement metrics between the two versions. In most cases, you’ll find that AMP is generating extra maintenance work for no measurable return.
Removing AMP isn’t complicated, but it does need to be done properly. The redirects matter. The canonical tags matter. And most importantly, your regular mobile site needs to be fast before you remove the AMP safety net.
Here’s a quick checklist:
- Audit all AMP URLs on your site
- Make sure your regular pages pass Core Web Vitals
- Set up 301 redirects from AMP URLs to their canonical counterparts
- Remove
rel="amphtml"tags and update canonical references - Submit a clean sitemap to Google Search Console
- Monitor traffic and rankings for 4-6 weeks after the switch
The lesson here
AMP’s rise and fall is a good reminder that not every technology that looks like the future actually is. When Google launched AMP, it solved a real problem. Mobile web pages in 2015 were often painfully slow. But instead of helping developers build better pages, Google created a walled garden with restricted tools and preferential treatment in search results. When that preferential treatment went away, so did the reason to use AMP.
The broader takeaway: be skeptical of any technology that requires you to give up control of your content and your user experience in exchange for a ranking boost. Those boosts are temporary. Good engineering is permanent.
At Coditive, we’ve seen this pattern play out more than once. We build with open technologies and modern frameworks specifically because they give our clients full ownership of their code and content. No vendor lock-in. No dependency on a single platform’s goodwill. When the next “AMP” comes along, and something always does, our clients aren’t scrambling to migrate. They’re already on solid ground.
If you’re thinking about removing AMP, or if you just want a second opinion on your site’s mobile performance, reach out to us. We’ve done this before, and we’re happy to walk you through it.
Sources
- Unredacted Antitrust Complaint Unsealed: Google Internal Documents Show AMP Pages Brought 40% Less Revenue to Publishers – WP Tavern, October 2021
- Google throttled non-AMP page speeds, created format to hamper header bidding, antitrust complaint claims – Search Engine Land, October 2021
- Google deliberately throttled ad load times to promote AMP – The Register, October 2021
- Google Calls Non-AMP Page Throttling & Other AG Paxton’s Claims Baseless – Search Engine Roundtable, October 2021
- Jeremy Keith Resigns from AMP Advisory Committee – WP Tavern, August 2021
- AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives – WP Tavern, November 2021
- We’re turning off AMP pages at Search Engine Land – Search Engine Land, November 2022
- Accelerated Mobile Pages – Wikipedia
- In re Google Digital Advertising Antitrust Litigation, second amended complaint (unredacted) – CourtListener
- AG Paxton’s claims about AMP and header bidding are just false – Google
