AMP Validator

AMP, originally short for Accelerated Mobile Pages, is an open-source framework developed by Google for building fast-loading web pages. It works by enforcing a restricted subset of HTML, CSS, and JavaScript that eliminates the most common causes of slow page rendering. AMP pages load near-instantly because the framework strips out render-blocking resources, limits CSS to 75KB inline, bans third-party JavaScript, and enforces static layouts that prevent content from shifting as the page loads.

When an AMP page passes validation, it becomes eligible to be cached and served by Google's AMP Cache (or other AMP caches), which pre-renders and delivers the page from servers geographically close to the user. This caching layer is what makes AMP pages feel almost instant when tapped from search results.

AMP started as a mobile-focused project in 2015, largely driven by Google's push for faster mobile experiences. It has since expanded beyond just mobile and beyond just Google, though its primary impact remains in how pages are served through Google Search.

AMP's role in the web ecosystem has shifted significantly since its early days. In 2021, Google removed the AMP requirement for appearing in the Top Stories carousel and stopped showing the AMP lightning bolt badge in search results. Pages no longer need to be AMP to rank well or appear in prominent search features.

That said, AMP isn't dead. It still serves specific use cases well. AMP pages are still cached and served by Google's CDN, which means they load faster than most standard pages for users in regions with slower connections. Several ad networks and content platforms continue to support or prefer AMP. Email providers like Gmail support AMP for Email, which enables interactive email content. And many large publishers who invested heavily in AMP infrastructure continue to maintain their AMP pages alongside their standard site.

The key shift is that AMP is no longer a competitive advantage in search rankings. Google's Core Web Vitals and page experience signals now evaluate all pages equally regardless of framework. A well-optimized standard page performs just as well in search as an AMP page. The decision to use AMP should be based on your specific technical needs and audience, not on SEO pressure.

The AMP Validator scans your markup against the full AMP HTML specification and reports every issue that would prevent the page from being considered valid AMP. Issues are categorized by severity to help you prioritize fixes.

Required markup. Every AMP page needs a specific set of boilerplate elements: the AMP runtime script, the AMP boilerplate CSS, a canonical link tag, a meta viewport tag, and the required doctype and html attributes. Missing any of these causes a validation failure.

Prohibited elements. AMP bans standard HTML tags that can cause slow rendering. Regular <img> tags must be replaced with <amp-img>. Forms use <amp-form>. Videos use <amp-video> or platform-specific components like <amp-youtube>. The validator flags any prohibited tags and tells you which AMP component to use instead.

Custom JavaScript restrictions. AMP does not allow custom JavaScript outside of <amp-script> sandboxed workers or AMP's own component scripts. Any inline script tags or external JavaScript files that aren't AMP components will fail validation. This is one of the strictest and most commonly violated rules.

CSS limitations. All CSS must be inline within a single <style amp-custom> tag, and the total size cannot exceed 75KB. External stylesheets are not allowed. The validator checks both the placement and size of your styles.

Layout and sizing. AMP requires explicit width and height attributes on media elements to prevent layout shifts. The validator checks that images, videos, iframes, and other embedded content have proper dimensions and use valid AMP layout values like responsive, fixed, fill, or intrinsic.

Component dependencies. If you use an AMP component like <amp-carousel> or <amp-accordion>, you need to include that component's script tag in the head of your document. The validator flags components that are used without their required script imports.

Missing or incorrect boilerplate. The AMP boilerplate CSS is a specific block of code that must be included exactly as specified. Even a small deviation, like an extra space or a missing rule, causes a validation error. The safest approach is to copy the boilerplate directly from the official AMP documentation rather than writing it by hand.

Using disallowed HTML tags. Standard tags like <img>, <video>, <iframe>, and <form> are not valid in AMP. Each has an AMP equivalent that enforces performance constraints. This is the most common error for developers converting existing pages to AMP, since it requires replacing familiar tags throughout the markup.

Custom JavaScript in script tags. Any <script> tag that isn't loading an AMP component library will fail validation. This includes analytics snippets, tracking pixels, chat widgets, and custom interaction code. AMP provides its own components for analytics (<amp-analytics>), ads (<amp-ad>), and many common interactive patterns, so most use cases have a compliant alternative.

CSS exceeding the size limit. The 75KB CSS cap is generous for most pages, but sites that rely on large frameworks like Bootstrap or Tailwind can hit it quickly. The validator reports the exact size overage so you know how much needs to be trimmed. Removing unused styles and minifying your CSS are the fastest fixes.

Missing width and height on media elements. AMP needs to know the dimensions of every image, video, and embedded element before the page renders. This prevents layout shifts but requires you to specify width and height attributes on every media tag. Forgetting these on even one element triggers a validation error.

Each error the validator returns includes a specific error code, the line number where it occurred, and a description of what's wrong. Here's a practical approach to working through them.

Start with structural errors. Fix missing boilerplate, doctype issues, and required meta tags first. These are foundational, and other errors sometimes cascade from structural problems. Once the page skeleton is correct, some downstream errors may resolve on their own.

Replace disallowed tags systematically. Search your markup for prohibited tags and swap them for AMP equivalents. Replace <img> with <amp-img>, <video> with <amp-video>, and <iframe> with <amp-iframe>. Add width, height, and layout attributes to each replacement.

Audit your script tags. Remove any custom JavaScript and check whether AMP provides a component that covers the same functionality. For analytics, switch to <amp-analytics>. For forms, use <amp-form>. For interactions that have no AMP equivalent, consider whether the functionality is essential or can be moved to the canonical (non-AMP) version of the page.

Trim your CSS. If you're over the 75KB limit, run your styles through a minifier and remove unused rules. Tools like PurgeCSS can identify styles that aren't referenced in your markup. If your styles are heavily framework-dependent, consider writing custom CSS for the AMP version instead of porting the entire framework.

Revalidate after every change. AMP validation is all-or-nothing. A page with one error is treated the same as a page with fifty errors: it won't be cached or served as AMP. Run the validator after each fix to confirm you're making progress and haven't introduced new issues.

The traditional AMP setup uses paired pages: a canonical (standard) page and a corresponding AMP version linked together with <link rel="amphtml"> and <link rel="canonical"> tags. The canonical page is your primary version, and the AMP page is a lightweight alternative that search engines can cache and serve for fast delivery.

However, AMP also supports a canonical AMP approach where the AMP page is your only page. In this setup, the AMP page links to itself as the canonical URL. This eliminates the need to maintain two versions of every page but means your entire site must comply with AMP restrictions, including no custom JavaScript and limited CSS.

For most sites today, the paired approach adds complexity that's hard to justify given that AMP is no longer required for search features. If you already have AMP pages running, maintaining them is reasonable. But building new paired AMP pages from scratch is rarely the best use of development time compared to optimizing your standard pages for Core Web Vitals.

If you do maintain paired pages, keep the content synchronized. Google compares the AMP version against the canonical version, and significant discrepancies can result in the AMP page being dropped from the index in favor of the canonical.

Most major content management systems support AMP through plugins or built-in features.

WordPress. The official AMP plugin for WordPress automatically generates AMP-compatible versions of your posts and pages. It supports multiple modes: Standard (your whole site is AMP), Transitional (paired AMP and non-AMP pages), and Reader (a separate simplified AMP theme). The plugin handles most validation issues automatically, though custom theme elements may still need manual fixes.

Drupal. The AMP module for Drupal provides theme-level AMP support with AMP-specific templates and formatters. It integrates with the AMP PHP library for server-side validation.

Other platforms. Shopify, Magento, Wix, and Squarespace all have varying levels of AMP support through native features or third-party extensions. The depth of support varies, so check whether the implementation covers your specific page types and content structures.

Regardless of your CMS, always validate the generated output with this tool. Plugins handle the common cases well but can miss edge cases introduced by custom themes, widgets, or content blocks that inject non-compliant markup.

Validating once and forgetting about it. Content changes, plugin updates, and theme modifications can introduce new AMP errors at any time. Set up a regular validation schedule or use monitoring tools that check your AMP pages automatically and alert you when errors appear.

Serving different content on AMP and canonical pages. Google expects your AMP page to contain the same substantive content as your canonical page. Stripping out sections, hiding content behind interactions, or showing different text to reduce page weight can result in indexing issues and violates Google's guidelines.

Ignoring AMP warnings. The validator distinguishes between errors and warnings. Errors prevent the page from being valid AMP. Warnings won't break validation but indicate issues that could affect performance or future compatibility. Address warnings when you can, especially those related to deprecated features that may become errors in future spec updates.

Over-investing in AMP for SEO purposes. Since AMP is no longer a ranking signal or a requirement for Top Stories, building and maintaining AMP pages purely for search advantages isn't a strong investment. Focus your performance optimization efforts on Core Web Vitals, which benefit all your pages regardless of framework.

Not testing on actual mobile devices. A page can pass AMP validation and still render poorly on certain devices or screen sizes. Validation confirms spec compliance, not user experience. Test your AMP pages on real phones across different browsers and connection speeds to ensure they deliver the fast, smooth experience AMP is designed for.