Should you really ditch AMP if your site is already fast?

Has AMP become a must-have for SEO?

For several years, AMP seemed essential for accessing certain premium features from Google, including the Top Stories carousel in search results. This situation compelled many publishers to maintain two versions of their pages: the original version and its AMP counterpart.

The initial logic was straightforward: Google favored AMP because the framework mechanically ensured ultra-fast loading times due to its strict constraints. However, this approach created a technical dependency and forced already performant sites to duplicate their infrastructure.

What changes with Mueller's statement?

Google now acknowledges that speed takes precedence over the technology used to achieve it. If your original site loads as quickly as an AMP page — or even faster — then AMP becomes redundant. This marks a significant shift in Google's philosophy.

This evolution aligns with the gradual rollout of Core Web Vitals as a ranking criterion. These metrics (LCP, FID, CLS) assess the actual performance perceived by the user, regardless of the underlying technical framework. An optimized native page can now compete with AMP on all fronts.

Do Core Web Vitals completely replace AMP as a criterion?

Not exactly. What Mueller is saying is that eligibility for premium features no longer requires AMP if your Core Web Vitals are good. However, AMP remains a valid solution for sites struggling to optimize their traditional technical infrastructure.

The AMP framework inherently imposes constraints that force performance: limited JavaScript, mandatory lazy loading, restricted inline CSS. For a complex legacy site with years of technical debt, AMP may be quicker to implement than a complete overhaul of the existing architecture.

• AMP is no longer mandatory for Top Stories and other premium features if your Core Web Vitals are strong
• Speed remains the central criterion — only the technical means to achieve it has become flexible
• Sites that are already fast can stop maintaining parallel versions
• AMP still holds value for sites that cannot easily optimize their technical stack
• Google now measures actual performance through Core Web Vitals instead of relying on a specific framework

Is this statement consistent with practices observed on the ground?

Yes and no. Google has indeed started displaying non-AMP pages in Top Stories for sites with excellent Core Web Vitals. However, the transition isn't as smooth as Mueller suggests. Some publishers still report visibility benefits from AMP, even when their native version performs better.

The problem is that Google doesn’t publish any hard data on the specific Core Web Vitals thresholds required to match AMP eligibility. Transitioning from "good Core Web Vitals" to a performance level that actually unlocks Top Stories remains [To be verified] case by case. The gray area is vast.

What nuances should be added to this recommendation?

Mueller states, "if your site is faster than the AMP version." But faster at what exactly? The LCP of a native page may be better than its AMP version over WiFi but could plummet on 3G. AMP excels particularly in degraded network conditions due to preloading and Google's cache.

Another point: abandoning AMP means losing the Google AMP cache, which served your pages instantly from Google servers. Even if your site is fast, it will never be as immediate as a pre-loaded page. For media sites where every millisecond counts, this difference could still justify AMP.

In what cases does this rule not apply?

If your sole motivation for using AMP was speed, then yes, you can abandon it. However, many sites use AMP for business reasons beyond SEO: specific ad monetization, dedicated analytics, or integration with certain platforms that still require AMP.

And let's be honest: if your original site is a heavy CMS with 15 poorly optimized WordPress plugins, achieving Core Web Vitals exceeding AMP is a fantasy. In this case, AMP remains your best short-term option while you plan a serious technical overhaul.

What should you do if you currently use AMP?

First, objectively measure the performance of your two versions. Use PageSpeed Insights, Lighthouse, and especially the ground data from your Search Console (Core Web Vitals report). Compare LCP, FID, and CLS metrics between your AMP and native pages over the last 28 days.

If your native version meets the "good" threshold on all three Core Web Vitals for at least 75% of visits, you are a candidate to abandon AMP. Otherwise, identify specific bottlenecks: unoptimized images, rendering-blocking JavaScript, poorly loaded custom fonts, non-deferred third-party scripts.

What mistakes should be avoided when migrating from AMP to native?

Do not abruptly remove all your AMP URLs without proper redirects. Google has indexed these pages, and external sites may link to them. Implement permanent 301 redirects from each AMP URL to its native equivalent. Properly configure the bidirectional canonical tags during the transition.

Another trap: believing that simply copy-pasting the AMP HTML into your native template will suffice. AMP works because it imposes strict constraints. Reproducing this performance natively requires real optimization work: lazy loading, critical inline CSS, preloading critical resources, and CDN for static assets.

How can you check that your native site is genuinely eligible for premium features?

Use Google's Rich Results Test tool to validate that your structured data (Article, NewsArticle) is correctly detected on the native version. Check in Search Console that your pages appear in the "News" report if you are a news media site.

Monitor your positions in Top Stories post-migration. If you notice a drop in visibility, it's because your Core Web Vitals aren't yet fully compensating for the AMP advantage. In that case, temporarily reactivate AMP while you further optimize your native version.

• Compare actual Core Web Vitals (Search Console) between AMP and native pages over a minimum of 28 days
• Reach the "good" threshold on LCP, FID, and CLS for 75%+ of visits before migrating
• Set up 301 redirects from all AMP URLs to their native equivalents
• Maintain the structured data Article/NewsArticle on the native version
• Monitor Top Stories eligibility and positions for 2-3 weeks post-migration
• Keep a non-indexed test AMP version to continuously compare performance