Is AMP still worth it beyond the news carousel?

What exactly does Google say about the use of AMP?

John Mueller's statement is clear: AMP is primarily displayed for news content in search results, via a specific AMP carousel. This positioning marks a break from the initial narrative surrounding AMP, which promised universal performance gains.

In practical terms, if your site is not news-related, your AMP pages do not receive any preferential treatment in the SERPs. Google can index and display them like any regular page, but without any visibility bonus. The AMP carousel, however, remains reserved for fresh news content.

Why this restriction to news content?

The AMP carousel was designed to address a specific problem: to quickly display news on mobile with a standardized format. Google imposes strict technical constraints (limited HTML, controlled JavaScript, inline CSS) that ensure ultra-short loading times.

For other verticals — e-commerce, corporate, SaaS, lead generation — these constraints become a hindrance. Advanced features (tracking, personalization, A/B testing) are limited or even impossible. Thus, Google sees no benefit in promoting AMP outside the news context where speed takes precedence over interactivity.

What does this change for non-news sites that have already implemented AMP?

If you have developed AMP versions for an e-commerce or corporate site, you are maintaining two versions of each page without measurable return. Google will not preferentially display your AMP in standard results, and you will not be able to access the news carousel.

Maintaining both (standard HTML + AMP) becomes a pure technical cost. Worse: synchronization bugs between versions can create canonicalization issues or duplicate content if not managed properly. Many publishers have since abandoned AMP for these specific reasons.

• AMP is reserved for the news carousel in Google SERPs
• No direct ranking advantage for non-news sites
• Maintaining both versions (standard + AMP) is costly without clear ROI
• Technical AMP constraints limit advanced features
• Canonicalization issues threaten poorly calibrated implementations

Is this statement consistent with what is observed in the field?

Absolutely. For several years, non-news sites that maintained AMP have seen no measurable positive impact on their organic traffic. A/B tests conducted by several e-commerce sites have shown that AMP and non-AMP pages perform equally in standard results.

Google has also gradually removed the AMP lightning badge from SERPs, indicating that the visual distinction no longer served their strategy. The only winning use case remains the news carousel, where AMP is still a technical eligibility requirement — even though Google claims that fast non-AMP pages can also appear there. [To be verified] in practice, the carousel remains dominated by strict AMP implementations.

What nuances should be added to this statement?

Mueller states "primarily for news content," not "exclusively." Technically, Google can display an AMP page for any type of content if it is indexed and the user clicks on the link. But display does not equate to preferential treatment.

The other nuance: AMP can still serve as a development framework to ensure maximum performance, regardless of SEO. Some teams use it as a technical safeguard. However, in this case, it must be accepted that it is an architectural choice, not an SEO strategy. The ROI becomes purely UX/conversion, not acquisition.

In what cases does this rule not apply?

If you are a news media outlet publishing fresh content daily, AMP remains relevant for accessing the news carousel. Regional press sites, national outlets, pure players, and news aggregators benefit from maintaining AMP as long as the carousel exists.

For all others (e-commerce, SaaS, corporate, non-news thematic blogs), abandoning AMP will not penalize your rankings. Focus instead on Core Web Vitals and the actual optimization of your standard HTML pages. This is where the performance battle is fought, not in adhering to a proprietary format that is losing momentum.

What should I do if my non-news site has already implemented AMP?

Your first instinct: measure the real contribution of AMP to your traffic. Segment in Analytics the sessions coming from AMP URLs versus standard ones. If the difference is marginal (less than 5% of organic traffic), the effort may not be worth it.

Next, audit the resources used to maintain AMP: development time, specific bugs, production delays caused by double validation. If the cost exceeds the gain, plan a proper migration. Redirect AMP URLs to their standard equivalents with 301s, update canonical tags, and monitor logs for a few weeks.

How can I optimize performance without AMP?

Core Web Vitals have become the real battleground. Focus on LCP (Largest Contentful Paint), FID (First Input Delay), and CLS (Cumulative Layout Shift). These metrics truly impact ranking, unlike AMP.

Technically, this can be achieved through intelligent lazy loading, modern image compression (WebP, AVIF), JavaScript code splitting, and high-performance hosting. The gains are measurable and benefit all your users, not just those who click on a nonexistent news carousel for your vertical.

What mistakes should be avoided during a migration away from AMP?

Never abruptly remove AMP pages without redirection. Google has indexed them, backlinks may point to them, and users may have those URLs in their favorites. A sudden removal creates 404 errors and destroys link equity.

Another pitfall: forgetting to remove the <link rel="amphtml"> tags from your standard pages after migration. Google will continue to look for AMP versions and will raise errors in Search Console. Clean up the markup and submit a new sitemap without the AMP URLs.

• Segment AMP vs standard traffic in Analytics to measure the real impact
• Calculate the maintenance cost of AMP (development time, bugs, complexity)
• Redirect all AMP URLs with 301s to their standard equivalents
• Remove rel="amphtml" tags from source pages
• Update XML sitemap to exclude AMP URLs
• Monitor logs and Search Console for 30 days post-migration
• Focus efforts on Core Web Vitals (LCP, FID, CLS)