AMP (Accelerated Mobile Pages)

AMP was the mobile-speed story of 2016–2020. Then Google's own Page Experience update stripped it of its privileges. Understanding what AMP still gives you — and what it no longer gives you — is the difference between running lean HTML and maintaining a parallel codebase for nothing.

What is AMP?

AMP is a framework composed of three parts. AMP HTML is a subset of regular HTML that bans custom JavaScript and locks down most tags. AMP JS is a Google-provided library that manages resource loading and enforces the speed rules. AMP Cache is a Google-hosted CDN that pre-renders AMP pages so they appear almost instantly when clicked from Search.

The point of the framework is predictable performance. Because every AMP page follows the same rules, Google can pre-cache and pre-render it safely without triggering unexpected behavior. That is why AMP pages, at their peak, loaded in under a second even on slow mobile networks.

Why AMP still matters

Even in a post-privileged world, AMP shows up in three places you should understand:

1. Legacy publisher sites. News outlets, magazines, and long-tail blogs built on AMP in 2017–2020 still run it. If you inherit one of these properties, you inherit AMP.
2. Guaranteed Core Web Vitals compliance. Because AMP forces async loading and blocks render-blocking scripts, most AMP pages pass CWV automatically. For teams that cannot fix a slow theme, AMP is a shortcut.
3. Email AMP. Gmail supports AMP for Email — interactive components inside inbox previews. This is a separate spec but shares the framework.

How AMP actually works

The mechanism is straightforward. Every AMP page has a companion "canonical" HTML page. The canonical points to the AMP version with a rel="amphtml" link tag. When a user clicks an AMP result in Search, Google serves the pre-cached AMP HTML from its CDN instead of hitting your origin server.

Restricted HTML

You cannot use <script> tags (except the AMP runtime), external CSS, or many standard tags. Images use <amp-img> with fixed width and height. Iframes use <amp-iframe>. This lets the framework compute layout before any resource loads.

Async everything

All resources are loaded asynchronously. The framework knows the size of every element up front, so it never has to reflow. This is why AMP feels instant — nothing blocks the paint.

AMP vs modern responsive HTML

Real AMP examples

1. A news publisher on legacy AMP

A regional newspaper built AMP versions of every article in 2018 to win Top Stories placement. In 2026 the AMP layer still exists, still passes Core Web Vitals, and the editors leave it alone. Rebuilding responsive templates would cost more than maintaining the existing AMP pipeline.

2. A WordPress blog using the official AMP plugin

A niche blog runs the AMP plugin in "transitional" mode. Every post has both a canonical URL and an /amp/ version. Analytics show mobile bounce rates dropped by 12 points after AMP was added — the vast majority of the gain came from faster paint, not from Google preference.

3. A new site skipping AMP entirely

A SaaS company launching in 2026 skips AMP. They use static HTML, defer non-critical JS, compress images to WebP, and hit a Largest Contentful Paint of 1.4 seconds. Their Search Console reports full Page Experience credit without a line of AMP code.

AMP vs Core Web Vitals — which to invest in

Both aim at the same outcome (fast mobile pages) but through different mechanics. Here is how to choose.

6 best practices if you still run AMP

1. Keep AMP and canonical in sync. If the content diverges between the two versions, Google may pick either one. Publish the same body, headline, and metadata on both.
2. Use official AMP components. Third-party AMP components can break during framework updates. Stick to the components in the official AMP library.
3. Validate every page. Google's AMP Test tool flags errors that make the page ineligible. Any invalid page will not receive AMP treatment.
4. Track amp-analytics correctly. Native GA snippets do not run inside AMP. Use the amp-analytics component with the correct account ID.
5. Serve AMP over HTTPS only. AMP pages served over HTTP will not be cached by Google. Enforce TLS on both the canonical and the AMP twin.
6. Have a retirement plan. If you plan to sunset AMP, 301 the /amp/ URLs to the canonicals and remove the amphtml link tag before you disable the framework.

Common AMP mistakes to avoid

• Building new AMP pages in 2026. Unless you have a specific reason (Gmail AMP, publisher legacy), skip it and invest in Core Web Vitals instead.
• Removing the canonical link. Without rel="canonical" on the AMP page, Google may index both versions and split ranking signals.
• Ignoring the AMP validation report. A single invalid tag disqualifies the page from AMP caching.
• Adding custom JavaScript. The framework rejects it — the page silently falls out of AMP status.
• Sunsetting AMP without redirects. Retired /amp/ URLs that return 404 waste crawl budget and lose historical link equity.

Frequently asked questions

Related glossary terms

Sources

Akshay VR

Marketing Head · theStacc

Akshay leads editorial and content operations at theStacc. He writes about the technical SEO decisions that compound — including which mobile-speed frameworks are worth investing in and which ones to quietly retire.

LinkedIn Author page More terms by Akshay