Skip to content

Home · Blog · Google AMP pages: what they were and whether you nee…

Send a request

New format

Google AMP pages: what they were and whether you need them now

AMP (Accelerated Mobile Pages) is an open format of lightweight pages that Google pushed from 2015: limited HTML/JS, fast paint, and often delivery from the search cache.

By the mid-2020s AMP is no longer a required mobile SEO layer: the carousel and SERP privileges are gone, and speed is decided by Core Web Vitals on your own site. Below: how the format worked, what helped and what hurt, and when it still makes sense. Step-by-step “install a plugin and rank” guides are outdated.

Share
Telegram

How AMP worked

A page was built under AMP HTML rules: allowed components instead of arbitrary scripts, markup validation. The goal — predictable fast load on a phone.

Users could open AMP on your domain (often an `/amp` suffix or `?amp`) or see a cached copy in Google’s infrastructure. In the second case some metrics and the feel of the site differed from a full visit to your host.

What was usually stripped:

  • heavy arbitrary JavaScript
  • complex widgets and some forms
  • heavy graphics and effects
  • some ad and social blocks without special components

Yandex Turbo pages

Pros and cons of the AMP era

The upside was speed on weak mobile networks and a shared light template for media. The downsides: poorer UX, harder analytics and conversions, canonical confusion risk, dependence on platform rules and cache.

We don’t reuse old PageSpeed “was 61 — became 87” benchmarks from 2019–2020 cases: tools and metric weights changed. Check current reports on your URLs.

Typical rollout problems:

  • low conversion on the stripped page
  • harder goals and events in analytics
  • duplicates/canonical issues from bad setup
  • maintaining two templates instead of one good mobile

Do you need AMP now

For most commercial sites in 2026 the sensible answer is no as a required layer. Invest in responsive design, compression, fonts, images, cache/CDN, and Core Web Vitals on canonical URLs.

AMP only makes sense if you have a narrow content case, format support already in the stack, and clear analytics. We don’t start new projects for an AMP checkbox.

Where to put the effort:

  • mobile layout and readability
  • LCP/INP/CLS speed
  • clear CTAs on the full site
  • one template without a parallel light universe

Responsive site Mobile search

Practice

Before deciding on AMP

Your own mobile beats a 2015 format.

0 / 6 done

FAQ

Is AMP still required for mobile SEO?

No. First a fast responsive site. AMP is a narrow/historical case — not a substitute for real mobile UX.

How did AMP differ from a normal page?

A strict set of tags and components, little arbitrary JS, stripped layout. Google could serve a copy from its cache — faster on a weak connection, but part of the session wasn’t on your host.

Is AMP the same as Yandex Turbo?

The idea is similar (a light mobile copy), ecosystems differ. Turbo in search was also wound down — the bet is on your own site.

Should I urgently delete old /amp URLs?

Not always. Check that canonical and analytics point to the main version, there’s no index confusion or dead redirects. What matters is main mobile quality.

Does AMP give a ranking boost?

There’s no direct “AMP points” as a required factor. Speed and behavior matter — you cover them on regular URLs.

Still maintaining AMP “for SEO” while Core Web Vitals on the main site lag?

We’ll focus speed and mobile UX on canonical URLs — AMP only if you already have a clear content case.

Discuss the task