TL;DR
Google removed the AMP requirement for Top Stories in June 2021 and has been deprioritizing AMP signals since. Publishers still running dual AMP/canonical setups are maintaining twice the infrastructure for zero ranking benefit. But migrating away from AMP isn’t just deleting amp/ pages. Your analytics attribution, ad revenue systems, canonical relationships, and URL structures are entangled with AMP in ways that break unexpectedly during migration. The safe migration path requires understanding what AMP actually did for your specific implementation before you remove it. Critical 2024 consideration: Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) in March 2024 as a Core Web Vital. If your canonical pages have poor INP scores, removing AMP exposes that weakness to Google’s ranking algorithms.
The Conversation
Nathan, director of digital at a regional news publisher, 85 employees, $12M revenue (60% from digital ads), WordPress with AMP plugin, intermediate technical knowledge, frustrated because maintaining AMP doubles content workload with unclear benefit: We’ve been running AMP for five years. Google killed the Top Stories requirement. Is there any reason to keep it?
SDC SEO Brain: Probably not, but “kill AMP” without analysis is how publishers break their sites. First question: which AMP plugin are you using? The official AMP plugin (now deprecated), AMP for WP (third-party), or a custom implementation?
Nathan: I think it’s the official one. The one that was recommended years ago.
SDC SEO Brain: The official AMP plugin was deprecated in 2023. If you’re still running it, you’re on unsupported software with no security updates or compatibility fixes. This makes migration more urgent. More importantly, each implementation type has different removal complexity. Official plugin removal can leave orphan database entries. AMP for WP has different hooks that persist after deactivation. Custom implementations may have AMP templates embedded in your theme that persist after plugin deactivation. We need to audit before deciding migration approach.
Nathan: How do I audit what the plugin actually did?
SDC SEO Brain: Three checks. First, look at your database. In WordPress, check the wpoptions table for AMP-related entries. Check wppostmeta for per-post AMP settings. The official plugin created extensive database entries that don’t auto-remove. Second, check your theme. Look for amp/ subdirectories or AMP-specific template files. Third, check your .htaccess or nginx config for any AMP-related rewrite rules. Document what you find before deactivating anything.
Nathan: I didn’t realize there would be database cleanup. What happens if I just deactivate without cleaning up?
SDC SEO Brain: Orphan database entries don’t break your site, but they bloat your database and can cause conflicts with other plugins. More critically, if any AMP template files remain in your theme, WordPress might still try to serve AMP-like content even without the plugin, creating broken pages. Clean deactivation requires removing all three layers: plugin, database entries, and template files.
Nathan: Got it. Now, what percentage of our traffic comes from AMP URLs versus canonical URLs?
SDC SEO Brain: Check Google Search Console. Under Performance, filter by “AMP” page experience. Compare impressions and clicks for AMP vs non-AMP. What’s the split?
Nathan: AMP pages: 2.1 million impressions, 89K clicks. Non-AMP: 4.8 million impressions, 156K clicks. So non-AMP already gets more traffic.
SDC SEO Brain: Your CTR is roughly equivalent (4.2% AMP vs 3.2% non-AMP), which suggests no dramatic ranking penalty either way. The impression difference indicates Google is already serving your canonical pages more often than AMP. That’s a good sign for migration. Google has been shifting preference away from AMP since 2021, and your data reflects that shift. Now the harder question: how is your ad revenue split between AMP and non-AMP pages?
Nathan: I’d have to check with our ad ops team. Why does that matter?
SDC SEO Brain: AMP has a different ad ecosystem. AMP ads load through amp-ad components with restrictions on JavaScript. Publishers often have completely different ad setups between AMP and canonical pages. If your AMP pages are monetizing better or worse than canonical, that affects migration priority and risk assessment.
Nathan: Fair point. Let me get that data.
SDC SEO Brain: While you’re gathering that, check something else. Open one of your AMP articles and look at the canonical tag. Where does it point?
Nathan: It points to the regular article URL. Like /news/article-title/ instead of /news/article-title/amp/.
SDC SEO Brain: Good, that’s standard. Now check the reverse: on your canonical article, is there an amphtml link pointing to the AMP version?
Nathan: Yes, there’s a link rel=”amphtml” in the head.
SDC SEO Brain: That bidirectional linking is what tells Google these are paired pages. When you migrate, removing the AMP page without removing the amphtml link from canonical creates a broken reference. Google follows that link, hits a 404, and might temporarily confuse your canonical signals. Small detail, but it’s the type of thing that causes traffic dips during migration.
Nathan: So I need to remove both the AMP pages and the amphtml links at the same time?
SDC SEO Brain: Ideally yes. Or at minimum, redirect AMP URLs to canonical URLs and remove the amphtml links. The redirect tells Google “this content moved” while the amphtml removal tells Google “stop looking for an AMP version.”
Nathan: Should I 301 redirect all AMP URLs to their canonical versions?
SDC SEO Brain: Yes. The redirect serves two purposes. First, any external links pointing to your AMP URLs transfer their equity to canonical URLs. Second, any users with bookmarked AMP pages or cached search results land on the right page instead of a 404. The redirect should be permanent (301), not temporary.
Nathan: How long do I keep the redirects active?
SDC SEO Brain: Minimum 12 months, then evaluate. After 12 months, check GSC for traffic to AMP URLs and run your AMP URLs through Ahrefs to see remaining backlink value. If traffic is near zero and remaining backlinks are low-authority (social shares, aggregators), you can convert redirects to 410 Gone responses. If any AMP URLs have backlinks from DR 50+ sites, keep those redirects indefinitely. The redirect cost is negligible, but unnecessary redirects add server processing and can mask actual 404 issues in your logs.
Nathan: Our ad ops team got back to me. AMP pages have 23% lower RPM than canonical pages.
SDC SEO Brain: That number needs context. Aggregate RPM comparison between AMP and canonical is often misleading because traffic sources differ. AMP traffic typically comes from Top Stories and Discover (breaking news readers, quick scanners). Canonical traffic includes organic search (researchers, deeper intent). These audiences behave differently regardless of page format. For accurate comparison, segment in GA4: filter to same traffic source (e.g., organic search only), same device (mobile), same content type. Then compare RPM. Your 23% gap might be real, or it might reflect audience differences. Either way, AMP’s JavaScript restrictions do limit ad competition. Header bidding partners often bid 20-40% less on AMP inventory because they can’t run their full optimization stack.
Nathan: Why would AMP monetize worse? I thought it was supposed to be better because pages load faster.
SDC SEO Brain: Faster loading helps user experience but doesn’t help ad revenue. AMP restricts JavaScript, which limits ad formats, targeting capabilities, and header bidding competition. Many premium ad partners don’t support AMP fully or run reduced bidding on AMP inventory. Your canonical pages can run whatever ad stack you want with full JavaScript. More competition equals higher RPMs.
Nathan: So AMP was always a bad deal for publishers?
SDC SEO Brain: Not always. When Top Stories required AMP, publishers faced a choice: lose Top Stories visibility or accept lower RPMs on AMP traffic. For breaking news publishers, Top Stories drove enough incremental traffic to offset the RPM loss. The math changed when Google removed the requirement. Now AMP has the monetization penalty without the visibility benefit. This is an economics problem: the incentive structure that made AMP rational in 2017-2020 no longer exists, but publishers haven’t updated their infrastructure to reflect the new equilibrium.
Nathan: When exactly did Google remove the AMP requirement?
SDC SEO Brain: June 2021. Google announced the Page Experience Update, which made Core Web Vitals the ranking factor instead of AMP specifically. Non-AMP pages with good CWV scores became eligible for Top Stories. Since then, Google has been pushing Signed Exchange (SXG) as the AMP alternative.
Nathan: I’ve heard of SXG but don’t really understand it. What is it?
SDC SEO Brain: Signed Exchange is a protocol that lets Google prefetch and serve your pages from their cache while preserving your URL in the browser address bar. With AMP, users saw Google’s AMP cache URL. With SXG, users see your actual URL even when Google serves cached content. For publishers, this matters because it maintains brand visibility and accurate analytics attribution. SXG also allows full JavaScript, so you’re not restricted like AMP. Your ad stack, your tracking, your interactive elements all work normally.
Nathan: How does SXG actually work technically?
SDC SEO Brain: Your server generates cryptographically signed packages of your HTML. These packages include proof that the content came from your domain. Google can prefetch these packages and serve them to users, but the cryptographic signature proves origin. From the user’s perspective, they see your URL and your content, even though Google served it. From Google’s perspective, they can offer fast loading through prefetch while respecting your branding and revenue mechanisms. It’s a technical middle ground between full cache (AMP) and full origin fetch (standard pages).
Nathan: Is SXG necessary? Or can I just optimize my canonical pages?
SDC SEO Brain: Not necessary, but potentially valuable for large publishers. SXG’s benefit is prefetch performance. When Google knows a user is likely to click your result, it can prefetch the SXG package before the click. The page loads nearly instantly. For breaking news where seconds matter, this is valuable. For evergreen content where users don’t mind a 1-2 second load, it’s less critical. The effort to implement SXG is significant: you need web server support (Cloudflare offers it natively, Google Cloud CDN offers it, self-hosting requires nginx configuration and certificate management), certificate setup specifically for SXG (not your regular TLS cert), and testing infrastructure. For smaller publishers, that effort might be better spent on direct CWV optimization.
Nathan: We’re not huge. 85 employees, regional news. Is SXG worth it for us?
SDC SEO Brain: Probably not as an immediate priority. Your immediate priority is clean AMP migration without traffic loss. Secondary priority is canonical CWV optimization. If after those two steps you’re still seeing performance gaps compared to national competitors, then evaluate SXG. But SXG won’t fix fundamental performance problems. If your canonical pages have poor LCP because of unoptimized images, SXG prefetch doesn’t solve that. Fix the foundation first.
Nathan: Speaking of CWV, what should I know before removing AMP?
SDC SEO Brain: Critical topic. AMP masked your actual performance from Google because AMP pages loaded from Google’s cache, not your servers. Your canonical pages might have terrible Core Web Vitals scores that you’ve never had to fix because AMP was the mobile experience. Removing AMP exposes your canonical pages to Google’s Page Experience signals directly.
Nathan: How do I check my canonical page CWV?
SDC SEO Brain: Two sources. GSC has a Core Web Vitals report broken down by URL groups. That shows aggregate data for your indexed pages. For specific pages, use PageSpeed Insights or Chrome DevTools Lighthouse. Check your homepage, your top traffic articles, and a random sample of older content. Look specifically at three metrics: LCP (Largest Contentful Paint) should be under 2.5 seconds. CLS (Cumulative Layout Shift) should be under 0.1. And critically for 2024: INP (Interaction to Next Paint) should be under 200ms.
Nathan: INP? I’ve been focused on FID.
SDC SEO Brain: Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as an official Core Web Vital in March 2024. This is a significant change that many publishers missed. FID measured only the first interaction delay. INP measures responsiveness throughout the entire page session, including all interactions like clicks, taps, and keyboard inputs. Sites that passed FID can fail INP because INP is stricter and more comprehensive. If your canonical pages have heavy JavaScript (ad scripts, video players, tracking pixels, social embeds), INP is likely your weak point.
Nathan: What’s our INP score?
SDC SEO Brain: Check in GSC Core Web Vitals report. It should show INP status now instead of FID. Also check in PageSpeed Insights for specific pages.
Nathan: Checking… Our mobile INP is “needs improvement” at 340ms. Desktop is fine at 180ms.
SDC SEO Brain: 340ms mobile INP is a problem. Google’s threshold for “good” is under 200ms, “needs improvement” is 200-500ms, “poor” is over 500ms. You’re 70% above the good threshold. When you remove AMP, Google’s mobile ranking signals will use your canonical page INP instead of AMP’s clean performance. This could hurt your mobile rankings and Discover visibility.
Nathan: So I need to fix INP before removing AMP?
SDC SEO Brain: Either before or simultaneously. Don’t remove AMP and wait to see rankings drop, then try to fix INP. That creates a valley where you’re exposed to both the transition disruption and the performance penalty. INP optimization usually involves deferring non-critical JavaScript, optimizing event handlers, breaking up long tasks on the main thread, and reducing third-party script impact. For publishers, the biggest INP killers are usually ad scripts, video player initialization, and social sharing widgets that execute on load.
Nathan: How do I fix INP without breaking our ads?
SDC SEO Brain: Work with your ad ops team. Modern ad implementations can lazy-load ads below the fold, defer header bidding until after initial render, and use web workers for heavy processing. The goal isn’t removing ads but sequencing their load to not block user interactions. Google’s own documentation says ads should load asynchronously and not block main thread during initial page interaction. Ask your ad partners if they have INP-optimized integration guides. Most major SSPs released updated implementation guidance in 2023-2024 specifically for INP compliance.
Nathan: This is more complex than I expected. What about Discover traffic? I’ve heard AMP affects Discover.
SDC SEO Brain: Discover’s algorithm weighs page experience signals, including Core Web Vitals. When Google served your AMP version to Discover users, your canonical CWV didn’t matter for that traffic. Post-migration, Google evaluates your canonical pages for Discover eligibility. If your canonical pages have poor CWV, especially mobile, you might see Discover traffic decline because Google’s algorithm considers user experience.
Nathan: What percentage of our traffic is Discover?
SDC SEO Brain: Check GA4 or GSC. In GSC, Discover has a separate report under Performance. What’s your monthly Discover traffic?
Nathan: About 22% of our mobile traffic comes from Discover.
SDC SEO Brain: 22% is significant. For publishers where Discover represents 20%+ of traffic, poor canonical CWV combined with AMP removal can drop Discover traffic 30-50% in the first 4-8 weeks. That’s why CWV optimization can’t wait until after migration. They need to happen together. The conventional wisdom that says “migrate first, optimize later” is backwards for publishers with significant Discover traffic.
Nathan: After migration, should I request removal of the old AMP URLs from Google?
SDC SEO Brain: No need. The 301 redirects tell Google these URLs have moved permanently. Google will process the redirects, consolidate signals to canonical URLs, and eventually drop AMP URLs from the index. Requesting removal manually doesn’t speed this up and might confuse the consolidation process.
Nathan: Timeline for Google to fully process the migration?
SDC SEO Brain: Calculate based on your specific crawl rate and domain authority. Check GSC Crawl Stats for average daily requests. High-authority news sites (DR 60+) typically see Google process changes in 2-3 weeks. Mid-authority regional publishers (DR 40-60) need 4-6 weeks. Lower authority sites might take 8-12 weeks. For your estimated 10,000-15,000 AMP URLs, expect 2-4 weeks for redirect discovery and 6-8 weeks for full consolidation assuming mid-authority. You can accelerate by submitting an updated sitemap and manually requesting indexing for your highest-traffic articles. Don’t panic if AMP URLs appear in search results for several weeks post-migration. That’s normal cache behavior, not a sign of failure.
Nathan: One more thing. We have Google News sitemap that includes AMP URLs. Do I need to update that?
SDC SEO Brain: Yes, critical catch. Your Google News sitemap should list canonical URLs, not AMP URLs. If it lists AMP URLs that now redirect, Google News might see redirect chains or have processing delays. Update your sitemap to list canonical URLs before or simultaneously with the redirect implementation.
Nathan: I think our sitemap is auto-generated by the plugin. When I disable AMP, it might break the sitemap.
SDC SEO Brain: Test this in a staging environment first. Disable the AMP plugin, regenerate sitemap, verify it produces canonical URLs without breaking. If the plugin generated your sitemap and removing the plugin breaks it, you need an alternative sitemap solution ready before migration. Don’t find out in production that your sitemap disappeared.
Nathan: Good point. I’ll test in staging first.
SDC SEO Brain: Smart approach. The entire migration should be tested in staging: internal link updates, amphtml tag removal, redirect logic, sitemap generation, and CWV performance of canonical pages under real ad load. Once verified in staging, deploy to production with confidence.
Nathan: What’s the complete checklist for migration day?
SDC SEO Brain: In order: First, verify canonical CWV scores are acceptable (LCP under 2.5s, CLS under 0.1, INP under 200ms). Second, update internal links from AMP to canonical URLs. Third, deploy 301 redirects from all AMP URLs to canonical equivalents. Fourth, remove amphtml link tags from canonical page templates. Fifth, update sitemap to list canonical URLs only. Sixth, submit updated sitemap to GSC. Seventh, deactivate AMP plugin. Eighth, clean up orphan database entries and template files. Ninth, monitor GSC Coverage, Performance, and Discover reports daily for first two weeks. Tenth, verify redirects are working via spot checks and log analysis.
Nathan: That’s comprehensive. What’s the biggest risk I should watch for?
SDC SEO Brain: Two risks. First: Discover traffic cliff. If your canonical CWV is worse than expected, Discover traffic can drop significantly in week 2-4 as Google reprocesses your pages. Monitor Discover specifically. If you see more than 20% drop, accelerate CWV fixes. Second: redirect implementation errors. A misconfigured redirect (wrong destination, redirect loop, redirect chain) can cause immediate traffic loss. Test redirects thoroughly before deployment and monitor 404 rates in GSC Coverage report after migration.
Nathan: If something goes wrong, can I roll back?
SDC SEO Brain: Partially. You can reactivate the AMP plugin and restore amphtml links. But Google will have already started processing the change. Rolling back creates another transition that Google has to process, potentially doubling the disruption period. Better to fix forward than roll back. That’s why staging testing is critical. Find problems before production deployment.
FAQ
Q: Does Google still require AMP for Top Stories?
A: No. Google removed the AMP requirement in June 2021 with the Page Experience Update. Non-AMP pages with good Core Web Vitals are fully eligible for Top Stories. AMP provides no ranking advantage over well-optimized canonical pages. Google now offers Signed Exchange (SXG) as the non-AMP alternative for publishers wanting prefetch benefits with full JavaScript support.
Q: Will removing AMP hurt my Core Web Vitals scores?
A: AMP removal doesn’t change your canonical page CWV scores, but it exposes them to Google. During AMP era, Google served content from its cache, masking your actual site performance. Post-migration, Google evaluates your canonical pages directly. If canonical CWV is poor (especially INP over 200ms since March 2024), you may see ranking and Discover traffic regression. Optimize canonical CWV before or during migration, not after.
Q: What is INP and why does it matter for AMP migration?
A: INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. INP measures responsiveness throughout the entire page session, not just the first interaction. Sites that passed FID often fail INP because it’s stricter. For publishers with heavy JavaScript (ads, video, tracking), INP is typically the hardest metric. Poor INP on canonical pages becomes a ranking factor once AMP is removed.
Q: Why do AMP pages have lower ad revenue than canonical pages?
A: AMP restricts JavaScript, limiting ad formats, targeting, and header bidding competition. Premium partners often bid 20-40% less on AMP inventory. However, aggregate RPM comparisons are misleading because AMP and canonical traffic sources differ. Segment by traffic source (organic search only, same device) for accurate comparison.
Q: Should I 301 or 302 redirect AMP URLs to canonical URLs?
A: Use 301 (permanent) redirects. This tells Google the move is permanent and transfers link equity. Keep redirects active for minimum 12 months, then evaluate based on remaining traffic and backlink value. High-authority backlinks justify indefinite redirects. Low-authority backlinks (social shares) don’t.
Q: What is Signed Exchange (SXG) and do I need it?
A: SXG lets Google prefetch and serve your pages from cache while preserving your URL in the browser (unlike AMP which showed Google’s cache URL). SXG allows full JavaScript, so your ad stack works normally. Implementation requires web server support (Cloudflare, Google Cloud CDN, or nginx configuration) and special certificates. For large publishers competing on breaking news speed, SXG is valuable. For regional publishers, canonical CWV optimization is higher priority.
Q: How long does it take Google to process AMP migration?
A: Timeline varies by domain authority and crawl rate. High-authority sites (DR 60+): 2-3 weeks. Mid-authority sites (DR 40-60): 4-6 weeks. Lower authority sites: 8-12 weeks. Regional publishers (5,000-20,000 articles) typically see 2-4 weeks for redirect discovery, 6-8 weeks for full consolidation. Submit updated sitemap to accelerate.
Summary
Google removed the AMP requirement for Top Stories in June 2021. Since then, AMP provides no ranking benefit over properly optimized canonical pages. Publishers maintaining dual AMP/canonical infrastructure are paying infrastructure costs and monetization penalties for zero SEO benefit.
The March 2024 INP transition is critical for AMP migration. Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as a Core Web Vital. INP measures responsiveness throughout the entire page session, not just the first interaction. Sites that passed FID often fail INP. If your canonical pages have INP over 200ms (common with heavy ad scripts), removing AMP exposes that weakness to Google’s ranking algorithms.
AMP removal and CWV optimization must happen together, not sequentially. During AMP era, Google served your content from its cache, hiding your actual site performance. Post-migration, Google evaluates your canonical pages directly. If canonical CWV scores are poor (LCP over 2.5s, CLS over 0.1, INP over 200ms), removing AMP exposes that problem. For Discover-dependent publishers, poor canonical CWV combined with AMP removal can drop Discover traffic 30-50%.
Plugin-specific removal requirements vary. The official AMP plugin (deprecated 2023) leaves orphan database entries that don’t auto-remove. AMP for WP has different cleanup requirements. Custom implementations may have theme-embedded templates. Audit your specific implementation before deactivating: check wpoptions, wppostmeta, theme directories, and server configuration files.
RPM comparisons require traffic source segmentation. Aggregate AMP vs canonical RPM is misleading because traffic sources differ. AMP traffic skews toward Top Stories/Discover (quick scanners). Canonical traffic includes organic search (deeper intent). Segment by traffic source before concluding AMP monetizes worse. That said, AMP’s JavaScript restrictions do limit header bidding competition by 20-40%.
Migration requires coordinated changes across multiple systems. Internal links pointing to AMP URLs must update to canonical URLs before redirects, or every click creates unnecessary redirect chains. The amphtml link tags on canonical pages must be removed to prevent broken references. Google News sitemaps must list canonical URLs. Test all changes in staging before production deployment.
Signed Exchange (SXG) is the AMP alternative for publishers wanting prefetch benefits. SXG lets Google cache and prefetch your pages while preserving your URL and allowing full JavaScript. Implementation requires web server support (Cloudflare, Google Cloud CDN, or nginx) and special certificates. For regional publishers, canonical CWV optimization is higher priority than SXG implementation.
Redirect duration is 12 months minimum, then evaluate. After 12 months, check remaining traffic and backlink value to AMP URLs. Low-authority backlinks (social shares, aggregators) don’t justify indefinite redirects. High-authority backlinks (DR 50+ sites) justify keeping redirects permanently.
Post-migration monitoring focuses on Coverage, Performance, Discover, and CWV reports. Watch for redirect errors in Coverage. Track traffic changes in Performance segmented by source. Monitor Discover specifically if it represents significant traffic share. Check CWV report for any degradation. Full consolidation takes 6-8 weeks for most regional publishers.
Sources
- Google Search Central: Page Experience Update announcement (https://developers.google.com/search/blog/2020/11/timing-for-page-experience)
- Google Search Central: AMP on Google Search (https://developers.google.com/search/docs/appearance/google-discover)
- Google Search Central: Interaction to Next Paint (INP) (https://developers.google.com/search/docs/appearance/core-web-vitals)
- Google News Publisher Help: Google News sitemaps (https://support.google.com/news/publisher-center/answer/9606710)
- Web.dev: Core Web Vitals (https://web.dev/vitals/)
- Web.dev: Interaction to Next Paint (https://web.dev/inp/)
- Google Developers: Signed Exchanges (https://developers.google.com/search/docs/appearance/signed-exchange)