TL;DR

AMP (Accelerated Mobile Pages) was Google's solution to slow mobile pages in 2015. In 2026 it's effectively dead for most sites. Here's the full picture and what to do instead.

What happened to AMP:

• Google launched AMP in 2015 to make mobile pages load under 1 second using 10x less data

• For years, AMP was required to appear in Google's Top Stories carousel

• In June 2021, Google removed AMP's ranking advantage entirely and retired the lightning bolt badge

• Since May 2023, AMP and non-AMP pages rank equally in Top Stories

• CNN, Washington Post, X (Twitter), Outside Magazine, Kinsta, and Search Engine Land all walked away from AMP

• The AMP project is still open-source but gets no major updates from Google's team

Should you use AMP in 2026:

• Building a new site: No. Standard HTML plus good engineering beats AMP on every metric

• Already have AMP and it's working: Keep it for now but plan the migration off

• AMP is causing problems: Remove it. Publishers consistently report no negative impact after removal

• Exception: Very large publishers with 500,000+ templated articles and no dev bandwidth to optimize individually

What replaced AMP: Core Web Vitals (the 3 metrics that matter now):

• LCP (Largest Contentful Paint): how fast main content loads. Target under 2.5 seconds. Caused by oversized images, slow servers, render-blocking JavaScript

• INP (Interaction to Next Paint): how fast the page responds to clicks. Target under 200ms. Caused by heavy JavaScript and too many third-party scripts

• CLS (Cumulative Layout Shift): how much the page jumps while loading. Target under 0.1. Caused by images without dimensions, ads injecting from the top, font swaps

6 practical mobile speed fixes:

1. Compress images to WebP (25-35% smaller than JPEG), set explicit dimensions, add loading="lazy" to below-fold images

2. Audit and minimize JavaScript: defer non-critical scripts, remove unused pixels and trackers, replace heavy libraries

3. Add a CDN: Cloudflare's free tier works for most sites. Serves files from servers closer to the visitor

4. Fix server response time (TTFB): upgrade from shared hosting, enable server-side caching with WP Rocket or W3 Total Cache

5. Load fonts smarter: add font-display:swap to CSS, preload your headline font in the HTML header

6. Test on PageSpeed Insights at pagespeed.web.dev: simulate slow 4G on a midrange phone, target 90+ on mobile

The AMP Test tool (search.google.com/test/amp):

• Still useful if you have existing AMP pages to validate before migrating

• Useless if you're building new content without AMP: use PageSpeed Insights instead

Structured data: the mobile win most sites miss:

• Tells Google what kind of content you have, unlocking rich results in search

• FAQ schema takes up 3x the vertical space of a normal result on mobile

• Product schema shows price, availability, and stars directly in results

• Article schema needed for Top Stories eligibility

• Add it with Rank Math or Schema Pro on WordPress, or Google's Structured Data Markup Helper

Safe AMP removal checklist (6 steps):

1. Remove the rel="amphtml" link tag from main pages

2. Set up 301 redirects from every /amp/ URL to the canonical

3. Add noindex tags to AMP pages temporarily if redirects aren't ready

4. Submit an updated sitemap with only canonical URLs in Search Console

5. Monitor Search Console Coverage and Performance reports for 30 days

6. Use URL Inspection to verify canonical pages are indexed correctly

——————————————————————————————————————————-

Google AMP in 2026: The Honest Guide to Mobile Page Speed

The lightning bolt is gone.

For years, a tiny lightning bolt next to a search result meant one thing: this page loads instantly. It was Google's badge of honor for AMP pages, Accelerated Mobile Pages. Publishers rushed to adopt it. SEOs called it essential. Some said you couldn't compete on mobile without it.

Then Google quietly removed the badge. Then it dropped the requirement for Top Stories. Then major publishers like CNN and the Washington Post walked away entirely.

So where does AMP stand in 2026? And more importantly, how do you actually make your site fast on mobile, badge or no badge?

This guide gives you the honest answers. It covers what AMP is, what happened to it, whether you still need it, and the practical moves that actually improve mobile speed in 2026.

Let's cut through the noise.

What AMP Actually Was

<cite index="121-1">AMP is an open-source HTML framework Google launched in 2015 to make mobile pages load near-instantly.</cite> The full name was Accelerated Mobile Pages.

The problem it tried to solve was real. In 2015, the average mobile webpage took 15 to 20 seconds to load on a 3G connection. Most users gave up after 3 seconds. Publishers were losing huge amounts of traffic because their pages were simply too slow on phones.

AMP's solution was brutal but effective. It stripped web pages down to the bare minimum. It banned most custom JavaScript. It required images to declare their dimensions upfront. It forced asynchronous loading. And it delivered pages through Google's own AMP Cache, which pre-loaded them before the user even clicked.

The result was real: <cite index="126-1">AMP pages could load in under one second while consuming up to 10 times less data than their non-AMP counterparts.</cite>

That was a genuine breakthrough in 2015. The problem is that the web didn't stay in 2015.

The Rise, The Fall, and Where It Stands Now

For a few years, AMP looked unstoppable. Google required AMP for pages to appear in the Top Stories carousel at the top of mobile search results. That carousel was prime real estate. News publishers had no choice but to adopt it or lose visibility.

Then things started to unravel.

First came the controversies. Publishers complained that AMP pages showed Google's URL in the browser bar instead of their own, which hurt brand recognition and made sharing links awkward. Analytics tracking became complicated. Advertising integrations were limited. And design freedom was severely restricted.

Then came the legal trouble. In a 2020 antitrust lawsuit, documents surfaced suggesting Google had intentionally slowed down non-AMP pages to make AMP look faster by comparison. Whether or not that was true, the trust damage was real.

Then came the policy change. <cite index="121-1">In June 2021, Google stopped giving AMP pages any special advantage in search rankings. The Top Stories carousel no longer requires AMP, and the lightning-bolt badge that once marked AMP results has been retired.</cite>

<cite index="124-1">Major publishers including CNN and The Washington Post, plus platforms like X (formerly Twitter), have walked away from AMP.</cite>

<cite index="123-1">The AMP project remains open-source but no longer receives major updates or attention from Google's search team.</cite>

The honest verdict in 2026: <cite index="129-1">AMP's role has changed from a must-have feature to an optional tool.</cite>

Should You Use AMP in 2026?

Here's the direct answer, split by situation.

If you're building a new site: No.

<cite index="127-1">For everyone else, the 2026 answer is straightforward: standard HTML plus good frontend engineering beats AMP on every metric that matters now.</cite> You'd be creating separate URLs, maintaining two versions of every page, accepting design limitations, and building on a framework Google has quietly deprioritized. The math doesn't work.

If you already have AMP and it's working: Maybe keep it for now.

<cite index="131-1">If your AMP pages are working well, there's no reason to do away with them immediately.</cite> But have a plan to migrate off eventually. The ecosystem is shrinking and maintenance overhead will only grow.

If your existing AMP is causing problems: Remove it.

Multiple publishers have removed AMP and seen results improve. Outside Magazine saw an increase in page views after removing AMP. Kinsta documented a drop in mobile leads while AMP was active. Search Engine Land removed AMP and reported no negative impact on search performance.

<cite index="128-1">Since May 2023, non-AMP pages and AMP pages rank equally in the Top Stories carousel.</cite> There is no longer a ranking benefit to maintain.

The exception: Very large templated content sites.

<cite index="132-1">AMP can still deliver reliably fast mobile performance for highly templated content. Use AMP when you need guaranteed consistency across thousands of similar pages, like news articles, or when your technical stack can't be tuned quickly.</cite> If you're a major publisher with 500,000 articles and no development bandwidth to optimize each one individually, AMP's constraints can still be a useful forcing function.

For everyone else, the path is clearer: build fast standard pages.

What Replaced AMP: Core Web Vitals

When Google stopped privileging AMP, it didn't stop caring about mobile speed. It just moved to a new measuring stick: Core Web Vitals.

<cite index="122-1">Core Web Vitals now drive Google's page experience signals for both AMP and standard pages.</cite>

Understanding Core Web Vitals is now essential for anyone who cares about mobile SEO. Three metrics make up the score:

LCP: Largest Contentful Paint This measures how fast the main content of your page loads. Google wants this under 2.5 seconds. If the biggest element on your page (usually a hero image or headline) takes more than 4 seconds, you're in the "Poor" category.

Common causes of slow LCP: oversized images, slow server response times, render-blocking JavaScript that delays everything else from loading.

INP: Interaction to Next Paint This replaced the old FID metric in 2024. It measures how quickly your page responds when someone taps or clicks. Google wants this under 200 milliseconds. Anything above 500 milliseconds is "Poor."

Common causes of bad INP: heavy JavaScript running on the main thread, too many third-party scripts (ads, chat widgets, social embeds), unoptimized event listeners.

CLS: Cumulative Layout Shift This measures how much your page jumps around while loading. You've experienced bad CLS when you're about to click a button and an ad loads above it, shifting everything down so you click the wrong thing. Google wants CLS below 0.1.

Common causes of bad CLS: images without declared dimensions, ads that inject from the top, web fonts that swap in after text is already rendered.

You can check your Core Web Vitals free in Google Search Console under the Page Experience report, or by pasting any URL into Google's PageSpeed Insights tool at pagespeed.web.dev.

How to Actually Make Your Pages Fast in 2026

This is the practical section. These are the specific moves that improve mobile speed without AMP.

Fix 1: Compress and Properly Size Every Image

Images are the single biggest cause of slow pages. A 4MB photo hero image will destroy your LCP score no matter how well you've optimized everything else.

Three steps:

1. Convert all images to WebP format. WebP files are typically 25 to 35 percent smaller than JPEGs at the same visual quality.

2. Set explicit width and height attributes on every image. This prevents layout shift as images load.

3. Use lazy loading for images below the fold. Add the attribute loading="lazy" to any image the user can't see on first load. This defers those images until the user scrolls down.

For WordPress users, plugins like ShortPixel or Smush handle conversion automatically. For non-WordPress sites, tools like Squoosh let you batch-convert images in a browser.

Fix 2: Minimize JavaScript

<cite index="129-1">AMP's original premise was "the web is too slow because developers use too much JavaScript." Google's solution was to ban developer-written JavaScript entirely.</cite> That was too extreme. But the underlying problem was real.

Every JavaScript file your page loads blocks rendering until it's downloaded and processed. Every third-party script (analytics, chat, social embeds, advertising tags) adds to that pile.

Practical steps:

• Audit your scripts. Open Chrome DevTools, go to the Network tab, and filter by JS. Count how many scripts you're loading. Anything above 20 is a warning sign.

• Defer non-critical scripts. Add defer or async attributes to scripts that don't need to run on initial page load.

• Remove what you don't use. That Facebook pixel from 2018 for a campaign you ran once? Gone.

• Replace heavy libraries with lighter ones. jQuery for simple tasks can often be replaced with vanilla JavaScript.

Fix 3: Use a Content Delivery Network (CDN)

A CDN stores copies of your site's files on servers around the world. When someone in Australia visits your site hosted in New York, a CDN delivers the files from a server in Sydney instead. Faster delivery, lower latency, better LCP.

Cloudflare has a free tier that works for most small and medium sites. Fastly and Amazon CloudFront are solid options for larger traffic volumes. If you're on a managed WordPress host like WPEngine or Kinsta, CDN is usually included.

Fix 4: Reduce Server Response Time

Before a single byte of your page loads, the browser has to connect to your server and receive the first response. Google calls this TTFB: Time to First Byte. If it's above 800 milliseconds, your LCP will struggle no matter what else you optimize.

Two main causes: slow hosting and an uncached server-rendered page.

Solutions:

• Upgrade to faster hosting. Shared hosting on cheap plans is often the culprit. A VPS or managed cloud host makes a measurable difference.

• Enable server-side caching. On WordPress, plugins like WP Rocket or W3 Total Cache serve pre-built HTML instead of rebuilding the page on every request. This alone can cut TTFB from 2 seconds to under 200 milliseconds.

Fix 5: Load Fonts Smarter

Web fonts are a common cause of CLS and perceived slow loading. When the page loads with a system font first and then swaps to your custom font, everything shifts.

Two fixes:

• Add font-display: swap in your CSS. This tells the browser to show text immediately with a fallback font and swap the custom font in when it loads, rather than showing nothing.

• Preload your most important font file. Add a preload link tag in your HTML header for the font used in your main headline. This fetches it early so the swap happens before the user notices.

Fix 6: Test Mobile Speed on Real Devices

Developers test on fast laptops with fast internet connections. Your users are on midrange phones with variable connections.

Google's PageSpeed Insights simulates a slow 4G connection and a midrange mobile device. Your score there is what matters, not your score on a $2,000 MacBook Pro.

Test at pagespeed.web.dev. Aim for 90 or above on mobile. Below 50 means real users are experiencing real frustration.

How to Use the Google AMP Test Tool

Even though AMP has declined in importance, the AMP Test at search.google.com/test/amp is still useful if you have existing AMP pages.

Here's what it does and when to use it.

What it checks:

• Is your page valid AMP HTML?

• Are there any AMP-specific errors blocking proper rendering?

• Does the page pass the structured data requirements for rich results?

How to use it:

1. Go to search.google.com/test/amp

2. Paste any URL or paste raw AMP HTML code

3. Click Test

4. Read the results: green checkmarks mean the page is valid, red errors need fixing

When it's still useful: If you're running a news or publishing site with existing AMP pages and you want to make sure they render correctly before removing them or migrating to standard pages. Also useful for diagnosing why an AMP URL might not be getting the rich results you expected in search.

When to ignore it: If you're building new content and not using AMP at all, this tool has nothing useful to tell you. Focus on PageSpeed Insights and Google Search Console's Core Web Vitals report instead.

What Reddit Developers and SEOs Say About AMP

The developer and SEO communities dropped AMP fast once the ranking benefit disappeared. Here's what they actually say.

"Nobody serious is starting new projects with AMP in 2026." This is near-universal in technical SEO and web development communities. The maintenance burden, design restrictions, and lack of any ranking benefit make it a hard sell to any client or stakeholder.

"The real lesson from AMP is how much bloated JavaScript was hurting us." Developers who went through the AMP migration often say the biggest benefit wasn't AMP itself. It was being forced to audit every script and every image on their site. The discipline of optimization matters more than the framework.

"Core Web Vitals are the new AMP requirement." The attention that publishers used to give to AMP compliance has shifted entirely to Core Web Vitals. Same goal, different tool, better measurement.

"If you still have AMP, remove it in a planned migration, not a panic." The consensus is clear: don't keep AMP, but don't rush the removal either. Set up 301 redirects from all AMP URLs to their canonical equivalents. Submit the updated sitemap. Monitor Google Search Console for any indexing changes after the migration.

"PageSpeed Insights is your new AMP Test." When people used to check their AMP Test score obsessively, they now check PageSpeed Insights obsessively. Same energy, much better signal.

Structured Data: The Mobile SEO Move Most Sites Miss

While everyone was focused on AMP, a quieter mobile SEO win was sitting right there: structured data.

Structured data is code you add to your pages that tells Google exactly what kind of content you have. A recipe. A product. A review. An article. An FAQ. Google reads this code and uses it to display rich results in search, things like star ratings, prices, recipe cards, and expandable FAQ sections.

These rich results take up more space on the search page, especially on mobile. They stand out. They get clicked more.

And unlike AMP, structured data works on any standard HTML page with no framework required.

The most useful types for most sites:

Article schema: tells Google your page is an article with a headline, author, and publication date. Required for eligibility in some Top Stories formats.

FAQ schema: turns your frequently asked questions into expandable results directly in search. A page with three FAQ schema questions can take up three times the vertical space of a normal result on mobile.

Product schema: shows price, availability, and review stars directly in the results. For ecommerce pages, this is the difference between a result that looks like a link and one that looks like a listing.

How-to schema: displays numbered steps in search results for instructional content. High click-through rates because users can preview the content before clicking.

How to add it: Google's Rich Results Test at search.google.com/test/rich-results lets you paste a URL and see what rich results your page is eligible for. If you use WordPress, plugins like Rank Math or Schema Pro handle the code automatically. For custom sites, Google's Structured Data Markup Helper walks you through the process step by step.

This is the mobile visibility move that matters right now, more than AMP ever did in its final years.

Removing AMP: The Safe Migration Checklist

If you have AMP pages and want to move off them cleanly, follow this order.

Step 1: Remove the rel="amphtml" link tag from your main pages. This tells Google's crawler to stop looking for an AMP version.

Step 2: Set up 301 redirects from every AMP URL to its canonical. AMP URLs typically end in /amp/ or have ?amp=1 appended. Every one of these needs a permanent redirect to the standard page. Missing even a few can cause crawl errors in Search Console.

Step 3: Add noindex tags to AMP pages temporarily if you can't set up redirects immediately. This prevents Google from indexing duplicate content while you sort out the redirects.

Step 4: Submit an updated sitemap in Google Search Console that includes only the canonical (non-AMP) URLs.

Step 5: Monitor Search Console for 30 days after migration. Check the Coverage report for new errors. Check the Performance report for any significant click or impression drops. Most well-executed AMP removals show no negative impact. Some show improvements.

Step 6: Use the URL Inspection tool to verify that the canonical versions of your most important pages are indexed and showing no errors.

The whole migration can be done in a weekend for most sites. Large publishers with tens of thousands of AMP pages should allow more time for redirect setup and testing.

The Bottom Line

AMP was a real solution to a real problem in 2015. In 2026, that problem has better solutions.

<cite index="127-1">The path AMP promised: fast mobile pages, fewer layout shifts, better Core Web Vitals, is achievable with standard HTML plus good engineering.</cite> You don't need a separate framework. You don't need a different URL. You don't need to give up design freedom, analytics, or advertising flexibility.

What you do need is to take mobile speed seriously. Check your Core Web Vitals in Google Search Console. Fix your images. Trim your JavaScript. Use a CDN. Cache your pages properly.

The lightning bolt is gone. But the need for fast, clean, mobile-friendly pages is not.

Build something fast. Then build something good. In 2026 those are the same goal.