Definition
AMP (Accelerated Mobile Pages) is an open-source web framework for building fast-loading pages from a restricted subset of HTML, a limited CSS budget and a set of prebuilt components that replace custom JavaScript. Google launched it in 2015 to speed up mobile news pages. The project is now governed by the OpenJS Foundation and still ships weekly runtime releases, but its role in search has shrunk to almost nothing.
AMP gets its speed from constraints. Pages cannot run arbitrary third-party scripts, every image and embed declares its dimensions to prevent layout shifts, author CSS is capped and inlined, and the AMP runtime controls resource loading. For years Google added two advantages on top: AMP was required to appear in the Top Stories carousel, and Google served AMP pages instantly from its own AMP Cache inside an AMP viewer.
Both advantages are gone. Google dropped the AMP requirement for Top Stories with the page experience update in 2021 and moved to Core Web Vitals as the shared performance standard for all pages. Then, on July 1, 2026, Google stopped serving AMP results from the AMP Cache. Clicks on AMP results now go straight to the publisher's own AMP URL, and Google removed the AMP viewer, AMP Cache and signed exchanges from its documentation. Google's AMP guidance now says Search 'indexes AMP pages just like other web pages, and applies the same standard to all pages, regardless of the technology used.' Google told Search Engine Land the change does not affect how AMP content ranks.
What remains is an implementation choice with real costs. Most sites that use AMP run it as a paired version next to a canonical HTML page, which doubles templates and requires correct rel='amphtml' and canonical URL links in both directions. Analytics, personalization and interactive features have to be rebuilt with AMP components. Frameworks are moving away too: Next.js removed AMP support in version 16.
For AI search, AMP neither helps nor hurts on its own. AI crawlers such as OAI-SearchBot, Claude-SearchBot and PerplexityBot fetch whatever URL they find, and most read the HTML without running JavaScript the way a browser does. AMP pages are server-rendered, so their text is visible to these bots. The risk is duplication: if the AMP and canonical versions drift apart, or canonical tags are missing, a bot may index or cite the thinner AMP copy. If you keep AMP, make sure both versions carry the same content and schema markup, and that the canonical points to the main page.
For new sites, the current recommendation is to skip AMP and meet Core Web Vitals on standard pages: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1, measured on real users. Server-side rendering, modern image formats, careful third-party script loading and a CDN get most sites there. Sites still running AMP can retire it gradually by redirecting AMP URLs to their canonical pages once those pages pass the same thresholds, then confirming in Google Search Console that the AMP URLs drop out cleanly.
Examples of AMP (Accelerated Mobile Pages)
- A regional news publisher that kept AMP for Top Stories traffic sees no ranking change after Google's July 2026 cache switch, but its analytics start attributing AMP visits to its own domain instead of a google.com cache URL.
- An ecommerce brand evaluating AMP for product pages decides against it after finding its server-rendered Next.js templates already pass all three Core Web Vitals thresholds on mobile.
- A blog finds that ChatGPT cites its /amp/ URLs for several guides because the canonical tags on the AMP versions point to themselves, and fixes the tags so citations go to the main articles.
- A media group retires AMP across 40,000 articles with 301 redirects to canonical URLs, then watches the Page indexing report in Search Console until the AMP URLs are reported as redirected.
