AMP SEO: Is the Speed Benefit Still Worth the Trade-Off?

AMP SEO refers to the practice of implementing Accelerated Mobile Pages to improve page speed, mobile experience, and search visibility. Google created the AMP framework in 2015 to strip web pages down to their fastest possible form, and for several years it carried meaningful ranking advantages. That advantage has narrowed considerably since Google’s Core Web Vitals update shifted the focus from AMP specifically to page experience broadly.

Whether AMP is worth implementing today depends entirely on your technical setup, your audience, and what you are trying to achieve. It is not a universal answer, and treating it like one is where most teams go wrong.

What Is AMP and What Was It Actually Designed to Do?

AMP stands for Accelerated Mobile Pages. It is an open-source HTML framework, originally backed by Google, that creates stripped-down versions of web pages designed to load almost instantly on mobile devices. The core mechanism is simple: AMP removes most JavaScript, caches pages on Google’s servers, and restricts what CSS and HTML you can use. The result is a page that loads fast because it has been forced to shed almost everything that makes pages slow.

When it launched, the pitch was compelling. Mobile was overtaking desktop in search traffic, and the average mobile page was painfully slow. Publishers were losing readers before the page even loaded. AMP offered a practical shortcut: implement the framework, get your content into Google’s AMP cache, and serve near-instant pages to mobile users from Google’s infrastructure rather than your own servers.

The incentive Google built in was access to the Top Stories carousel in mobile search results, which for news publishers represented significant traffic. For a few years, AMP was effectively a requirement if you wanted that placement. That changed in 2021 when Google opened Top Stories eligibility to any page that met Core Web Vitals thresholds, AMP or not.

That single policy change fundamentally altered the AMP value calculation. The framework did not disappear, but its strategic necessity did for most sites.

How Does AMP Interact With Core Web Vitals?

Core Web Vitals are Google’s three primary page experience metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). These measure how fast the main content loads, how responsive the page is to user input, and how stable the layout is as elements render. Google uses these signals as part of its ranking algorithm.

AMP pages, by design, tend to perform well on LCP and CLS because they strip out the JavaScript and render-blocking resources that cause both problems. An AMP page served from Google’s cache will almost always load faster than a standard page served from a typical hosting environment. That is not a small thing. Slow pages cost real traffic, and I have seen that play out directly in client accounts where load time improvements correlated with measurable ranking gains.

But here is what the AMP conversation often misses: Core Web Vitals are achievable without AMP. A well-optimised standard page with proper image compression, efficient JavaScript loading, a solid CDN, and clean server response times can pass all three thresholds. When I was managing SEO strategy across a portfolio of clients at iProspect, we routinely hit strong Core Web Vitals scores on standard WordPress and custom-built sites without touching AMP. The framework was never the only path to speed.

The question is not whether AMP helps with Core Web Vitals. It does. The question is whether you need AMP to achieve passing scores, or whether conventional optimisation gets you there more efficiently.

If you want a fuller picture of how page experience fits into your broader search strategy, the Complete SEO Strategy hub covers the full range of technical and content signals that drive rankings.

What Are the Real Costs of Running AMP?

This is where most AMP discussions go quiet. The benefits get documented extensively. The costs get buried in footnotes.

Running AMP properly means maintaining two versions of every page: the standard version and the AMP version. Those two versions need to stay in sync. Every time you update content, change a template, add a new feature, or adjust your tracking setup, you are doing it twice. That development overhead compounds over time, and it is rarely free.

Analytics is a specific pain point. AMP pages do not run standard Google Analytics or Tag Manager implementations out of the box. You need to configure AMP-specific analytics, and even then, session attribution and cross-device tracking behave differently. I have sat in reporting meetings where the AMP traffic simply was not being counted correctly, and the team did not know it for weeks. When your analytics are broken, your decisions are broken. That is not a small problem.

Design restrictions are another cost that gets underestimated. AMP’s constraints on JavaScript and CSS mean that many standard UX components, personalisation features, and conversion elements either do not work or require significant workarounds. If you are running a content site where the page is the product, that is manageable. If you are running an e-commerce site where the page needs to convert, AMP’s limitations become a direct commercial liability.

There is also the question of what happens when Google’s AMP cache serves your page. The URL shown in the browser is a Google AMP URL, not your domain. That has implications for brand recognition, direct traffic attribution, and in some cases, ad revenue. Publishers who monetise through display advertising found that AMP’s ad restrictions affected their yield. Some found workarounds. Many found the trade-off unfavourable.

Who Should Still Be Using AMP?

The honest answer is a narrower group than the AMP evangelists would have you believe, but a broader group than the AMP critics acknowledge.

News publishers and large-scale content operations with high mobile traffic and limited development resource are the clearest case for AMP. If you are publishing dozens of articles a day, your standard pages are slow, and you do not have the engineering capacity to rebuild your entire front-end for performance, AMP offers a practical shortcut. The speed gains are real, the implementation is relatively predictable, and the trade-offs on design and analytics are more acceptable when the content itself is the primary product.

Sites in markets where mobile connectivity is poor or inconsistent also benefit more from AMP than sites in high-bandwidth markets. The performance delta between AMP and a well-optimised standard page narrows significantly on fast connections. On slower connections, AMP’s cache-served delivery still provides a meaningful advantage.

E-commerce sites should almost always look elsewhere. The conversion functionality that AMP restricts, forms, dynamic pricing, personalisation, complex checkout flows, is exactly what e-commerce depends on. The speed benefit rarely compensates for the conversion cost. I have not recommended AMP to a single e-commerce client in the last four years, and I have not regretted that position.

Lead generation sites fall into similar territory. If your page exists to capture a form submission, you need full control over that form, its validation, its tracking, and its integration with your CRM. AMP complicates all of that without providing a compensating benefit that you could not achieve through conventional speed optimisation.

The Moz Whiteboard Friday on headless SEO is worth reading alongside this. Headless architectures and AMP share some philosophical DNA around separating content delivery from the traditional CMS stack, and understanding one helps you think more clearly about the other.

How Do You Implement AMP Without Breaking Your SEO?

If you have decided AMP is the right call for your situation, implementation quality matters more than implementation speed. A poorly implemented AMP setup creates more SEO problems than it solves.

The canonical relationship between your standard and AMP pages needs to be correct. Your standard page should include a link tag pointing to the AMP version. Your AMP page should include a canonical tag pointing back to the standard page. This tells Google which version is the primary one and prevents duplicate content issues. Get this wrong and you can end up with the AMP version being indexed as the canonical, which causes problems if you ever decide to remove AMP later.

Structured data needs to be present on both versions. If your standard pages have Article schema, your AMP pages need it too. Google uses structured data to understand content type and eligibility for rich results. Missing or inconsistent schema across your AMP and standard versions creates gaps in how your content is understood.

Validate your AMP pages before they go live. Google provides an AMP validator, and there is also a command-line tool for bulk validation. AMP errors are not always obvious from visual inspection, and an invalid AMP page does not get served from Google’s cache, which means you lose the speed benefit you implemented AMP to achieve in the first place.

Analytics configuration deserves dedicated attention. Set up AMP analytics separately, test it thoroughly, and reconcile your AMP and non-AMP data in reporting. Do not assume the standard implementation carries over. It does not.

Monitor your AMP pages in Google Search Console. There is a dedicated AMP report that surfaces validation errors, coverage issues, and impressions data. Check it regularly, especially after template changes or CMS updates that might inadvertently break your AMP output.

What Happened to AMP’s Search Advantages?

It is worth being precise about what AMP’s search advantages actually were, because a lot of the commentary conflates different things.

AMP was never a direct ranking factor in the traditional sense. Google did not give AMP pages a boost in standard organic results simply for being AMP. What AMP provided was eligibility for the Top Stories carousel, which for news publishers was a significant traffic source. Top Stories placement is prominent, mobile-first, and drives substantial click volume for breaking news and trending topics.

When Google removed the AMP requirement for Top Stories in 2021, it did not remove speed as a factor. It changed the mechanism. Now any page that meets Core Web Vitals thresholds is eligible for Top Stories, regardless of whether it uses AMP. That is a meaningful policy shift because it means publishers can compete for the same placement without the AMP overhead, provided their standard pages are fast enough.

The practical effect has been a gradual decline in AMP adoption among publishers who have the technical resource to optimise their standard pages. Publishers who lack that resource, or who are already deeply invested in AMP infrastructure, have largely stayed with it. That is a reasonable position. Ripping out a working AMP implementation to rebuild page speed from scratch carries its own risks and costs.

What has not changed is that speed matters. Google has been consistent on this for years, and the Core Web Vitals framework has made the measurement of speed more specific and more actionable than it was when AMP launched. The argument for speed is as strong as it has ever been. The argument for AMP specifically is weaker than it was five years ago.

How Should You Decide Whether to Keep, Remove, or Implement AMP?

This is the decision most teams find difficult, because it requires honest assessment rather than following a trend. I have spent a lot of time in rooms where the question was framed as “should we do AMP?” when the more useful question was “what problem are we actually trying to solve?”

Start with your current Core Web Vitals data. Pull your field data from Google Search Console and your lab data from PageSpeed Insights. If you are passing LCP, INP, and CLS on mobile, AMP is not solving a problem you have. Your energy is better spent elsewhere in your SEO programme.

If you are failing Core Web Vitals, identify why before reaching for AMP. Most Core Web Vitals failures have identifiable causes: unoptimised images, render-blocking JavaScript, poor server response times, layout shifts from ads or embeds. Many of these are fixable without AMP. Get a technical audit done, understand the root causes, and assess whether conventional fixes are feasible within your development constraints.

If conventional fixes are not feasible, and your site is content-heavy with high mobile traffic, AMP becomes a more reasonable option. But go in with clear eyes about the ongoing maintenance cost and the analytics complexity.

If you already have AMP implemented and it is working, the bar for removing it should be high. Removing AMP from a site that has been running it for years is not a trivial operation. You need to ensure your standard pages can pass Core Web Vitals before you remove the AMP versions, and you need to handle the redirect and canonical changes carefully to avoid traffic drops. I have seen AMP removals go wrong when teams treated them as simple deletions rather than structured migrations.

The decision framework is not complicated, but it requires you to look at your actual data rather than defaulting to what everyone else is doing. That is true of most SEO decisions, and it is something I come back to repeatedly when I see teams chasing tactics without a clear commercial rationale.

If you want to think about AMP in the context of a broader search strategy rather than as an isolated technical decision, the Complete SEO Strategy hub is the right place to start. Technical signals like page speed do not exist in isolation from content quality, link authority, and search intent alignment.

What Does AMP Mean for Your Content Strategy?

One thing that rarely gets discussed in AMP conversations is what the framework does to your content experience, not just your content delivery.

AMP pages are fast. They are also stripped back. The design constraints that make them fast also make them less distinctive. When your content is served from Google’s AMP cache, the experience is clean and functional, but it is not your brand. The header, the navigation, the sidebar, the related content modules, many of the elements that build familiarity and drive return visits are either absent or restricted.

For a reader who arrives on an AMP page, reads the article, and leaves, your brand has barely registered. They have consumed your content through Google’s infrastructure. That is fine if your primary goal is raw traffic volume. It is less fine if you are trying to build an audience, grow a newsletter, or move readers through a content funnel.

I think about this in terms of what you are optimising for. If you are optimising for impressions and clicks, AMP can help. If you are optimising for audience development and downstream conversion, the stripped-back AMP experience works against you. Most content operations are trying to do both, which is why the AMP decision is rarely as clean as the framework’s advocates suggest.

The broader point is that speed and experience are not the same thing. You can have a fast page that delivers a poor experience, and you can have a rich experience that loads quickly if you build it properly. AMP prioritises speed by constraining experience. That trade-off is sometimes worth making. It is not always worth making.

About the Author

Keith Lacy is a marketing strategist and former agency CEO with 20+ years of experience across agency leadership, performance marketing, and commercial strategy. He writes The Marketing Juice to cut through the noise and share what works.

Frequently Asked Questions