Is Google AMP dead in 2026? (And what you should use instead)

The lightning bolt has faded. In 2016, Google launched AMP. In 2026, the requirement for “Top Stories” is gone.

Is AMP dead? Yes. Should you use it on your WordPress site? No.

In this in-depth analysis, we cover the rise and fall of AMP, what the framework actually was under the hood, how to remove it from WordPress without wrecking your rankings, and what to reach for instead.

#Is AMP still relevant in 2026

No. AMP (Accelerated Mobile Pages) is no longer relevant for new WordPress projects in 2026. Google removed the AMP requirement for Top Stories in 2021, and Core Web Vitals replaced AMP as the primary performance signal for search rankings. The AMP plugin for WordPress has seen an 80% drop in downloads from its peak.

If your site currently runs AMP, the only relevant question is how to remove it safely. If you are building a new site, skip AMP entirely and focus on the modern performance stack described later in this guide.

#Are AMP pages dead

Yes. The AMP format itself still technically works — Google has not shut down the AMP cache or the framework. But the ecosystem that made AMP valuable has collapsed:

• No ranking advantage. AMP pages receive no preferential treatment in search results.
• No Top Stories requirement. Any page meeting Core Web Vitals thresholds qualifies.
• Publisher exodus. Many major publishers have removed their AMP implementations and reported no traffic loss.
• Development stopped. The AMP project receives minimal updates. No significant features have shipped since 2023.

#Google AMP status in 2026

Google’s official position is that AMP remains “supported” but is no longer recommended or required for any search feature. The AMP cache (cdn.ampproject.org) still serves cached pages, but Google has not invested in new AMP capabilities since Core Web Vitals became the primary performance metric.

For WordPress site owners, the practical status is clear: uninstall the AMP plugin, set up redirects, and invest in native performance optimization instead. See our WordPress security hardening guide for the full performance and security stack that replaces AMP.

#What AMP actually was

AMP was never a separate language. It was a constrained profile of HTML with three moving parts that worked together, and understanding those parts explains why the project ended where it did.

AMP HTML. A curated subset of tags. You could not write your own <script>. Standard elements were replaced by AMP components: <img> became <amp-img>, iframes became <amp-iframe>, analytics went through <amp-analytics>, carousels through <amp-carousel>, and dynamic behaviour was expressed declaratively through <amp-bind> and <amp-list> rather than imperative code. Inline CSS was allowed but capped by a hard budget (50 KB in the original spec, later raised to 75 KB), and external stylesheets were forbidden.

The AMP runtime (v0.js). Every AMP page loaded a single Google-hosted JavaScript library. It managed resource loading, sized every element before paint to prevent layout shift, and lazy-loaded anything below the fold. Because the runtime controlled the render pipeline, AMP pages behaved predictably. That predictability was the whole selling point.

The AMP Cache and preload. This is the part most people forget. Google did not just rank AMP pages, it copied them onto its own CDN (cdn.ampproject.org) and pre-rendered them inside the search results before you tapped. That is why an AMP result felt instant: the bytes were already on Google’s edge and partly rendered off-screen. The instant feel was never purely the format. It was the format plus Google prefetching from its own infrastructure. That bargain, speed in exchange for handing Google your pages, is the seed of everything that went wrong.

#Part 1: Why AMP failed

The goal was speed. The solution was to ban JavaScript. That framing solved a real 2015 problem and created several new ones.

#The compromise

The cost was high:

1. Brand dilution. Because pages were served from Google’s cache, users saw a google.com/amp/yoursite.com address in the URL bar, not your domain. Sharing, copying, and basic brand recognition all broke.
2. Conversion killer. The JavaScript ban that made pages predictable also made them inert. Multi-step opt-in forms, dynamic pricing, gated checkouts, and third-party booking widgets either did not work or needed brittle AMP-specific rewrites. For a content site that was tolerable. For anything with a funnel it was a direct tax on revenue.
3. Maintenance nightmare. AMP almost always meant maintaining two renderings of every template: the canonical version real users landed on, and the AMP version Google served. Two code paths, two sets of bugs, two QA passes for every change.

#The URL problem and Signed Exchanges

Google understood the URL damage and spent years engineering a fix: Signed HTTP Exchanges (SXG), part of the Web Packaging effort, which let the cache serve a cryptographically signed copy while displaying the publisher’s real URL. SXG worked, but it was complex, poorly supported outside Chrome, and it arrived after publishers had already lost patience. Papering over the URL problem with cryptography told you how deep the problem ran.

#The walled-garden controversy

Over time AMP looked less like a performance project and more like a lever. An amended antitrust complaint led by a coalition of US state attorneys general alleged that Google used AMP to advantage its own ad exchange and slow rival ad formats. Whatever the legal merits, the perception stuck: a framework marketed as an open speed standard was steering traffic and ad revenue toward the company that controlled the cache.

#The shift to Core Web Vitals

In 2021, Google introduced Core Web Vitals (CWV). The message: “We don’t care IF you use AMP. We only care that your site is FAST.”

This was the death sentence for AMP. If a standard responsive page passes the thresholds (LCP under 2.5 s, INP under 200 ms, CLS under 0.1), it earns the same ranking treatment AMP once gated, with none of the restrictions. Why maintain a restrictive parallel version of your site when you can make the original fast enough?

#The timeline of AMP’s decline

#Why publishers left, in practice

The publisher exodus was not a coordinated protest, it was a slow accumulation of small defeats. A news team would find that their AMP article could not run the same consent banner as the main site, so privacy compliance needed a second implementation. Their ad ops team would discover that an AMP-only ad format earned less than the standard stack. Their analytics would arrive through <amp-analytics> with subtly different session stitching, so the numbers never quite matched the canonical site and every quarterly report needed a caveat. Their design team would ask for one interactive feature the AMP components did not support, and the answer was always “not on AMP.” Each of these was survivable alone. Together they meant a full parallel product to keep a badge that Google then removed anyway.

#Part 2: How to safely remove AMP (de-AMPing)

If your WordPress site still runs AMP, you are carrying all of AMP’s costs for none of its former benefit. Removal is straightforward, but the redirect and canonical steps are where sites lose rankings if they rush. Work through this in order.

#Step 1: Measure the AMP traffic you actually have

Before touching anything, open your analytics and Search Console and quantify how many sessions and impressions still arrive on /amp/ URLs. Export the list of AMP URLs that currently earn impressions so you can redirect the right paths and watch for regressions afterward.

#Step 2: Confirm your canonical pages are fast first

Do not remove AMP while your standard template is slow, or you will trade a fast-but-restricted page for a slow-and-free one. Run your top canonical templates through PageSpeed Insights and confirm they clear Core Web Vitals on mobile. Fix the template first, then retire AMP. The order matters.

#Step 3: Redirect every AMP URL

AMP URLs like /post-name/amp/ must redirect to the original (301 redirect). The ?amp=1 query-string variant needs its own rule, and forgetting it leaves indexed URLs returning 404s for weeks, which is the single biggest SEO risk in this whole process.

Nginx rule:

rewrite ^/(.*)/amp/?$ /$1/ permanent;

Apache (.htaccess):

RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]

WordPress (via plugin or functions.php):

add_action('template_redirect', function() {
    if (isset($_GET['amp']) || preg_match('#/amp/?$#', $_SERVER['REQUEST_URI'])) {
        $clean_url = preg_replace('#/amp/?$#', '/', $_SERVER['REQUEST_URI']);
        $clean_url = remove_query_arg('amp', $clean_url);
        wp_redirect(home_url($clean_url), 301);
        exit;
    }
});

#Step 4: Repair canonical tags and sitemaps

With AMP live, your standard pages often pointed their rel="canonical" at the AMP version, or the AMP version self-canonicalised. Every page must now carry a self-referencing canonical to its clean URL. Yoast and Rank Math handle this automatically once AMP is gone, but verify a sample by hand. Regenerate the XML sitemap so it no longer advertises AMP URLs.

#Step 5: Monitor in Search Console

After removing AMP:

• Check the Pages report for 404 errors on old AMP URLs
• Verify redirects are working with Screaming Frog or similar
• Monitor the mobile usability report for any new issues
• Allow 2-4 weeks for Google to fully reprocess

The legacy AMP report in Search Console was itself deprecated once Google stopped treating AMP as special, which tells you everything about the format’s status.

#Part 3: The modern performance stack (2026)

You do not need AMP to be fast. Removing AMP only helps if the native site is genuinely fast, because AMP forced good habits by fiat and you now have to choose them. Here is the stack we standardise on.

#1. Hosting and time to first byte

Everything downstream sits on top of server response time. A shared host that answers the first request in 800 ms has already spent most of the LCP budget before a single byte of optimised HTML reaches the browser. Put the origin on hosting that returns a cached document in well under 200 ms, and confirm it under real load rather than on an idle staging box. AMP hid slow hosting behind Google’s cache; once you serve your own pages, the host is exposed again.

#2. Image optimization (AVIF)

AVIF delivers meaningfully smaller files than WebP with better quality. Ship AVIF with a WebP fallback and correct srcset/sizes so each device downloads only the resolution it needs. Use ShortPixel or Imagify to auto-convert on upload, or serve conversion at the edge with Cloudflare Polish.

#3. Interaction to Next Paint (INP)

INP replaced FID in March 2024 and is the metric most WordPress sites now fail. It measures how quickly the page responds to a tap or click, and the usual culprit is heavy third-party JavaScript hogging the main thread. Delay non-critical scripts (chat widgets, pixels, tag managers) until first interaction, use requestIdleCallback, and remove plugins that inject render-blocking script you do not use.

#4. Caching and CDN

You do not need Google’s AMP Cache. You need your own edge cache. Full-page caching served from a CDN close to the user (Cloudflare, Bunny.net) reproduces most of AMP’s speed advantage without surrendering the URL, with sub-50ms TTFB globally. Layer object caching (Redis) behind it so logged-in and dynamic requests stay quick too.

#5. Critical CSS

Inline the CSS needed for above-the-fold content and defer the rest so the first paint is not blocked by your full stylesheet. WP Rocket and FlyingPress handle this automatically.

#6. Font optimization

Use font-display: swap, preload the fonts used in the hero so text is visible during load, subset fonts to the characters you actually use, and consider system font stacks for body text.

#7. Speculation Rules for instant navigation

This is the honest replacement for AMP’s prefetch trick. The Speculation Rules API lets the browser prerender the next likely page before the user clicks, producing the same instant feel, from your own origin, on your own URL, with no framework.

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/*" }, "eagerness": "moderate" }
  ]
}
</script>

#Performance comparison

#Part 4: AMP vs native, the decision

For a new or existing public site the decision is not close. The one genuinely live use of the technology is AMP for Email: Gmail still renders dynamic AMP emails that let a recipient RSVP, browse, or submit a form inside the message without leaving the inbox. That is a separate product from web AMP, it rides on a different runtime, and it is not affected by anything above. If your only remaining exposure to AMP is a marketing team experimenting with interactive email, that is fine and unrelated to your website build.

#Summary

The AMP experiment is over. The open web won. Uninstall the plugin.

AMP solved a real 2016 problem and then outlived the conditions that justified it. Core Web Vitals gave Google a neutral way to reward speed, browsers shipped native APIs that reproduce AMP’s instant feel, and modern hosting made fast standard pages routine. The trade AMP asked for, control of your URL and your code in exchange for speed, no longer buys anything you cannot get another way.

The action plan is short: measure your AMP traffic, make the canonical templates pass Core Web Vitals, deactivate the plugin, 301-redirect every AMP URL, repair canonicals and sitemaps, and monitor Search Console. Your users keep the richer experience, and your developers keep a single codebase.

Explore our WordPress speed optimization services to take your project further.