What Is AMP (Accelerated Mobile Pages)? SEO Glossary

Learn what AMP means in SEO, why it matters, and whether you should implement it for better search rankings.

AMP, or Accelerated Mobile Pages, is an open-source HTML framework originally created by Google to make web pages load almost instantly on mobile devices. AMP pages use a restricted subset of HTML, a streamlined CSS approach, and a custom JavaScript library that controls how pages render. The result is a stripped-down version of your web page that loads significantly faster than a standard mobile page.

Google launched AMP in 2015, and it quickly became a major consideration in mobile SEO. However, the landscape has shifted substantially since then. AMP is no longer required for Top Stories or other Google Search features, and its role in modern SEO is much more nuanced than it once was.

Why AMP Matters for SEO

AMP's original appeal was straightforward: Google gave AMP pages preferential treatment in search results. AMP content appeared in a dedicated carousel at the top of mobile search results, particularly for news content. For publishers, being in that carousel meant massive visibility and traffic.

In 2021, Google removed the AMP requirement for Top Stories and the news carousel. As Google Search Central stated when it detailed the page experience update, "the Top Stories carousel feature on Google Search will be updated to include all news content," meaning that any page that meets the Google News policies became eligible, with or without AMP. Google now prioritizes pages with strong page experience whether they are built with AMP or any other web technology. The change rolled out starting in mid-June 2021. This fundamentally changed the calculus around AMP adoption.

That said, AMP still matters in certain contexts. Its strict constraints make fast loads the default, which helps a page clear the Core Web Vitals "good" thresholds that Google measures at the 75th percentile of real visits, namely Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1. Note that Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, so any older guidance you find that lists FID is out of date. For sites that struggle with page performance due to technical debt, heavy ad implementations, or complex CMS platforms, AMP can be a shortcut to fast mobile experiences.

The speed advantage of AMP translates to real user experience benefits. Faster pages have lower bounce rates, higher engagement, and better conversion rates. Even without direct ranking preferences, the performance improvements from AMP can indirectly improve your SEO through better user signals.

How AMP Works

AMP achieves its speed through strict technical constraints:

AMP HTML restricts which HTML tags you can use and requires specific AMP components for common elements. Images use <amp-img> instead of <img>, videos use <amp-video>, and embeds use specific AMP components. This allows the AMP runtime to control exactly how and when elements load.

AMP CSS caps the author stylesheet and inline styles together at a hard 75,000 bytes per page, and it is a validation error to exceed it. All custom CSS lives in a single <style amp-custom> tag in the document head, and external stylesheets are not allowed. This forces lightweight styling and eliminates render-blocking CSS requests.

AMP JavaScript prohibits author-written JavaScript. As the AMP HTML specification puts it, AMP "does not allow author written JavaScript beyond what is provided through the custom elements" in order to reach its performance goals. All interactivity must come from AMP's own component library, loaded through the mandatory runtime script <script async src="https://cdn.ampproject.org/v0.js"></script>. This eliminates the biggest source of page slowness, which is arbitrary JavaScript execution blocking the main thread.

Google AMP Cache pre-fetches and caches AMP pages on Google's servers. When a user clicks an AMP result in Google Search, the page loads from Google's CDN rather than your server, eliminating server response time entirely.

The combination of these constraints means AMP pages are predictably fast. The AMP validator ensures every AMP page meets the framework's requirements, so there is no variation in baseline performance.

Best Practices for AMP

Evaluate whether AMP is right for your site. If you can achieve good Core Web Vitals scores without AMP, you may not need it. AMP adds development and maintenance complexity. Weigh the speed benefits against the restrictions and overhead.

Maintain parity between AMP and canonical pages. If you create AMP versions of your pages, ensure the content matches your canonical pages. Significant differences between versions can cause indexing confusion and user experience issues.

Use the canonical/amphtml link relationship correctly. Your standard page should link to the AMP version with <link rel="amphtml">, and the AMP page should link back with <link rel="canonical">. This tells Google the two pages are related.

Validate every AMP page. Use the AMP Validator (validator.ampproject.org) or the browser extension to check for errors. Invalid AMP pages will not receive AMP-specific benefits and may not be cached by Google.

Track AMP performance separately in analytics. AMP pages served from Google's cache have different referrer behavior. Make sure your analytics setup correctly attributes traffic from AMP pages.

Consider AMP for specific page types only. Many sites implement AMP selectively for articles and blog posts while keeping their interactive pages (product pages, checkout flows, dashboards) as standard pages.

Common Mistakes

The biggest mistake is implementing AMP solely for SEO benefit without understanding the current landscape. AMP no longer gives preferential ranking treatment. If your non-AMP pages already meet Core Web Vitals thresholds, adding AMP may add complexity without meaningful benefit.

Creating AMP pages with significantly less content than the canonical version is problematic. Google may choose to index the canonical version instead, negating the point of having AMP pages.

Failing to update AMP pages when the canonical version changes creates content drift. If your AMP article is outdated while the canonical version is current, users who land on the AMP version get a worse experience.

Blocking AMP pages in robots.txt or adding noindex tags defeats the purpose entirely. AMP pages need to be crawlable and indexable to function as intended.

Not testing AMP pages on actual mobile devices is another oversight. The AMP Validator checks technical compliance but does not verify that the page looks good or functions well on real screens.

In Practice

The relationship between a standard page and its AMP version is declared with a pair of link tags. Your canonical (non-AMP) page points to the AMP version, and the AMP page points back to the canonical one. Suppose your article lives at https://example.com/blog/fast-pages. In the <head> of that standard page you add:

<link rel="amphtml" href="https://example.com/blog/fast-pages/amp">

The AMP version at https://example.com/blog/fast-pages/amp is a valid AMP document. Its skeleton looks like this:

<!doctype html>
<html amp>
 <head>
 <meta charset="utf-8">
 <link rel="canonical" href="https://example.com/blog/fast-pages">
 <meta name="viewport" content="width=device-width">
 <style amp-custom>
 h1 { font-size: 2rem; }
 </style>
 <script async src="https://cdn.ampproject.org/v0.js"></script>
 </head>
 <body>
 <h1>Fast Pages</h1>
 <amp-img src="/hero.jpg" width="1200" height="630" layout="responsive" alt="Hero"></amp-img>
 </body>
</html>

Two details from the spec are doing the load-bearing work here. The <html amp> attribute marks the document as AMP, and the spec accepts the lightning-bolt character form as an equivalent way to write it. The <amp-img> element replaces a plain <img> so the runtime can control loading. Run this through the validator at validator.ampproject.org. If your inline CSS in <style amp-custom> plus any inline styles cross 75,000 bytes, validation fails and the page loses its AMP benefits, so the practical move is to trim and tree-shake CSS down before shipping.

What Is Core Web Vitals? covers the LCP, INP, and CLS thresholds AMP is designed to help you pass.
What Is Largest Contentful Paint (LCP)? explains the loading metric and its 2.5 second target.
What Is a Canonical URL? explains the rel="canonical" relationship that ties an AMP page to its standard version.
What Is Mobile-First Indexing? covers why mobile performance shapes how Google crawls and ranks your pages.
What Is Page Experience? describes the Google ranking signals that replaced the old AMP requirement for Top Stories.

Conclusion

AMP was a transformative technology when Google tied it directly to search visibility, but its role has evolved significantly. Today, AMP is a tool for achieving fast mobile page loads, not a ranking requirement. If your site already performs well on Core Web Vitals, AMP may be unnecessary overhead. If you struggle with mobile performance due to heavy scripts, complex layouts, or ad-heavy pages, AMP offers a structured path to dramatically faster load times. Evaluate your specific needs, measure your current performance, and decide whether the speed benefits justify the development constraints.

Sources

More time, tools, and details on the page experience update, Google Search Central Blog (checked 2026-05-30) for the removal of the AMP requirement for Top Stories.
Understanding Core Web Vitals and Google Search results, Google Search Central (checked 2026-05-30) for Core Web Vitals as a ranking signal and the INP responsiveness metric.
How the Core Web Vitals metrics thresholds were defined, web.dev (checked 2026-05-30) for the LCP 2.5s, INP 200ms, CLS 0.1 thresholds at the 75th percentile.
Interaction to Next Paint (INP), web.dev (checked 2026-05-30) for INP replacing First Input Delay as a Core Web Vital in March 2024.
AMP HTML Specification, amp.dev (checked 2026-05-30) for the 75,000 byte CSS limit, the prohibition on author JavaScript, the <html amp> requirement, and the mandatory v0.js runtime script.
Supported CSS, amp.dev (checked 2026-05-30) for the single <style amp-custom> tag rule.
AMP Validator, validator.ampproject.org (checked 2026-05-30) for AMP page validation.