AMP Is Dead: Migration Guide for Publishers

AMP no longer carries a search advantage, and Google’s documentation now reflects it. Its Search updates log records that on July 1, 2026, Google Search began taking users directly to the publisher’s AMP host pages, that publishers no longer need to update the AMP cache or configure signed exchanges, and that AMP content will continue to rank just like any other web page. That makes AMP a format decision, not a search decision. If you still run a second AMP version of every article, the open question is how to retire it without breaking URLs, leaving dead references in your templates or shipping a slower page to the readers who used to get the AMP one.

Why migrate at all

AMP isn’t penalized; the updates log says it ranks like any other page. The case for leaving is cost. A canonical non-AMP setup means two versions of every article: two templates, two ad configurations, a validation step and a plugin or build process to maintain, with no ranking benefit on the other side. The July 2026 change removed part of that work, since there is no cache to update and no signed exchange to configure, but it didn’t remove the second template.

Before deciding, check one thing: whether anything other than Google Search consumes your AMP pages. Google’s AMP removal guide treats removal from Google Search and removal from non-Google platforms as separate steps. If a partner or platform still depends on your AMP URLs, plan for it before you switch them off.

The real risk: the canonical template’s performance

When a reader who used to land on your AMP page is redirected to the canonical page, what they get is the canonical template. If that template carries heavier scripts, more third-party tags or late-loading ads than the AMP version did, the experience those readers get changes on the day you migrate.

That matters for search. Google’s page experience documentation says Core Web Vitals are used by its ranking systems, and that its core ranking systems generally evaluate content on a page-specific basis, including aspects related to page experience. The same page cautions that good results in reports like Search Console’s Core Web Vitals report don’t guarantee that pages will rank at the top of Google Search results. Google’s Discover guidance lists providing an overall great page experience among its recommendations. A publisher that depends on Discover has particular reason to know the canonical numbers before the switch.

The thresholds for good, from web.dev’s Web Vitals overview, are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of page loads, segmented across mobile and desktop. Check INP separately. web.dev describes it as the measure of interactivity, and it replaced First Input Delay as a Core Web Vital on March 12, 2024. A page can pass LCP and CLS and still fail INP.

The sequencing lesson: fix canonical performance in the same change window as the AMP removal, not after it. “Remove AMP now, fix performance next sprint” can leave a gap in which readers get a slower page while the fix waits.

The amphtml link trap

In a canonical non-AMP setup, the canonical page carries a rel="amphtml" link pointing at its AMP version, and the AMP page points back with rel="canonical". Google’s AMP removal guide starts the removal with the first half of that pair: remove the rel="amphtml" link from the canonical non-AMP page in the source code.

The mistake to avoid is retiring the AMP URLs while the canonical templates still advertise them. Remove the rel="amphtml" links in the same release that redirects the AMP URLs, so the reference and the destination change together.

The migration sequence

Run it in order. Each step protects the next.

1. Baseline both templates. Pull field data for the AMP and the canonical versions of your key templates. The web.dev INP announcement points to PageSpeed Insights, which surfaces data from the Chrome User Experience Report (CrUX). You need to know what readers will get before you move them.
2. Fix canonical performance before or with removal. Find the slow interactions in the field and fix what causes them, such as third-party scripts or heavy event handlers. If canonical INP is poor, this is the migration; the AMP teardown is the easy part.
3. Update internal links. Repoint any links that target AMP URLs to the canonical URLs, so your own navigation doesn’t depend on redirects.
4. Redirect each AMP URL to its own canonical page. Google’s guide says to configure a redirect from the removed AMP page to the canonical non-AMP page, returning either a 301 or a 302, and to use a 301 if you want to keep permalinks active. Map each AMP URL to its own canonical equivalent rather than sending all of them to a section page or the homepage.
5. Remove the rel="amphtml" links from canonical templates in the same release.
6. Update news sitemaps so they list canonical URLs.
7. Turn off AMP generation and monitor. Google’s guide says to use the AMP status report in Search Console to verify removal of a large number of AMP pages. Watch the Core Web Vitals report and Discover performance alongside it.

Google’s guide also cautions against removing AMP by deleting the content in the file; retire the page with the redirect instead. Timing depends on recrawling: Google has to revisit the AMP URLs and process the redirects.

What about signed exchanges?

Google added documentation for signed exchanges on Google Search in April 2021, according to its updates log. For AMP pages in Google Search, that chapter is over: the July 1, 2026 entry in the updates log says Google removed outdated references to the AMP viewer, AMP Cache and signed exchange from its AMP documentation, and that publishers no longer need to configure signed exchanges. Don’t build signed-exchange infrastructure as an AMP replacement. Put that engineering time into the canonical template’s Core Web Vitals, which Google’s page experience documentation does name as used by its ranking systems.

The WordPress plugin edge case

If AMP came from a CMS setting or plugin, Google’s guide notes that disabling AMP in a CMS removes all AMP pages, and that on a CMS-hosted domain the CMS can redirect users to the canonical non-AMP page once AMP is disabled; if the redirect doesn’t happen, contact the CMS provider. On a self-hosted WordPress site, don’t assume deactivation cleaned everything up. Check that a request for a former AMP URL, in both the /amp/ and ?amp patterns your site used, returns the 301 you intended rather than a stale plugin-generated page; flush rewrite rules after removal; and look for leftover AMP template files in the theme and plugin-created options before you delete anything.

Frequently asked questions

Will removing AMP hurt my rankings?

Not because AMP itself is gone. Google’s updates log says AMP content ranks like any other web page. The risk is the canonical page: if it performs worse than the AMP version readers were getting, those readers get a slower page, and Core Web Vitals are used by Google’s ranking systems. Fix the canonical template in the same change window.

Should I redirect AMP URLs one to one?

Yes. Google’s AMP removal guide says to redirect the removed AMP page to the canonical non-AMP page. Map each AMP URL to its own canonical equivalent, and use a 301 to keep permalinks active.

Do I need signed exchanges to replace AMP?

No. As of July 1, 2026, Google takes users directly to publishers’ AMP host pages, and publishers no longer need to configure signed exchanges for AMP. Spend the effort on the canonical page’s Core Web Vitals.