How AMP works
AMP, short for Accelerated Mobile Pages, is a restricted version of HTML. A valid AMP page may only use an approved set of components, cannot run its own JavaScript, and must declare image dimensions in advance. Those restrictions make the page predictable, and a predictable page can be checked, cached and served ahead of time.
That was the real mechanism. Because AMP pages were guaranteed to behave, Google could store copies on its own infrastructure and hand them to a phone the instant a headline was tapped, before the visitor had travelled to the publisher’s server at all. Sites usually kept two versions of every article, the ordinary page and its AMP twin, linked to each other so search engines knew which was canonical.
Why AMP mattered, and why it matters less now
For a period, publishers had little choice: the Top Stories carousel on mobile was reserved for AMP pages, and news sites that wanted to appear there built AMP versions whether or not they wanted the format. That requirement was removed. Any sufficiently fast page can now appear there, judged on the same page experience signals as everything else.
Once the exclusive placement disappeared, the arithmetic collapsed. AMP had always meant a second version of every article to build, style, test, track and keep in step with the first. Publishers who could reach the same placement with one well-built page did exactly that, and many retired AMP entirely. Today it is a legacy format rather than a recommendation, and for an ordinary business website — a service page, a shop, a clinic — it was never appropriate in the first place.
Where AMP goes wrong
The duplication is the root of most of it. Two versions of every page means two chances for the canonical link to break, two templates for a design change to miss, and two sets of tracking that rarely agree, so analytics on AMP traffic is often quietly wrong.
The restrictions bite too. Forms, chat widgets, custom interactions and many advertising and consent tools either need an AMP-specific replacement or simply cannot run, so the stripped page converts worse than the page it replaced. And a fast page arrived at from a cache is a poor excuse for a slow site: the moment a visitor clicks through to any other page, they meet the real one.
What to do about it
If you do not have AMP, do not add it. Put the same effort into making the ordinary page fast, which is what a page speed review is for, and you get the benefit on every page rather than on the article twin.
If you inherited AMP, decide deliberately whether it still earns its keep. Check whether those URLs bring any real traffic before touching anything. When you retire them, redirect every AMP URL to its standard page rather than deleting it, remove the links that pointed at it, and confirm the standard version is indexed and fast on a phone. Removing AMP is a small migration, and treating it as one avoids losing pages that were ranking perfectly well.