AMP SEO: What Still Works and What to Skip

AMP SEO refers to the practice of implementing Accelerated Mobile Pages to improve page speed, mobile experience, and organic search performance. Google created the AMP framework in 2015 to make mobile web pages load near-instantly, and for several years it carried real ranking advantages. That picture is now more complicated, and whether AMP belongs in your SEO strategy depends on what you are trying to solve, not on what Google announced six years ago.

The short version: AMP is no longer a ranking signal in itself, Core Web Vitals have replaced it as Google’s speed benchmark, and many sites that adopted AMP are now quietly walking it back. But there are still specific contexts where AMP delivers measurable value, and dismissing it entirely because it is no longer fashionable is just as lazy as adopting it because it once was.

What AMP Actually Is and Why It Existed

AMP, which stands for Accelerated Mobile Pages, is an open-source HTML framework that strips a web page down to its fastest-loading essentials. It limits which HTML tags you can use, bans most custom JavaScript, and serves pages from Google’s AMP cache rather than your own server. The result is a page that loads in under a second on most mobile connections.

Google introduced AMP in direct response to the mobile web being genuinely broken. In 2015, the average mobile page took somewhere between six and ten seconds to load. Users were abandoning sites before the first paragraph rendered. Publishers were losing ad revenue. Google was serving a worse search experience than it wanted to. AMP was Google’s engineering solution to a real commercial problem, and in that narrow sense it worked.

The incentive structure Google built around AMP was significant. AMP pages got a lightning bolt badge in search results. They were eligible for the Top Stories carousel, which sits above organic results and commands disproportionate click-through rates for news and editorial content. For publishers chasing traffic volume, AMP was not optional, it was table stakes.

I watched this play out across several media and publishing clients during my agency years. The ones who moved fastest on AMP saw measurable lifts in mobile organic traffic in 2016 and 2017. The ones who hesitated lost carousel placements to competitors who had implemented it. At the time, the business case was clear. What changed was not the technology, it was Google’s own position on it.

What Changed When Google Dropped the AMP Requirement

In June 2021, Google removed the requirement that Top Stories pages be AMP. Any page that meets the Core Web Vitals thresholds, specifically Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift, can now appear in the Top Stories carousel. This was a significant policy shift, and it effectively ended AMP’s privileged position in Google’s ranking ecosystem.

Google has been consistent since then: AMP is not a ranking factor. A well-optimised canonical page that passes Core Web Vitals will rank on equal footing with an AMP page. The lightning bolt badge still appears in some contexts, but it carries no algorithmic weight. It is a user interface element, not a ranking signal.

This matters because a lot of SEO advice about AMP is still written as though it is 2018. I see this regularly, articles recommending AMP implementation as an SEO priority without acknowledging that the framework’s relationship with Google has fundamentally changed. If you are making decisions based on that advice, you are optimising for a version of Google that no longer exists.

What Google replaced AMP with, in terms of speed-related ranking signals, is Core Web Vitals. These are measurable, page-level performance metrics that apply to your canonical pages, not to a stripped-down AMP version. If your canonical pages are slow, the fix is to make them faster, not to create parallel AMP versions that Google now treats as equivalent anyway.

For a grounded view of how testing and experimentation actually moves rankings, Moz’s work on SEO testing beyond title tags is worth reading. It reinforces something I have believed for years: incremental, measurable changes beat sweeping technical overhauls that are hard to attribute.

Where AMP Still Delivers Real Value

Saying AMP is no longer a ranking signal is not the same as saying it is useless. There are specific use cases where AMP continues to deliver genuine performance benefits, and ignoring those because the SEO story has changed would be its own kind of mistake.

The clearest case is high-volume editorial and news content on sites where the audience is predominantly mobile and where page speed on slower networks is genuinely degraded. If you are running a news site serving readers in markets where 4G is inconsistent or where low-end Android devices are the norm, AMP pages will load faster than even a well-optimised canonical page. That speed difference translates into lower bounce rates and higher engagement, which are real business outcomes regardless of their direct ranking effect.

I spent time working with clients across emerging markets, and the device and connectivity picture there is genuinely different from what you see in Western European or North American analytics dashboards. A page that loads in 2.1 seconds on a London broadband connection might take six seconds on a mid-range Android phone in Lagos or Jakarta. AMP collapses that gap in a way that Core Web Vitals optimisation on your canonical page often cannot fully replicate.

AMP also remains relevant for email and ad formats. AMP for Email allows interactive content inside email clients that support it, and AMP for Ads is a format that loads faster than standard display advertising. Neither of these is an SEO play, but they are legitimate performance channels that share the same underlying framework.

For publishers already running AMP at scale with established infrastructure, the case for maintaining it is often stronger than the case for migrating away. Migration carries risk. If your AMP implementation is clean, your canonical signals are correct, and your pages are performing, the disruption of removing AMP may not be worth it unless you have a specific conversion problem that AMP is causing.

The Conversion Problem Nobody Talks About Enough

AMP’s biggest commercial limitation is not technical, it is structural. AMP pages are deliberately constrained. You cannot run arbitrary JavaScript. You cannot use most third-party tracking scripts without specific AMP-compatible versions. You cannot implement the kind of personalisation, A/B testing, or conversion optimisation that most commercial sites depend on.

This creates a genuine tension. AMP can improve your load time and potentially your organic traffic. But if the AMP version of your page cannot carry your lead capture form, your chat widget, your retargeting pixels, or your CRO tests, then you are trading conversion capability for speed. That is not always a bad trade, but it is a trade, and most AMP advocates do not make it explicit.

I have seen this play out in practice. A client in the financial services sector implemented AMP across their content hub after reading that it would improve mobile rankings. Traffic to those pages increased modestly. Conversions from those pages dropped noticeably, because the AMP versions could not fire the tracking and personalisation scripts that their conversion funnel depended on. The net commercial outcome was negative despite the positive traffic signal.

Speed is not the end goal. Speed is a means to an outcome, usually engagement, conversion, or retention. If the mechanism you use to improve speed also breaks the conversion path, you have optimised the wrong thing. This is exactly the kind of situation where marketing needs to function as a business support function rather than a technical exercise. Organic search traffic has high commercial intent, which makes it even more important that the pages receiving that traffic are built to convert, not just to load.

This is also part of why thinking through your complete SEO strategy matters before making technical decisions at the page level. If you want the broader framework, the Complete SEO Strategy hub at The Marketing Juice covers how all of these components fit together commercially, not just technically.

AMP vs Core Web Vitals: How to Think About the Trade-off

The practical question most site owners face is not whether AMP is good or bad in the abstract. It is whether to implement AMP, maintain existing AMP pages, or invest that same resource into Core Web Vitals optimisation on canonical pages. These are competing uses of development time and budget, and the right answer depends on your starting point.

If your canonical pages already pass Core Web Vitals thresholds, the SEO case for AMP is essentially zero. You are already meeting Google’s speed benchmark. Adding AMP would create a parallel set of pages to maintain, introduce canonical complexity, and potentially create the conversion problems described above, for no ranking benefit.

If your canonical pages are failing Core Web Vitals, the question is whether AMP is the fastest path to fixing that or whether direct optimisation of your canonical pages is more efficient. For most sites, especially those on modern CMS platforms, direct optimisation is more sustainable. You improve the pages that users actually land on, you maintain full commercial functionality, and you do not create a parallel architecture to manage.

AMP becomes more attractive when direct canonical optimisation is genuinely difficult. Legacy CMS platforms, complex page templates, or sites with significant third-party script bloat can be hard to optimise quickly. In those cases, AMP can serve as a bridge, a way to serve fast pages while the underlying technical debt is addressed. That is a legitimate use case, but it should be framed as a temporary measure, not a long-term strategy.

One thing I have found useful when advising on these decisions is to run the numbers on what a speed improvement is actually worth commercially before committing to a technical approach. If a one-second improvement in load time is projected to lift conversion rate by a measurable amount on a high-traffic page, that quantifies the value of the investment. It also tells you how much development resource is justified. Too many technical SEO decisions are made on principle rather than on projected return.

How to Implement AMP Correctly If You Decide to Use It

If you have assessed your situation and concluded that AMP is the right tool, the implementation needs to be clean. Poorly implemented AMP creates more problems than it solves, particularly around canonicalisation, structured data, and analytics tracking.

The canonical relationship between your AMP and non-AMP pages must be explicit and correctly configured. Your AMP page should include a canonical link pointing to your standard page. Your standard page should include an amphtml link pointing to your AMP version. Without both of these in place, Google may not understand the relationship between the two versions and may treat them as duplicate content.

Structured data needs to be present on your AMP pages, not just your canonical pages. If you are targeting Top Stories eligibility for news content, your AMP pages need valid Article schema with the required fields: headline, image, datePublished, dateModified, author, and publisher. Google’s Rich Results Test will validate this, and it is worth running before you push AMP pages live.

Analytics is a common failure point in AMP implementations. Standard Google Analytics tags do not work on AMP pages. You need to use the amp-analytics component, which has its own configuration syntax. If you skip this step, you will have AMP pages generating traffic that your analytics platform cannot see, which means you cannot measure whether the implementation is working. I have audited sites where AMP pages were generating a material share of mobile traffic and the analytics team had no visibility into it because the tracking was never configured correctly.

Ad monetisation on AMP requires AMP-compatible ad tags. Most major ad networks have AMP versions of their tags, but if you are running custom or direct-sold advertising, you will need to verify compatibility before launch. This is especially important for publisher sites where advertising revenue is directly tied to page-level performance.

Testing AMP pages before they go live is non-negotiable. Google’s AMP Validator is a free tool that checks your AMP HTML against the specification and flags errors. Any validation errors will prevent your pages from being served from Google’s AMP cache, which eliminates most of the speed benefit. Validate every template, not just a sample page.

How to Migrate Away From AMP Without Losing Organic Equity

If you are running AMP pages and have decided to wind them down, the migration needs to be handled carefully. The risk is not losing AMP-specific ranking benefits, those are minimal now. The risk is losing organic equity that has accumulated on AMP URLs if those URLs have attracted links or have been indexed separately from your canonical pages.

Start by auditing which of your AMP URLs have external links pointing to them. If the AMP URL has been linked to directly rather than the canonical URL, a 301 redirect from the AMP URL to the canonical URL is required to preserve that link equity. Do not simply remove AMP pages and let them 404.

Check Google Search Console for impressions and clicks on AMP URLs. If AMP URLs are generating meaningful traffic, you need to ensure that traffic is redirected cleanly to canonical pages and that the canonical pages are fast enough to retain those users. A structured migration checklist is worth following here, even if the scope is smaller than a full site migration. The principles are the same: redirect correctly, verify indexing, monitor traffic post-migration.

Remove the amphtml link tags from your canonical pages once the AMP pages are redirected. Leaving those tags pointing to pages that no longer exist or that redirect will create crawl errors. Update your sitemap to reflect the canonical URLs only.

Monitor organic performance for four to six weeks after the migration. You are looking for any drop in mobile organic traffic that correlates with the AMP removal. If you see a drop, investigate whether it is related to page speed on the canonical pages rather than the AMP removal itself. The two can be conflated if your canonical pages are slower than your AMP pages were.

The Broader Lesson AMP Teaches About SEO Technology Decisions

AMP’s trajectory is a useful case study in how SEO technology decisions should be made. When AMP launched, the incentive to adopt it was real and the business case was defensible. Publishers who adopted it early captured genuine traffic advantages. But the technology was always Google’s solution to Google’s problem, and when Google found a better solution, the incentives changed.

I have watched this pattern repeat across twenty years in the industry. Schema markup, AMP, featured snippets, voice search, now AI Overviews. Each time, there is a period where early adopters gain an advantage, followed by a period where the advantage normalises, followed by a period where the advice still circulating is based on the first period rather than the third. The gap between what Google is doing now and what the SEO content ecosystem is recommending is almost always wider than practitioners realise.

The discipline I try to apply, and that I applied when running large agency teams, is to ask what problem we are actually solving before adopting any new technical approach. AMP solves a page speed problem. If you have a page speed problem, AMP is one potential solution. If you do not have a page speed problem, or if you have a page speed problem that can be solved without AMP, then AMP is not the answer regardless of what the SEO community is currently excited about.

Innovation in marketing technology only matters when it solves a real business problem. A faster-loading page that cannot convert is not a solution. A technically compliant AMP implementation that your analytics team cannot measure is not a solution. The technology has to serve the outcome, not the other way around.

If you want to think about AMP in the context of a complete SEO approach rather than as a standalone technical decision, the SEO strategy hub at The Marketing Juice covers how speed, content, authority, and technical foundations interact across the full organic channel.

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