AMP, short for Accelerated Mobile Pages, is a stripped-down HTML framework Google introduced to make mobile web pages load almost instantly. It is essentially a constrained subset of HTML plus a mandatory JavaScript library and an aggressive caching layer.
I am writing this in 2026, and I will not bury the verdict. For the overwhelming majority of websites, AMP is no longer worth implementing. If you already have it, you should seriously consider whether it still earns its place.
What AMP actually is
Take a normal HTML page. Now imagine Google handing you a rulebook that says: you can only use these specific tags, you cannot write your own JavaScript, all your CSS must live inline and weigh under 75 kilobytes. Then imagine Google offering to host a cached copy of your page on its own servers and pre-load it before the user clicks. That’s AMP.
The trade: give up flexibility in exchange for predictable, very fast performance on mobile. For a while that trade was worth it because Google effectively forced publishers into it. That changed.
From mandatory to mostly abandoned
Google launched AMP in October 2015. What made it take off was that Google tied AMP to the Top Stories carousel. For years, if you were a news publisher and you wanted to show up in that carousel, you needed AMP. Every major newsroom built an AMP pipeline.
Then in June 2021, Google rolled out the Page Experience update and removed AMP as a requirement for Top Stories. Any page meeting Core Web Vitals became eligible. Overnight, AMP went from necessary evil to optional choice. Vox Media dropped AMP. BuzzFeed dropped AMP.
How AMP works
- Restricted HTML. AMP defines its own tag set (
<amp-img>,<amp-iframe>, etc.). - Mandatory AMP JavaScript library. No custom JS allowed.
- Tightly constrained CSS. Inline only, under 75kb.
- Server-side caching via the AMP Cache. Pages served pre-rendered from Google.
Real benefits when AMP made sense
- Fast page loads on weak connections.
- Pre-rendering in Google search.
- Predictable performance.
- Top Stories visibility before June 2021.
The drawbacks that piled up
- The URL problem. AMP pages were served from a Google URL. Users saw a Google address and had no idea they were reading your site.
- Limited design flexibility. Anything custom was painful.
- Reduced functionality. Forms and interactive elements were awkward.
- Maintenance burden. Two versions of every page.
- Analytics headaches. Sessions split between AMP cache and canonical domain.
- Branding loss. Readers consumed content without registering your brand.
- Locked into Google’s framework. When Google changed the rules in 2021, the value changed with it.
Where AMP stands in 2026
AMP is still technically supported. Google still serves AMP pages from its cache. What has changed is the strategic position. Google no longer requires AMP for Top Stories, rich results, or any meaningful search feature.
Narrow cases where AMP might still make sense
- News publishers with massive mobile traffic in emerging markets.
- Sites that already have AMP working with no operational pain.
- AMP for Email (a separate technology) for transactional/interactive emails.
- Certain ad formats and partner integrations.
Notice what is not on that list: small business websites, e-commerce stores, SaaS marketing sites, B2B blogs, local service pages. For those, AMP is overhead without payoff.
The better alternative: optimize your real pages
A well-built canonical page can hit the same performance bar as an AMP page without any of the trade-offs. Core Web Vitals gives you three targets: LCP under 2.5s, INP under 200ms, CLS below 0.1.
- Serve WebP or AVIF with proper dimensions.
- Lazy-load below-the-fold images and iframes.
- Minimize render-blocking JavaScript.
- Use a CDN.
- Audit third-party scripts.
- Cache aggressively.
- Use priority hints and preload tags for above-the-fold resources.
If you already have AMP: should you remove it?
Probably yes, but do it carefully. Pull your analytics and look at AMP-specific traffic. In most cases you’ll find it’s negligible or fully replaceable by your canonical pages.
- Inventory your AMP URLs.
- Set up 301 redirects from each AMP URL to its canonical.
- Strip the
<link rel="amphtml">tags from canonical pages. - Update your sitemaps to only canonical URLs.
- Resubmit to Search Console and monitor.
- Clean up analytics.
Most sites that remove AMP report zero negative impact, sometimes positive (analytics get cleaner, design improves).
Common questions
Does Google penalize sites without AMP? No.
Will I lose my Top Stories spot if I remove AMP? Almost certainly not, if your canonical pages meet Core Web Vitals.
What about Google Discover? Does not require AMP either.
Is AMP the same as a PWA? No. AMP is a performance-focused HTML framework; PWA is a broader pattern for app-like web experiences.
What about AMP for Email? Separate technology, still active, supported by Gmail.
The verdict
For almost every site reading this in 2026, AMP is no longer worth implementing. The original deal, give up flexibility, get speed and Top Stories access, no longer holds. The speed is achievable without AMP. The Top Stories access is no longer gated by AMP.
If you currently have AMP running quietly without pain, you don’t need to drop everything and rip it out. Audit it and remove on a sensible timeline if the analysis says it’s not earning its place. If you don’t have AMP, skip it and put that engineering time into Core Web Vitals and content quality.
Build fast pages. Own your URLs. Keep your analytics clean.