AMP (Accelerated Mobile Pages)
A constrained HTML subset built to make mobile pages load fast, and a case study in what happens when a format's distribution advantage is withdrawn.
Karl-Gustav Kallasmaa, Founder & CEOLast updated AMP, for Accelerated Mobile Pages, is a constrained subset of HTML that trades away arbitrary author-supplied JavaScript and unsized layout in exchange for predictable load performance, served through a runtime and, optionally, a cache. It is best understood today as a design that solved a real problem and then lost the distribution advantage that made adopting it worthwhile.
The mechanism
Validity is the whole idea: AMP is not a style guide, it is a format a validator can prove. The AMP HTML specification requires a fixed set of markup in every document:
<!doctype html>, and an<html ⚡>or<html amp>root element- explicit
<head>and<body>tags, which ordinary HTML makes optional - a
<link rel="canonical">pointing at the regular HTML version, or at itself <meta charset="utf-8">as the first child of<head><meta name="viewport" content="width=device-width">- the AMP runtime,
<script async src="https://cdn.ampproject.org/v0.js"></script> - the AMP boilerplate style blocks, in
head > style[amp-boilerplate]andnoscript > style[amp-boilerplate]
Author JavaScript is disallowed; interactive behaviour comes from a vetted component library instead. Resources declare their dimensions so layout can be computed before they arrive, which is why an AMP page does not shift under the reader. Because validity is machine-checkable, a third party can verify a document is fast-by-construction without loading it — and that verifiability, not the speed itself, is what made caching and pre-rendering possible.
Why the calculation changed
The reason publishers adopted AMP was rarely the format. It was placement: a fast page was worth building in a restricted dialect if the restricted dialect was the entry ticket to a surface.
That is no longer the arrangement. Google's current documentation states that "Google Search indexes AMP pages just like other web pages, and applies the same standard to all pages, regardless of the technology used to build the page." There is no AMP requirement for any Search feature. What replaced it is direct measurement: Core Web Vitals assesses a page on its own numbers — LCP within 2.5 seconds, INP at 200 milliseconds or less, CLS at 0.1 or less, at the 75th percentile of loads — and an ordinary HTML page that meets them is treated the same as an AMP page that does.
The general lesson outlives the format. A technology adopted for a distribution privilege carries the risk that the privilege is withdrawn while the maintenance cost stays. The underlying goal — a page that arrives quickly and does not move — survived; the specific bargain did not.
Failure modes
Two URLs for one document. An AMP page and a canonical page are two addresses for the same content, and every consumer downstream has to reconcile them. Google's guidance is that "users must be able to experience the same content and complete the same actions on AMP pages as on the corresponding canonical pages, where possible," and that AMP URLs should be recognisably related to the canonical host rather than unrelated.
Content drift. The AMP variant is usually the one that stops being updated. It then keeps serving a superseded version of a claim to whatever fetches it, which is a correctness problem, not a performance one.
Structured data divergence. Markup added to the canonical page and not to the AMP page — or the reverse — leaves two documents describing the same thing differently. See schema markup.
Assuming validity means quality. AMP proves a document loads predictably. It proves nothing about whether the document answers the question, and a fast page with nothing in it is not a candidate for anything.
Treating AMP as an AI-visibility tactic. Agents that fetch pages to answer with care about whether a page returns quickly and renders its content server-side. Those are properties, not formats. An AMP duplicate adds an addressing problem without adding a fact worth quoting, and the same performance is reachable in plain HTML. See crawling and indexing.
If you still run AMP
Decide whether it is earning anything specific — a measured performance gap against your canonical template, or a downstream consumer that requires it. If it is not, the retirement path is to serve the canonical page, keep the URLs redirecting, and verify the canonical template against the Core Web Vitals thresholds directly rather than inheriting a guarantee from the format. If it is, treat the two variants as one document with two addresses: same content, same structured data, same publication dates, updated in the same change.
Terms related to AMP (Accelerated Mobile Pages)
Google's three published field metrics for loading, responsiveness and visual stability, with the exact thresholds and the percentile they are judged at.
The two separate stages that decide whether a page can be retrieved at all, and the reason a serving rule on a blocked page is never read.
A machine-readable list of the URLs you want discovered, bounded by the protocol at 50,000 URLs and 50MB per file, and a hint rather than an instruction.
The Schema.org vocabulary and the JSON-LD you embed with it, what it is genuinely good for, and the limits of what it can make happen.