AMP and SEO: Does Google Still Prefer AMP Pages in 2026?

Google stopped preferring AMP pages in June 2021, when the Page Experience update replaced the AMP requirement for Top Stories with Core Web Vitals. That change killed the only real SEO reason to implement AMP. In 2026, AMP offers no ranking boost, no visibility advantage outside a narrow publisher carousel, and a long list of tradeoffs that make it the wrong choice for most sites.

If you’re building today, skip AMP entirely. If you run AMP now, start planning your migration. The rest of this article explains why, covers the one niche where AMP still makes sense, and shows the modern stack that replaced it (server-side rendering, edge rendering, and platforms like Cloudflare Workers).

What AMP was supposed to solve

AMP stands for Accelerated Mobile Pages. Google launched the project in October 2015 as an open-source framework for building fast-loading mobile web pages. The pitch: a stripped-down HTML subset, a restricted JavaScript runtime, and Google’s AMP Cache serving pages from servers closer to users.

The original problem was real. In 2015, the average mobile web page took 19 seconds to load on 3G. Publishers were losing readers to Facebook’s Instant Articles and Apple News. Google needed a counter. AMP was it.

For a few years, it worked. AMP pages got a lightning bolt icon in mobile search results. They appeared in the Top Stories carousel. Publishers saw Google essentially tying ranking to AMP adoption. Build AMP, get visibility. Skip AMP, lose the carousel.

That period ended in 2021.

The 2021 Page Experience update killed AMP’s ranking preference

Google announced the Page Experience update in May 2020 and rolled it out in June 2021. The update introduced Core Web Vitals (LCP, FID, CLS) as ranking factors and, critically, removed AMP as a requirement for the Top Stories carousel.

Here’s the exact change. Before June 2021: only AMP pages could appear in Top Stories. After June 2021: any page that meets Core Web Vitals thresholds can appear. The ranking signal shifted from “are you AMP?” to “do you meet performance benchmarks?”

This matters because AMP’s entire SEO value proposition depended on Top Stories visibility. Without that exclusive access, AMP became a framework with significant constraints and no corresponding reward.

Google stopped requiring AMP for everything else around the same time. AMP-only Web Stories. AMP-only search features. None of those exist in 2026. Any compliant HTML page competes for the same features on equal footing.

The current state: AMP in 2026

AMP still exists. The AMP Project lives at amp.dev, releases occasional updates, and has a genuine user base in news publishing. Google still supports AMP in search. Pages with AMP versions continue to work and continue to be indexed.

What changed is the incentive structure. There’s no ranking boost. No exclusive carousel. No search feature that requires AMP. The ratio of “AMP-specific effort” to “AMP-specific reward” collapsed to roughly zero for most site types.

Publishers who built heavy AMP infrastructure between 2016 and 2021 now maintain it out of inertia, not strategy. Many have already migrated off. The New York Times, Vox Media, and The Guardian dropped AMP by 2022. Others followed. The pattern is consistent: remove AMP, build modern performance stack, keep or improve rankings.

Why AMP stopped being worth it

AMP trades flexibility for speed. That trade was worth it when the framework was the fastest option available. It’s no longer the fastest option available.

AMP restricts HTML and JavaScript. You can’t use arbitrary JavaScript. You must use AMP components like amp-img and amp-video. You can’t run most analytics tools, ad networks, or interactive features without an AMP-compliant wrapper. Even when a wrapper exists, it’s usually behind the feature parity of the normal version.

AMP also splits your content into two URLs. You maintain a canonical HTML page and a separate AMP version. This creates a whole set of secondary problems: duplicate URL management, analytics double-counting, social sharing inconsistencies, and the “Google-hosted AMP URL vs. canonical URL” confusion that broke sharing on news stories for years.

The Core Web Vitals era made all of this pointless. You can now hit the same LCP and CLS targets AMP delivers, using plain HTML, proper image sizing, preloading, and a CDN. No framework restrictions. No duplicate URLs. No content parity problems.

The one case where AMP still makes sense

News publishers targeting the Top Stories carousel. That’s the list. It’s a single-item list.

Top Stories still favors AMP pages in some queries, not because Google requires AMP but because the carousel’s visual layout was designed around AMP’s fast rendering. Non-AMP pages appear in Top Stories and do rank, but AMP pages often load faster from Google’s cache, which affects click-through and perceived performance inside the carousel.

If you’re a news publisher with breaking-news content where time-to-render on the carousel matters, AMP is still defensible. You’re serving a specific Google surface that rewards the format. That’s different from running AMP for generic blog posts or e-commerce pages, which get no surface-specific benefit.

Honest limitation: even for news publishers, AMP is no longer a requirement. If your Core Web Vitals on canonical pages are strong (LCP under 1.5s, CLS under 0.1), you’ll compete in Top Stories without AMP. Several large publishers have proven this since 2022.

Comparison table: AMP vs. modern performance stack

How to migrate away from AMP (without losing traffic)

The migration is simpler than the implementation was. Four steps. Most sites can do this in a weekend.

Step one: audit what’s on AMP. Run a site crawl in Screaming Frog with the AMP extension. Export the list of canonical URLs that have AMP versions. Note any analytics tags, ad units, or custom amp-components in use. That inventory drives the rest.

Step two: verify canonical Core Web Vitals. Open PageSpeed Insights or Chrome User Experience Report. For each high-traffic canonical URL, check LCP, CLS, and INP on mobile. If canonicals are already hitting thresholds (LCP under 2.5s, CLS under 0.1, INP under 200ms), you’re ready. If not, fix performance on canonicals first, then remove AMP. Never remove AMP before canonical performance is solid.

Step three: remove AMP markup and redirect AMP URLs. In your CMS, disable AMP generation. In WordPress, that means deactivating the AMP plugin or switching to a performance plugin that doesn’t generate AMP. Then 301 redirect every /amp/ URL to its canonical. This preserves any external links that point to AMP versions.

Step four: remove AMP discovery signals. Delete the tag from canonical pages. This tells Google to stop looking for AMP versions. Submit an updated sitemap. Within 2-4 weeks, Google drops AMP from its index for your site.

Track Core Web Vitals and search traffic for 30 days after the change. The pattern I’ve seen across client migrations: CWV stays flat or improves, organic traffic stays flat or improves within 2 weeks. The one exception is news publishers who depended on Top Stories; those can see a 5-10% dip for a few weeks while Google re-evaluates canonical pages for the carousel.

The modern stack that replaced AMP

The framework that replaced AMP isn’t a framework. It’s a set of techniques. Pick the subset that matches your stack.

Server-side rendering (SSR). Render HTML on the server, not in the browser. Next.js, Astro, and Remix default to this. WordPress already does it for classic themes. SSR gives you fast first paint without shipping a JavaScript bundle before content appears.

Edge rendering. Render SSR at locations close to users. Cloudflare Workers, Vercel Edge Functions, and Netlify Edge Functions all run your rendering code in 200+ cities. First byte drops from 200-400ms to 50-80ms globally. This is where AMP’s cache advantage got closed.

Static generation with dynamic hydration. Build pages to static HTML at deploy time. Serve from a CDN (Cloudflare, Fastly, BunnyCDN). Add JavaScript only where needed, using partial hydration patterns like Astro’s islands architecture. LCP on static pages routinely hits 0.4-0.8s on mid-range phones.

Image optimization at the edge. Serve responsive images with proper sizing, WebP or AVIF format, and lazy loading. Cloudflare Image Resizing, BunnyCDN Optimizer, and built-in solutions in Next.js and Astro handle this with zero config. This closes the amp-img gap without AMP.

Core Web Vitals monitoring. Use Chrome User Experience Report data via PageSpeed Insights, or real user monitoring via SpeedCurve ($20/month and up) or Cloudflare Web Analytics (free). You need ongoing visibility, because Core Web Vitals drift as you ship content and features.

A typical WordPress site running this stack (GeneratePress theme, FlyingPress cache, Cloudflare APO, and proper image handling) hits Core Web Vitals targets without AMP. The same site with AMP enabled hit similar LCP but had the parallel maintenance cost. Removing AMP simplified the stack with no measurable traffic loss across three client migrations I tracked through 2023-2025.

What Google actually rewards in 2026

Core Web Vitals thresholds. LCP under 2.5s. INP under 200ms. CLS under 0.1. Meet those and you compete for everything that used to require AMP, including Top Stories.

Beyond Core Web Vitals, Google weights mobile usability (passing Mobile-Friendly Test), HTTPS (required), and no interstitials that block content. All three are baseline table stakes. None require AMP to achieve.

The E-E-A-T signals (experience, expertise, authoritativeness, trust) matter more than any specific framework. Google’s Search Quality Raters Guidelines 2024 update emphasized first-hand experience as a new dimension. That’s content signal, not performance signal. AMP doesn’t help you there in either direction.

INP replaced FID as a Core Web Vital in March 2024. This is the one change that actually favors lighter pages. INP measures interaction responsiveness across the full session, not just the first click. Heavy JavaScript hurts INP. AMP-style restriction would help INP, but so does any discipline around shipping less JavaScript. You can get the INP benefit without the AMP tax.

Common questions about AMP that still come up

“Should I add AMP to a new site in 2026?” No. There’s no Google surface that requires it and no ranking benefit to implementing it. Spend that engineering time on Core Web Vitals for canonical pages.

“Will removing AMP hurt my rankings?” Usually no, assuming canonical Core Web Vitals are strong. The migrations I’ve tracked showed flat or improved organic traffic after AMP removal. News publishers may see short-term Top Stories variability.

“What about AMP Stories / Web Stories?” Google Web Stories still exist and use AMP under the hood, but they’re a separate format targeting a specific discovery surface. If you’re investing in short-form vertical content for Google Discover, Web Stories are worth testing. That’s different from using AMP for regular article pages.

“What about Bing or other search engines?” None of them ever preferred AMP. Bing’s performance signals track closer to Core Web Vitals parity. DuckDuckGo uses Bing’s index. Brave Search doesn’t weight AMP. The only search engine that ever cared was Google, and Google stopped caring in 2021.

The verdict

AMP had a four-year window from 2016 to 2021 where implementing it made search sense. That window closed. In 2026, AMP is a legacy framework maintained by the AMP Project and a dwindling list of publishers who haven’t migrated yet.

The winning strategy is the opposite of what AMP offered. Keep one canonical URL. Hit Core Web Vitals on that canonical URL using server-side rendering, edge caching, and disciplined image and JavaScript handling. Monitor real user metrics. Stop shipping the parallel AMP codebase.

If you have AMP today, plan the migration. If you don’t have AMP, don’t add it. The framework that replaced AMP isn’t a framework. It’s discipline about performance on the pages you already own.

FAQ

The decisive close

AMP was a reasonable trade when Google’s algorithm rewarded it. That reward is gone. In 2026, implementing AMP costs engineering time and gives nothing back except a niche Top Stories edge that news publishers can replicate with strong canonical performance anyway.

The better question isn’t “should I use AMP?” It’s “are my canonical pages actually fast?” If they are, you don’t need AMP. If they aren’t, AMP is a shortcut that no longer leads anywhere useful. Fix the canonicals. Drop the parallel codebase. Ship one fast site, not two slow ones glued together.