# What happens to AMP pages after migration? > When you migrate off WordPress, you generally do not recreate your AMP pages, because AMP is no longer a ranking factor or a requirement for Google's Top Stories, and a fast, statically built site makes the separate AMP version redundant. What matters instead is what happens to the old AMP URLs, the /amp/ addresses Google indexed: you map each one to a 301 redirect to its normal canonical page, so any links and residual traffic land on the real page rather than a 404. You also drop the amphtml annotations that pointed to the AMP copy, since there is nothing to point at. The result is one fast page per URL instead of two versions to keep in sync. WPBuildAI rebuilds the site to pass Core Web Vitals without AMP, and maps every old /amp/ URL to a verified 301, so dropping AMP costs you nothing in rankings or links. Source: https://wpbuildai.com/what-happens-to-amp-pages-after-migration/ By lawrence-arya ยท 2026-06-17 --- When you migrate off WordPress, you generally do not recreate your AMP pages, because AMP is no longer a ranking factor or a requirement for Google's Top Stories, and a fast, statically built site makes the separate AMP version redundant. What matters instead is what happens to the old AMP URLs, the /amp/ addresses Google indexed: you map each one to a 301 redirect to its normal canonical page, so any links and residual traffic land on the real page rather than a 404. You also drop the amphtml annotations that pointed to the AMP copy, since there is nothing to point at. The result is one fast page per URL instead of two versions to keep in sync. WPBuildAI rebuilds the site to pass Core Web Vitals without AMP, and maps every old /amp/ URL to a verified 301, so dropping AMP costs you nothing in rankings or links. ## AMP was a speed workaround, and its ranking role is gone It helps to remember why AMP existed. Typical WordPress pages, weighed down by plugins and scripts, were slow on mobile, so Google offered AMP as a stripped-down format that loaded fast, and for a while it was the ticket into the Top Stories carousel. That changed: Google [dropped the AMP requirement for Top Stories](https://developers.google.com/search/blog/2020/11/timing-for-page-experience) and moved to measuring page experience directly, so any fast page can qualify. AMP is now just one way to be fast, not a ranking signal and not a gate. That is the fact that reframes the migration question, because it means the separate AMP version is no longer earning you anything that a fast normal page would not. ## Why a fast rebuild makes AMP redundant If AMP was your route to a quick mobile page, a proper rebuild gives you the same speed on the page itself. A statically built site ships lean HTML and passes [Core Web Vitals](https://web.dev/articles/vitals) on the canonical URL, without loading the plugin stack that made the original slow. So the reason AMP existed, papering over a slow page with a stripped copy, disappears, because the real page is now fast. Keeping AMP after that would mean maintaining two versions of every page for no benefit, which is exactly the kind of duplication a clean migration is meant to remove. This is part of why a [static rebuild tends to be faster](/is-static-website-better-than-wordpress-performance) than the WordPress site it replaces. ## What to do with your old /amp/ URLs Dropping AMP does not mean ignoring its URLs. Those /amp/ addresses were indexed, may have been linked from elsewhere, and were served through Google's AMP cache, so they have to be handled or they become 404s. The clean move is to 301 redirect each AMP URL to its canonical page, so any link equity and residual traffic flow to the real page and Google consolidates the two over the next crawls, as in any [site move with URL changes](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes). To do that you need the full list of AMP URLs, which is why [extracting every URL for redirect mapping](/find-extract-all-urls-website-301-redirects) is the first practical step. Redirected properly, the AMP addresses retire cleanly and nothing that pointed at them is wasted. ## Remove the amphtml annotations There is a small cleanup that matters. AMP pages worked in a pair: the normal page carried a rel="amphtml" link pointing to the AMP copy, and the AMP copy carried a canonical pointing back to the normal page. Once AMP is gone, the rel="amphtml" annotation points at a page that no longer exists, so it has to be removed from the rebuilt pages, or you are telling Google to look for an AMP version that is not there. A clean rebuild simply does not emit those annotations, so the pages are consistent: one canonical page, no dangling pointer to a version you retired. It is a detail, but leaving it in place sends a confusing signal. ## When AMP might still be worth a second thought Honesty is worth more than a blanket rule. If you run a high-volume news operation with workflows, ad setups, or analytics built specifically around AMP, dropping it is a real project rather than a checkbox, and you should plan that transition deliberately. And a few third-party integrations were historically AMP-specific, so check whether anything you depend on assumed AMP. For the large majority of sites, though, business pages, blogs, shops, AMP is a legacy layer with no ranking value, and the migration is the natural moment to consolidate to one fast page. Knowing which case you are in tells you whether this is a redirect job or a small project. ## Steps to handle AMP in a migration 1. **Confirm AMP's status:** it is not a ranking factor, so plan to consolidate, not recreate. 2. **List every /amp/ URL** so none is missed in the redirect map. 3. **Make the canonical page fast** in the rebuild so it passes Core Web Vitals on its own. 4. **301 each AMP URL** to its canonical page with a verified redirect. 5. **Remove rel="amphtml" annotations** so no page points to a retired AMP copy. 6. **Recheck in Search Console** that AMP URLs consolidate and no 404s remain. ## Worked example: a blog that consolidated to one fast page Consider a blog that had run an AMP plugin for years, so every post existed twice, at /post/ and at /post/amp/. Moving off WordPress, the owner did not rebuild the AMP versions; instead the rebuild made each canonical post fast enough to pass Core Web Vitals on mobile, which was the whole point of AMP in the first place. Every /amp/ URL was mapped to a 301 pointing at its canonical post, the rel="amphtml" annotations were dropped, and the URL list was checked so none was missed. Over the following weeks Google consolidated the AMP addresses onto the canonical posts, no 404s appeared, and the blog kept its rankings while shedding the duplicate version it no longer needed. ## Limitation: consolidation takes a few crawls, and heavy AMP setups need planning It is honest to bound this. Redirecting the AMP URLs is correct, but consolidation is not instant: Google needs a few crawls to process the 301s, drop the AMP addresses, and settle everything onto the canonical pages, so expect the tidy-up to play out over weeks in Search Console rather than overnight. And the blanket advice to drop AMP assumes a normal site; a large publisher with AMP-specific ad, analytics, or editorial tooling should treat the change as a planned transition, because the value there is in the surrounding workflow, not in AMP as a ranking asset. ## Common mistakes - Recreating AMP out of habit, adding a duplicate version that earns no ranking benefit. - Deleting AMP but leaving its /amp/ URLs to 404 instead of redirecting them. - Missing some AMP URLs because the full list was never extracted. - Leaving rel="amphtml" annotations pointing at pages that no longer exist. - Dropping AMP without making the canonical page fast, so page experience slips. ## Key points When you migrate off WordPress, you almost never recreate AMP, because it is no longer a ranking factor or a Top Stories requirement, and a fast static rebuild makes the separate version redundant. The real work is to make the canonical page fast on its own, 301 each old /amp/ URL to that page so links and traffic are preserved and no 404s appear, and remove the rel="amphtml" annotations that would otherwise point at a retired copy. Consolidation takes a few crawls, so watch it settle in Search Console, and treat a heavy AMP-specific publishing setup as a planned transition rather than a checkbox. Done this way, you end with one fast page per URL and lose nothing in rankings or links. WPBuildAI rebuilds the site to pass Core Web Vitals without AMP and maps every old /amp/ URL to a verified 301. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.