AMP Is Dead: Migration Guide for Publishers

Published Read 7 min read

On this page

AMP no longer earns any ranking or Top Stories advantage, so if you are still running it, the only open question is how to migrate off it without losing the canonical-page performance and Discover eligibility that AMP was quietly masking. The framework still functions, but the SEO rationale is gone: Top Stories was decoupled from AMP in the June 2021 Page Experience update, the AMP badge in search results was removed, and major publishers have abandoned the format. The real migration risk is not the redirect itself. It is the moment AMP stops being served from Google’s cache and your origin’s Core Web Vitals, especially INP, get exposed to ranking and Discover signals for the first time.

The current reality: migrate, do not maintain dual infrastructure

For years AMP bought you a guaranteed-fast experience served from Google’s cache and a ticket into the Top Stories carousel. Both rationales are dead. Since the 2021 Page Experience update, Top Stories eligibility is tied to Core Web Vitals on your standard pages, not to AMP. The lightning-bolt badge that marked AMP results is gone. Google now measures real-world performance through field data on your canonical URLs, so a fast non-AMP page competes on equal footing with a cached AMP one.

That leaves AMP as pure operational cost. You are maintaining a second, constrained version of every article: a stripped-down subset of HTML, a forbidden-tag list, custom components instead of normal JavaScript, and a validation step that breaks when a developer ships ordinary markup. The dual-rendering setup, the AMP-specific ad stack, the validation CI, and the plugin maintenance all persist with no countervailing search benefit. The verdict is not “consider migrating.” It is migrate, and do it deliberately, because the failure modes are specific and avoidable.

Why your canonical Core Web Vitals are the real risk

Here is the trap that catches publishers. When AMP served your content from Google’s cache, the experience users got in Top Stories and Discover was governed by AMP’s performance, not your origin’s. AMP effectively masked whatever was wrong with your canonical templates: heavy third-party tags, layout shift from late-loading ads, sluggish interaction response. The day you stop serving AMP, the canonical page is what Google measures and what users land on.

The metric most likely to bite is Interaction to Next Paint (INP), which replaced First Input Delay as a Core Web Vitals metric in March 2024. INP measures responsiveness across the whole visit, not just the first interaction, and it is unforgiving of the heavy JavaScript and third-party ad logic typical of publisher templates. A page can pass Largest Contentful Paint (good at or under 2.5 seconds) and Cumulative Layout Shift (good at or under 0.1) while failing INP (good at or under 200 milliseconds at the 75th percentile of field data). AMP forbade most of the scripts that wreck INP, so your canonical INP may be genuinely poor and you would never have seen it in the field, because real users were being served the cached AMP version.

This is why migration is not a redirect task, it is a performance task. Discover-dependent publishers feel any gap immediately, because Discover continues to weigh page experience. The expert move is to remediate canonical CWV in the same change window as the AMP removal, not afterward. Teams that sequence it (remove AMP first, “we will fix performance next sprint”) fall into a performance valley: traffic from Discover and Top Stories softens before the fix lands, and they spend the gap explaining a drop they engineered.

Your canonical pages currently carry a bidirectional link relationship with their AMP versions. The canonical HTML includes a <link rel="amphtml" href="..."> pointing at the AMP URL, and the AMP page includes a <link rel="canonical"> pointing back. Google relies on that pair to understand which is the cached variant and which is authoritative.

The single most common migration mistake is removing the AMP pages (or redirecting them) while leaving the amphtml link tags in place on the canonical pages. Google then follows a rel="amphtml" reference to a URL that 301s or 404s, wasting crawl on a dead pointer and sending a confused signal about a page that no longer exists. Strip every amphtml link tag from your canonical templates in the same deployment that retires the AMP URLs. Remove the reference and the destination together, not one and then the other weeks later.

The migration sequence

Run this as an ordered checklist, not a loose set of tasks. The order protects you from the performance valley and the dead-reference trap.

  1. Baseline canonical Core Web Vitals first. Pull field data from the Core Web Vitals report in Search Console and from the Chrome User Experience Report for your canonical URLs, segmented by template. You need to know your canonical INP, LCP, and CLS before you change anything, because these are the values users will get post-migration.
  2. Fix INP before or with removal. Defer or remove the third-party scripts and heavy event handlers that inflate INP. This is the load-bearing step. If canonical INP is poor, fixing it is the migration, and the AMP teardown is the easy part.
  3. Update internal links. Repoint any internal links that currently target AMP URLs to the canonical URLs so you are not relying on redirects for your own navigation.
  4. Deploy one-to-one 301 redirects from each AMP URL to its canonical equivalent. Map them individually. A bulk redirect of all AMP URLs to a section page or homepage signals “no equivalent exists” and risks soft-404 treatment.
  5. Strip the amphtml link tags from canonical templates in the same release as the redirects.
  6. Repoint the Google News sitemap (and any news-specific sitemaps) to the canonical URLs so Publisher Center and News crawling see the correct addresses.
  7. Deactivate the AMP plugin or build step and monitor. Watch Discover performance, the Core Web Vitals report, and the Page Indexing (Coverage) report for redirect processing and any new not-indexed reasons.

Timelines here are crawl-rate dependent, not fixed. Google has to recrawl the AMP URLs, process the redirects, and consolidate signals onto the canonical pages, and high-volume news sitemaps are crawled often while deep archive URLs are not. Expect the transition to play out over weeks, faster for fresh content, slower for the long tail.

SXG: the technical successor, and when to skip it

Signed Exchanges (SXG) are the closest thing to an AMP successor for publishers who valued the prefetch-from-cache speed. SXG lets Google prefetch and serve your content from its cache while preserving your own URL in the address bar and supporting full JavaScript, which AMP never did. Google Search still supports SXG for both mobile and desktop, and it can prefetch SXG content to improve real-world LCP. Critically, SXG is not a ranking factor in itself; its only search value is the LCP improvement from prefetch, which then feeds page experience.

The practical catch in 2026 is tooling. SXG requires server-side packaging and certificate management with a special certificate that supports the CanSignHttpExchanges extension, and the managed one-click options have narrowed (Cloudflare retired its automatic SXG support). For a large publisher with platform engineering, SXG can be worth the setup to recover prefetch speed. For a regional or mid-size publisher, it usually is not: the certificate rotation, packaging infrastructure, and ongoing maintenance cost more than the marginal LCP gain, and a well-optimized canonical page that passes Core Web Vitals already captures most of the user-experience benefit. Get your canonical CWV genuinely good first; only then evaluate whether SXG’s prefetch is worth the operational tax.

The WordPress plugin residue edge case

If you ran AMP through a WordPress plugin, deactivating it does not fully remove it. Plugins commonly leave orphaned database entries (post meta, options, and sometimes custom tables), AMP-specific theme template files, and rewrite rules that can still resolve old AMP URL patterns. Before you delete anything, audit what the plugin created: check for residual ?amp or /amp/ rewrite behavior, leftover template files in your theme, and orphaned rows in wp_postmeta and wp_options. Flush rewrite rules after removal and confirm that requesting a former AMP URL returns your intended 301, not a stale plugin-generated page. Clean the residue deliberately so you are not left with half-live AMP routes contradicting your redirects.

Frequently Asked Questions

Will removing AMP hurt my rankings?

Not for the loss of AMP itself, because AMP confers no ranking or Top Stories benefit. The risk is indirect: if your canonical pages have worse Core Web Vitals than the cached AMP version users were getting, you can lose page-experience-driven visibility in Top Stories and Discover. Remediate canonical CWV in the same change window to avoid that.

Do I have to redirect AMP URLs one to one, or can I bulk-redirect them?

Map them one to one to the canonical equivalent. Bulk-redirecting all AMP URLs to a homepage or section page signals that no equivalent exists and risks soft-404 treatment, which loses the signals you are trying to consolidate.

Is SXG required to replace AMP?

No. SXG is optional and is not a ranking factor; it only recovers some of AMP’s prefetch speed for LCP. A canonical page that genuinely passes Core Web Vitals captures most of the benefit without SXG’s certificate and packaging overhead.

Sources

Related posts:

  1. Neighborhood-Level SEO: Why “Local” Isn’t Local Enough Anymore TL;DR Local SEO strategies treating entire metro areas as single markets are leaving rankings on the table. Search behavior varies dramatically between neighborhoods within the same…...
  2. Mobile Rankings Tanked But Desktop Is Fine When mobile positions collapse while desktop holds steady, you are not looking at a content or authority problem. You are looking at a mobile-specific experience failure that desktop never exposed.......
  3. What Is Crawl Budget and Does It Matter for Small Sites? For the vast majority of small sites, the answer is no, and acting as if it does is misdirected effort. Crawl budget is a real constraint, but it only binds......
  4. How to Do SEO for YouTube Videos YouTube ranks on engagement, not authority. Where Google web search weighs links and domain trust, YouTube weighs watch time, audience retention, click-through rate, and the session time a video generates.......
  5. Informational SEO is Dead. Here’s What’s Left. Publishing top-of-funnel informational content primarily to capture search clicks has lost its economics. AI Overviews now answer "what is" and "how to" queries directly inside the results page, so the......
  6. Edge SEO: Implementing Changes at the CDN Layer Edge SEO ships header, redirect, hreflang, schema, and meta changes in hours by running serverless workers at the CDN layer, instead of waiting weeks for an engineering backlog to clear.......
  7. Your Contact Page Ranks Higher Than Your Service Pages A contact page outranks your service pages for the queries you actually care about when two things stack: it carries more internal-link weight than the service pages, and it contains......
  8. Redirects Are Working But Traffic Still Dropped A redirect that verifies clean in a crawler proves one thing only: the hop resolves with a 301 and lands on a live page. It does not prove that the......
  9. Google Keeps Choosing the Wrong Canonical A canonical tag is a hint, not a directive, and Google says so directly: it takes your declared canonical into consideration, but it can and does select a different URL......
  10. Google Is Indexing Parameters You Blocked in Robots.txt Robots.txt controls crawling, not indexing, and that single distinction explains the whole paradox. Google can index a URL it has never crawled, purely from external link signals, which is exactly......
  11. SEO Quarterly Business Reviews: Executive Reporting and Strategic Alignment A quarterly business review exists to keep SEO funded and strategically aligned, and it does that by reporting outcomes instead of activity. Executives do not allocate budget based on how......
  12. SEO Team Capacity Planning: Workload Modeling and Resource Allocation Capacity planning is the constraint that forces real prioritization. SEO work is effectively unbounded; there is always another page to optimize, another competitor to analyze, another technical issue to chase,......
  13. Magento SEO at Enterprise Scale Without Losing Sanity Enterprise Magento (now Adobe Commerce) SEO is an architecture-constraint problem, not a configuration problem. The platform's defaults generate crawlable URLs faster than you can tune settings: layered navigation multiplies filter......
  14. SEO vs GEO: A Misframed Debate and the Real Answer "Should I do SEO or GEO" is a false choice. Visibility has fragmented across traditional search engines and AI engines that retrieve and cite sources differently and that share surprisingly......
  15. Original Research as an SEO Moat Original research is defensible for one reason: the asset is data your competitors cannot replicate. Informational content gets reverse-engineered within weeks, because anyone can read the same sources and rewrite......