Is Google AMP dead in 2026? Yes for SEO, and what to use instead

Is AMP dead? As an SEO tactic, yes. Google Search indexes AMP pages like any other page, Top Stories stopped requiring AMP in June 2021, and on 1 July 2026 Google stopped serving AMP results from its own cache. The framework is not dead: the amphtml project still ships releases, and AMP for Email still works in Gmail. If you run a WordPress, Shopify or custom site today, there is no search reason to build or keep AMP pages.

This guide covers what AMP was under the hood, why it lost its place in search, how to remove it without losing rankings, and what to use instead on any stack.

#Is AMP still relevant in 2026

Not for search. Google’s own AMP documentation now says that Google Search indexes AMP pages just like other web pages, and applies the same standard to all pages, regardless of the technology used to build the page (About AMP on Google Search, updated 1 July 2026). An AMP page earns no ranking boost, no badge, and since July 2026 no instant load from Google’s cache.

If your site runs AMP, the relevant question is how to remove it safely. If you are building a new site, on WordPress, Shopify, a headless setup or a hand-built stack, skip AMP and work on the performance stack described later in this guide.

#Is Google AMP still a thing

The code is. The amphtml repository on GitHub received pushes in October 2026 and shipped three releases in August 2026. AMP is also still used for Web Stories and for AMP for Email. What disappeared is the search incentive. Publishers adopted AMP for the Top Stories carousel and the instant load from Google’s cache; the first went in 2021, the second in July 2026.

#Is Google AMP worth the engineering effort in 2026

The return on maintaining AMP is negative for almost every site. In 2016 the trade was awkward syntax and a second template in exchange for carousel visibility and a pre-rendered result. Both benefits are gone. What remains is the cost: a parallel template, restricted JavaScript, and analytics that never quite match the canonical pages.

#How AMP compares to a modern performance stack

#Are AMP pages dead

AMP pages still work and still get indexed. The incentives that made them worth building are gone:

• No ranking advantage. Google applies the same standard to AMP and non-AMP pages.
• No Top Stories requirement. Since 2021, any page that meets the Google News policies qualifies.
• No cache-served instant load. Since 1 July 2026, a click on an AMP result lands on your own AMP URL, so the AMP page is only as fast as your server.
• A plugin on maintenance mode. The official WordPress AMP plugin has not shipped a release since April 2025.

#Is Google AMP deprecated in 2026

Not formally. Google keeps the AMP documentation, the AMP Test tool and the AMP status report in Search Console. What changed in July 2026 is how Google delivers AMP results: it no longer uses the AMP viewer, the AMP Cache or signed exchanges, so publishers no longer need to update the AMP cache or configure signed exchanges. For site owners on any platform the practical status is the same: remove AMP, redirect the AMP URLs, and put the effort into the speed of your canonical pages. The speed optimization guide lists what that work covers.

#What is Google AMP and how it worked

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.

#Why Google AMP failed

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

#What were the disadvantages of AMP

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.

#Why AMP showed a google.com URL and what Signed Exchanges changed

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. On 1 July 2026 Google removed the AMP viewer, AMP Cache and signed exchange references from its Search documentation, because Search now links straight to the publisher’s AMP host. The URL problem ended by Google stepping out of the delivery path.

#AMP and the antitrust complaint against Google

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.

#How Core Web Vitals replaced AMP

Google announced Core Web Vitals in 2020 and rolled them into ranking with the page experience update in June 2021. The same update opened Top Stories to non-AMP pages and dropped the AMP badge.

That removed AMP’s reason to exist in search. A standard responsive page that passes the thresholds (LCP under 2.5 s, INP under 200 ms, CLS under 0.1) is measured the same way as an AMP page, with none of the restrictions. Google’s page experience docs still say there is no single page experience signal, and that good Core Web Vitals do not guarantee top rankings, so the gain from either approach is modest. Why maintain a restrictive parallel version of your site when you can make the original fast enough?

#AMP timeline from 2016 to 2026

#Why publishers stopped using AMP

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.

#How to remove AMP from WordPress safely

If your site still runs AMP, you are carrying all of AMP’s costs for none of its former benefit. The steps below use WordPress examples because the official plugin is the most common source of AMP pages, but the order is the same on Drupal, a custom CMS or a Shopify store that added AMP through an app: measure, fix the canonical template, redirect, clean up canonicals, monitor. 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
• Watch the Core Web Vitals report for the canonical templates that now take the AMP traffic
• Allow 2 to 4 weeks for Google to reprocess

The AMP status report in Search Console will empty out as Google drops the AMP URLs; once it shows no pages, the migration is done.

#What to use instead of AMP in 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 I 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, or the CDN built into Shopify) reproduces most of AMP’s speed advantage without surrendering the URL. Since July 2026 even AMP pages are served from your own host, so this layer matters whether you keep AMP or not. 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. It is a script tag, so it works on WordPress, Shopify themes and custom builds alike; the Speculation Rules guide for WordPress and WooCommerce covers the eagerness settings and the pages to exclude.

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

#Is Google AMP worth it in 2026

For a new or existing public site the decision is not close. The live use of the technology that matters to most businesses 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

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 in July 2026 Google stopped serving AMP results from its own cache. 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.

Before the plugin goes, the canonical templates have to pass on field data. That is what my Core Web Vitals audit measures: send the domain, plus read access to Search Console if you have it, and you get a baseline per template and the fixes that must land before the AMP URLs are redirected. For the fixes themselves, see WordPress speed optimization.