11 min read · Technical SEO · Last updated July 2026
Quick answer: Most sites should remove AMP in 2026. Google no longer requires AMP for Top Stories eligibility, and properly optimized non-AMP pages consistently outperform AMP on Core Web Vitals. The risk is in the removal process — improper redirects cost you rankings.
Introduction
AMP (Accelerated Mobile Pages) was Google’s 2015 answer to slow mobile web experiences. For three years, having AMP pages was the only path to appearing in Google’s Top Stories carousel — the most valuable SERP real estate for news and content publishers.
Then Google changed the rules. In June 2021, Core Web Vitals became a ranking signal and AMP was no longer required for Top Stories. The SEO community began questioning AMP’s value proposition almost immediately.
By 2026, the calculus is clear for most sites: AMP creates more problems than it solves. It requires maintaining a parallel set of pages, strips your design and functionality, reduces conversion rates, and — because it historically served pages from Google’s cache — muddied analytics attribution.
Yet removing AMP incorrectly is a ranked-traffic risk. This guide gives you the complete playbook:
- Why the case against AMP is now overwhelming
- The exact redirect strategy to preserve rankings and link equity
- How to validate removal before deploying to production
- What to do when GSC shows AMP errors post-removal
Table of Contents
- Why AMP Made Sense (And Why It No Longer Does)
- The Business Case Against AMP in 2026
- Pre-Removal Audit — What You Have to Inventory
- The Redirect Strategy That Protects Rankings
- Removing AMP from WordPress
- Removing AMP from Custom Builds
- Validating the Removal Before Go-Live
- Post-Removal: GSC, Analytics, and Monitoring
- Core Web Vitals as the AMP Replacement Strategy
- Interactive AMP Removal Checklist Widget
- FAQ
- Conclusion
1. Why AMP Made Sense (And Why It No Longer Does)
In 2016–2019, AMP delivered real speed advantages. It preloaded content in Google’s cache, stripped JavaScript, enforced lightweight HTML, and delivered pages in under a second on mobile. For news publishers chasing Top Stories placement, the performance was transformative.
The AMP framework required sites to maintain two parallel versions of every article:
– yoursite.com/article-name — the canonical page
– yoursite.com/amp/article-name — the AMP version
Google served the AMP version from google.com/amp/yoursite.com/article-name — their own cache. This meant users never actually visited your domain when clicking AMP results.
The problems that accumulated:
-
Dual maintenance burden. Every page needed two versions kept in sync. Template changes required AMP updates. Feature additions required AMP equivalents. Developer time doubled.
-
Analytics fragmentation. Traffic to AMP pages showed as
google.com/amp/...in referral reports. Session attribution broke. Conversion tracking required custom AMP analytics implementations that few teams did correctly. -
Conversion rate penalty. AMP’s stripped functionality meant no live chat, limited forms, restricted personalization, and no JavaScript-dependent conversion features. Publishers reported 15–40% lower ad RPMs on AMP vs. canonical pages.
-
Branding loss. The AMP lightning bolt badge in SERPs and the Google-branded URL bar made users feel they were on Google, not your site — reducing brand recall and direct traffic.
-
Core Web Vitals made AMP’s speed advantage obsolete. A well-optimized non-AMP page can achieve identical or better CWV scores, and Google now ranks on those scores regardless of framework.
2. The Business Case Against AMP in 2026
The definitive signal came from large publishers who removed AMP and measured the outcome.
Washington Post (2021): Began testing non-AMP canonical pages in Top Stories. Found that their optimized canonical pages matched AMP CTR within 5% and increased session depth (pages per visit) significantly because users landed on full-featured pages.
Condé Nast: Removed AMP across properties and reported higher time-on-site and lower bounce rates after migration.
The pattern across smaller publishers: Sites that removed AMP properly (correct redirects, CWV optimization) maintained or improved organic traffic within 60–90 days. Sites that removed AMP without preparation saw 10–20% traffic drops that took 3–6 months to recover.
The conclusion: removal is safe if executed correctly; risky if rushed.
Who should keep AMP:
– Sites using AMP for non-Google distribution (some email clients, Bing News)
– Sites on servers so slow that AMP’s cached delivery is the only way to achieve acceptable performance (fix the server problem instead)
– Sites where the AMP pages are generating significant Top Stories traffic and your canonical pages have LCP above 2.5s (fix CWV first, then remove AMP)
3. Pre-Removal Audit — What You Have to Inventory
Before touching a single file, run a complete inventory.
Step 1 — Count AMP URLs in GSC.
Go to Google Search Console → Coverage → Valid. Filter by “AMP” in the page type selector. Export the full list. This is your redirect target list.
Step 2 — Count AMP URLs in Ahrefs or your sitemap.
If you have an AMP sitemap (sitemap-amp.xml), download it. Cross-reference against GSC to find AMP URLs that GSC has indexed but your sitemap may no longer include.
Step 3 — Identify backlinks to AMP URLs.
In Ahrefs → Site Explorer → Backlinks → filter for /amp/ in the URL. Any external domain linking directly to your AMP URLs will need those links to redirect to canonical pages permanently.
Step 4 — Audit AMP-specific analytics events.
If you have AMP analytics set up separately (AMP-specific GA4 streams, or AMP-specific ad tags), document these before removal so you know what tracking to deprecate.
Step 5 — Check your Top Stories performance.
In GSC → Search Results → filter by Search Type “Google News” or “Web.” Are a significant number of your Top Stories impressions on AMP URLs? If yes, prioritize CWV optimization before removal.
4. The Redirect Strategy That Protects Rankings
The redirect strategy is the single most important technical decision in AMP removal. Getting this wrong costs you link equity and rankings.
Rule 1: 301 redirect every AMP URL to its canonical counterpart.
/amp/article-name → 301 → /article-name
/article-name/amp/ → 301 → /article-name
/article-name?amp=1 → 301 → /article-name
All three URL patterns must be covered. Check your AMP implementation to determine which pattern your site uses.
Rule 2: Use pattern-matching redirects, not page-by-page rules.
For WordPress with Yoast SEO AMP or the official AMP plugin:
# Nginx: redirect /amp/ suffix
location ~ ^(.+)/amp/?$ {
return 301 $1;
}
# Nginx: redirect /amp/ prefix
location ~ ^/amp/(.*)$ {
return 301 /$1;
}
For Apache .htaccess:
# Redirect /amp/ prefix pattern
RewriteRule ^amp/(.*)$ /$1 [R=301,L]
# Redirect trailing /amp/ pattern
RewriteRule ^(.*)/amp/?$ /$1 [R=301,L]
Rule 3: Remove <link rel="amphtml"> from canonical pages.
After redirects are in place, remove the AMP link tag from your canonical pages. If Googlebot follows the amphtml link to a page that now 301s back to the canonical, it creates a redirect loop signal.
Rule 4: Update your XML sitemap.
Remove the AMP sitemap (sitemap-amp.xml) entirely. Update your main sitemap to include only canonical URLs. Submit the updated sitemap in GSC.
Rule 5: Don’t remove AMP pages without redirects.
Deleting AMP pages without redirects in place returns 404s for all indexed AMP URLs. Google has to re-discover and re-attribute all that link equity from scratch. This is the most common cause of post-removal traffic drops.
5. Removing AMP from WordPress
Using the Official AMP Plugin:
- Go to Appearance → AMP (or Plugins → AMP).
- Change AMP mode from “Transitional” or “Standard” to “Disabled.”
- The plugin auto-removes AMP routes — but does NOT set up redirects by default.
- Install Redirection (plugin) or add Nginx/Apache rules to redirect
/amp/routes. - Verify with
curl -I yoursite.com/amp/test-article— should return301.
Using Yoast SEO AMP:
- Deactivate the “Glue for Yoast SEO & AMP” plugin.
- Deactivate the AMP plugin.
- Add redirect rules manually (Nginx/Apache) or via a redirect plugin.
Using RankMath:
RankMath’s AMP settings are under RankMath → General Settings → Links. Disable AMP, then implement server-level redirects.
After deactivation, always:
– Clear all caches (WP Super Cache, W3 Total Cache, WP Rocket, Cloudflare)
– Test AMP URLs manually with curl before announcing removal
– Monitor GSC Coverage for the AMP section — it should show “Excluded” rather than “Error” for AMP URLs once redirects are live
6. Removing AMP from Custom Builds
For custom or headless builds, AMP lives in your application routing and template layer.
If AMP routes are separate endpoint handlers:
// Express.js example — remove this route
// app.get('/amp/:slug', ampHandler);
// Add redirect instead
app.get('/amp/:slug', (req, res) => {
res.redirect(301, `/${req.params.slug}`);
});
// Also handle trailing amp
app.get('/:slug/amp', (req, res) => {
res.redirect(301, `/${req.params.slug}`);
});
If AMP is a query parameter:
app.get('/:slug', (req, res, next) => {
if (req.query.amp === '1') {
const cleanUrl = req.path;
return res.redirect(301, cleanUrl);
}
next();
});
Remove from <head> template:
Find and delete <link rel="amphtml" href="..."> from every page template. Leaving this tag on canonical pages after AMP removal creates a dangling reference that Googlebot will follow and encounter a 301, creating unnecessary redirect overhead.
7. Validating the Removal Before Go-Live
Run this validation sequence in staging before deploying to production:
# Test redirect returns 301
curl -I https://staging.yoursite.com/amp/article-slug
# Expected: HTTP/2 301 and Location: /article-slug
# Verify no amphtml link in canonical
curl -s https://staging.yoursite.com/article-slug | grep "amphtml"
# Expected: no output (empty)
# Check sitemap contains no AMP URLs
curl -s https://staging.yoursite.com/sitemap.xml | grep "/amp/"
# Expected: no output
# Verify canonical page has proper canonical tag
curl -s https://staging.yoursite.com/article-slug | grep "canonical"
# Expected: <link rel="canonical" href="https://yoursite.com/article-slug">
Use Google’s Rich Results Test on 5–10 canonical URLs post-removal to verify structured data is intact. AMP removal sometimes inadvertently breaks schema markup if the AMP plugin was injecting it.
8. Interactive AMP Removal Checklist Widget
9. Core Web Vitals as the AMP Replacement Strategy
AMP’s legitimate value was speed. The answer to replacing that value is passing Core Web Vitals on your canonical pages.
Target thresholds (mobile):
– LCP (Largest Contentful Paint): under 2.5 seconds
– INP (Interaction to Next Paint): under 200ms
– CLS (Cumulative Layout Shift): under 0.1
The five optimizations that matter most for former AMP users:
1. Image optimization. Use loading="lazy" on below-fold images, fetchpriority="high" on hero images, and modern formats (WebP/AVIF). This single change reduces LCP by 30–50% on image-heavy editorial pages.
2. Critical CSS inlining. Inline your above-fold CSS in <style> tags and defer the rest. AMP forced this discipline — your canonical pages need it too.
3. Eliminate render-blocking scripts. Audit every <script> in <head>. Move to defer or async. Third-party scripts (analytics, chat, ads) are the most common LCP killers.
4. Use a CDN for static assets. AMP’s speed advantage came partly from Google’s CDN serving cached pages. Replicate this with Cloudflare, AWS CloudFront, or Fastly for your canonical pages.
5. Server response time (TTFB). Target TTFB under 600ms on mobile. Caching strategies (full-page cache for public articles, edge caching) and server-side rendering have the largest impact here.
A canonical page that passes CWV qualifies for Top Stories and delivers a better user experience than AMP ever did — without the dual maintenance burden.
Post-Removal: What Happens in GSC
After removal, GSC’s Coverage report will behave predictably:
- Days 1–7: AMP URLs show “Submitted URL seems to be a Soft 404” or “Page with redirect” status
- Days 7–21: AMP URLs transition to “Excluded — Alternate page with proper canonical tag” as Googlebot processes redirects
- Days 21–60: AMP section in GSC Coverage gradually depopulates as Google re-processes pages
- Days 60–90: Canonical pages begin appearing in Top Stories (if content is eligible) without AMP badge
Do not be alarmed by temporary drops in indexed page counts during this period. The redirects are working; Google is re-processing canonical URLs.
FAQ
Q: Will removing AMP hurt my Top Stories traffic?
Not if your canonical pages pass Core Web Vitals. Google has confirmed CWV — not AMP — is the criteria for Top Stories eligibility since June 2021. Many publishers saw Top Stories traffic increase after removing AMP because canonical pages have stronger content signals.
Q: How long until Google stops showing AMP URLs in search results?
Typically 4–8 weeks after redirects are in place. Google’s cache clears gradually. You may see the AMP lightning bolt badge disappear from some URLs while others retain it temporarily.
Q: My AMP pages have backlinks. Will I lose that link equity?
No — a 301 redirect passes approximately 90–99% of link equity to the destination URL. Update any high-value external backlinks you can control to point directly to canonical URLs.
Q: Should I remove AMP before or after optimizing Core Web Vitals?
After. Assess your CWV scores on canonical pages first. If LCP is above 4 seconds on mobile, fix it before removal — otherwise you risk losing Top Stories traffic in the gap between AMP removal and CWV improvement.
Q: What happens to AMP-specific ads and revenue?
AMP ad units need to be removed and replaced with standard ad units on canonical pages. Work with your ad operations team to migrate before removing AMP. Standard ad units typically achieve higher CPMs than AMP ad units.
Conclusion
AMP was a sensible solution to a real problem in 2015. In 2026, it is a maintenance burden that adds complexity without competitive advantage. Core Web Vitals have replaced AMP as the performance benchmark that matters for Google’s ranking and Top Stories eligibility.
The removal process is not technically complex, but it demands discipline: audit first, implement redirects before deactivating AMP, validate in staging, then monitor for 60 days post-launch.
If your site is approaching AMP removal and you want a risk-minimized rollout plan, Ignited Nepal provides migration planning for publishers and e-commerce brands across Nepal, Australia, the UAE, USA, UK, Japan, Canada, and Qatar.
Written by the Ignited Nepal team. ignitednepal.com