What is AMP?

The acronym stands for Accelerated Mobile Pages. The project started in October 2015, when news pages took several seconds to open on mobile and some platforms were offering closed formats as an alternative to the browser.

It is not a new language. An AMP page is still HTML, but HTML with strict rules. Custom JavaScript is forbidden, the CSS is inline and subject to a size limit, and images, videos or ads are declared through the framework's own components instead of the usual tags. A validator checks whether the document follows those rules, and only valid pages get its benefits.

Three things that tend to be lumped under the same word are worth separating. The first is the format itself, an open standard anyone can serve from their own server. The second is the Google cache, the infrastructure that copies and delivers valid AMP pages from a domain of its own. The third is the preferential treatment Search gave those pages, which for years was the real reason publishers adopted the format. The three have taken different paths, which is why the question about AMP no longer has a single answer.

AMP's speed does not come from a compression trick but from what the format forbids. With no third-party scripts running during load, the browser does not wait for unknown code before painting the page. Image and ad dimensions are declared up front, so the layout does not shift while resources arrive.

On top of that design came the cache. When an AMP page is valid, Google's infrastructure can copy it, optimise it and deliver it from cdn.ampproject.org, and preload it as well: while the user scans the results, the document has already been downloaded. That is where the sense of instant opening that made the format famous came from, and also the addresses shaped like google.com/amp that replaced the publisher's domain in the browser bar. Current Search documentation states that the URL of your AMP page is visible to the user when they open it, as with any other result.

The price of that speed is the set of restrictions. Forms, paywalls, personalisation and much of the ad stack need specific components or workarounds. Keeping an AMP version alongside the normal one also means two templates, with the risk that a change lands in only one of them. That cost weighs more today than it did ten years ago, because well-built HTML reaches similar load figures with lazy loading, resource priorities and a CDN.

In April 2021 Google announced that using the AMP format was no longer a requirement and that any page would be eligible for the Top Stories carousel. The change arrived with the page experience update, rolled out between mid-June and the end of August 2021, and in the same move the lightning icon that marked AMP results disappeared. With it went the argument that sustained adoption of the format among publishers.

Current Google Search Central documentation is explicit on the other point: AMP pages are indexed just like any other page and the same standard applies, regardless of the technology used to build them. The format brings no ranking advantage in itself.

As software, the project is still running. It is hosted by the OpenJS Foundation and its repository has published releases throughout 2026, the latest stable one dated 15 July 2026. What changed is not the maintenance but the incentive. For a new site, the reason that justified adopting AMP no longer exists. For a site that already uses it and works, there is no shutdown date forcing anyone to rush either.

• Measure before you touch anything. Export from Search Console and from your analytics the impressions, clicks and conversions of your AMP URLs over the past twelve months. Without that baseline you will not be able to show afterwards whether the change helped or hurt.
• Check which version Google indexes. If the normal page is the canonical one and AMP is only the variant linked via rel=amphtml, removing it is a cleanup. If your AMP pages are self-canonical or the only version that exists, you are facing a migration.
• Compare the real performance of both versions with mobile field data (LCP, INP and CLS). If your normal HTML already meets the thresholds, the technical argument for keeping AMP disappears.
• If you decide to retire it, redirect every AMP URL to its equivalent with a one-to-one 301, never to the home page, remove the rel=amphtml tag and update the sitemap. Keep those redirects permanently in place, because external links point to the AMP variant.
• Do it in phases. Retire one section first, wait four to six weeks, watch coverage in Search Console and compare against the baseline you measured. If nothing gets worse, carry on with the rest.
• If you decide to keep it, treat it as production code. Validate the pages regularly, check that the content does not drift from the canonical version and verify that cookie consent and analytics behave the same in both.

• Deleting AMP URLs without redirects. They turn into 404 errors and drag along the external links that pointed at that variant.
• Redirecting every AMP page to the home page. Google tends to treat those redirects as soft 404s, and a user coming from a specific article lands on a page they did not ask for.
• Leaving the rel=amphtml tag pointing at pages already retired. The result is warnings in Search Console and conflicting signals about which version to crawl.
• Assuming AMP still grants a ranking advantage and postponing performance work on the main version for that reason, when that is the version being evaluated.
• Publishing changes in only one of the two versions. Over time you end up with two different texts, with outdated prices or legal notices in the forgotten variant.