Key Takeaways

• AMP (Accelerated Mobile Pages) is an open-source HTML framework Google launched in 2015 to make mobile pages load near-instantly.
• Google never treated AMP as a direct ranking factor, and as of a June 2021 update it stopped giving AMP pages any special advantage in Search.
• The “Top Stories” carousel no longer requires AMP, and the lightning-bolt badge that once marked AMP results in search has been retired.
• Core Web Vitals — loading, interactivity, and visual stability metrics — now drive Google’s page experience signals for both AMP and standard pages.
• Major publishers including CNN and The Washington Post, plus platforms like X (formerly Twitter), have walked away from AMP.
• The technical core of AMP still works: restricted HTML, asynchronous JavaScript, mandatory image dimensions, and delivery through the Google AMP Cache.
• For most sites today, optimizing a well-built standard page delivers equal or better results than maintaining a separate AMP version.

What AMP Is and Where It Stands in Google Search Today

Accelerated Mobile Pages, or AMP, is an open-source HTML framework that Google introduced in 2015 to fix a real problem: mobile pages that loaded too slowly and pushed visitors away. AMP strips a page down to a lean, predictable structure so it renders almost instantly on a phone. The catch — and the part many site owners still misunderstand — is that AMP was never a direct ranking factor. Google said so plainly: AMP is not a ranking factor.

So where does AMP sit in Google Search right now? On the sidelines. In a June 2021 update, Google stopped giving AMP pages a special advantage in search rankings. Instead, it started focusing on a new set of performance metrics called Core Web Vitals. The “Top Stories” carousel, once gated behind AMP for news publishers, is now open to any mobile page that loads well and meets the page experience bar. The visual lightning-bolt badge that flagged AMP results is gone too. AMP still functions, and Google still supports it, but it no longer buys you anything in the rankings that a fast standard page can’t earn on its own.

How AMP Works Under the Hood

AMP achieves its speed by accepting limits. The framework rests on three pieces working together.

Restricted HTML. AMP uses regular HTML with a stripped-down rulebook. Some standard tags are swapped for AMP-specific equivalents — the most common being <amp-img> in place of <img>, alongside <amp-video>, <amp-iframe>, and <amp-audio>. These custom elements control how resources load based on viewport position, connection quality, and available system resources, so the page fetches only what the reader actually needs to see.

Asynchronous, locked-down JavaScript. This is the strictest rule. AMP loads JavaScript asynchronously. Custom JavaScript is strictly not allowed inside an AMP page. Every page loads the AMP library from a single script tag — <script async src="https://cdn.ampproject.org/v0.js"></script> — and only AMP component scripts are permitted. No third-party synchronous scripts can block rendering. A later component, <amp-script>, opened a narrow door for custom JavaScript that still respects AMP’s performance rules, but the default posture remains heavily restricted.

Mandatory dimensions and the AMP Cache. AMP requires you to declare the width and height of every image, iframe, and video. It is mandatory to give size for the image, iframe, video tags so that the amp page can locate the space on the page without having to load the resource. That single rule eliminates the layout jumps that frustrate mobile readers. On top of that, AMP pages are served through the Google AMP Cache, a proxy-based content delivery network that validates, pre-fetches, and pre-renders pages before a user even taps the link.

Here’s how the main technical pieces compare to a standard mobile page:

That 50 KB inline CSS ceiling is worth noting: AMP HTML restricts inline CSS to a 50 KB budget and forbids custom synchronous JavaScript. The trade-off is deliberate. You give up flexibility, and in return you get a page that behaves predictably and loads fast.

Inside the Google AMP Cache

The cache is the engine behind AMP’s perceived speed. The AMP Cache is a proxy-based content delivery network (CDN) that pre-fetches and pre-renders AMP pages before they’re requested by users. When Google links to an AMP page in search, it often links to the cached copy, not your origin server — which is exactly why some publishers felt they were handing control of their URLs to Google.

The cache also rewrites your domain into a predictable subdomain. When possible, the Google AMP Cache will create a subdomain for each AMP document’s domain by first converting it from IDN (punycode) to UTF-8. The caches replaces every dash with two dashes and replaces every dot with a dash. So pub.com becomes pub-com.cdn.ampproject.org. The cache doesn’t just store HTML, either — it optimizes the payload. The Google AMP Cache caches images and fonts in addition to AMP documents, limits maximum image dimensions to prevent browser memory issues and poor responsiveness, and performs transformations to improve the delivery efficiency of images. To keep load off publisher servers, the Google AMP Cache considers any document fresh for at least 15 seconds, and any resource fresh for at least 1 minute.

Why AMP Lost Its Place in Search

AMP’s decline wasn’t one decision — it was the web catching up and Google changing the rules around it.

The first crack came early. As of May 2020, Google ditched the AMP badge and stopped prioritizing AMP format in its Top Stories carousel, marking the beginning of its decline. Removing the badge erased the one clear visual edge AMP results had. The deeper change arrived a year later, when Page Experience and Core Web Vitals became the yardstick. Once Google measured speed and stability directly, the format a page used stopped mattering — the experience it delivered did. As SEO Director Ross Allen summarized it: “As long as non-AMP pages are meeting the criteria of core web vitals and mobile visibility, they can rank alongside AMP pages.”

Two other forces sealed it. First, ordinary pages simply got faster. Developers can achieve great mobile performance using modern web technologies without needing to follow AMP’s restrictive rules. Modern hardware, 5G, and better browsers closed the gap that justified AMP in 2015. Second, AMP’s limits hurt revenue for the very publishers it was meant to serve. To speed up the web, Google had to strip down pages, which in turn throttled the kinds of ad units publishers could run, leaving publishers with limited media on AMP pages they could sell to advertisers.

So the big names left. The Top Stories requirement is gone, the lightning badge in search results is gone, and most major publishers, including CNN and Washington Post, have abandoned AMP. Allen put the functional reason bluntly: “Normal pages now supersede AMPs because they have full functionality with JavaScript and images. Previously, those functions were only available on desktop.”

Should You Use AMP in 2026?

For most websites, the honest answer is no. The current page experience framework treats AMP and standard pages identically, judging both on Core Web Vitals. AMP no longer provides the direct SEO ranking boost it once did, and for most websites, optimizing standard pages delivers better results than maintaining AMP infrastructure.

There’s a hidden cost to running AMP that catches people off guard. Each AMP-enabled page typically spawns a second URL, and Google can end up indexing and crawling the stripped-down version instead of your full page. As one analysis warns, when AMP is enabled, Google’s crawlers — and increasingly AI content engines — often scrape the AMP version of your page instead of the real one. That means search engines see a thinner copy of your content, often missing conversion elements and richer markup.

A few situations still justify AMP: large publishers with legacy AMP infrastructure already performing well, or sites where the Google AMP Cache’s edge delivery measurably beats their own hosting. If you fall outside those cases, the modern playbook is straightforward — build one fast, canonical page, hit your Core Web Vitals targets, add structured data, and let that single page do the work. The Core Web Vitals standard itself keeps evolving; INP replaced FID as a Core Web Vitals metric in March 2024, so the metrics worth chasing are the page experience signals, not the format.

The web that needed AMP no longer exists. The framework still functions, the cache still serves pages, and the technical ideas behind it — lean code, deferred resources, reserved layout space — remain genuinely good practice. But as a ticket to better Google rankings, AMP has been outrun by the open web it was built to fix.

---

If you are interested in this topic, we suggest you check our articles:

• 5 Top Ways to Optimize for AI Search Engines
• The Most Popular AI Search Engines for Users

Sources: Setupad, WPPoland, Finmark Solutions, Tutorialspoint, amp.dev, Semrush, Ahrefs, Google AMP Cache docs, Search Engine Journal

Written by Alius Noreika