What AMP is and where it stands in 2026
AMP, short for Accelerated Mobile Pages, is a stripped-down way of building web pages designed to load almost instantly on mobile devices. It enforces a restricted subset of HTML, bans custom JavaScript in favor of a fixed component library, and requires that styles be inlined and sized in advance so the browser can render the page without waiting on external resources or recalculating layout. This validator detects whether a page is built as AMP, confirms the markup includes the pieces AMP requires, and checks that the connection between your normal page and its AMP version is declared correctly in both directions.
It is important to be honest about AMP's current role. Google removed the requirement that news content be AMP to appear in the Top Stories carousel, and the visible AMP badge and AMP-specific ranking advantages are gone. AMP is no longer a prerequisite for any major search feature. That said, plenty of sites still run AMP — large publishers, sites on platforms that generate it automatically, and pages built years ago that nobody has migrated. If you are running AMP, it still needs to be valid to work at all, and invalid AMP can cause real problems. This tool helps you confirm your existing AMP is correct, or decide whether to keep it.
The required markup that makes a page valid AMP
A valid AMP page is not just normal HTML with some extra tags — it is a specific document shape. The opening html tag must carry the AMP indicator (the lightning-bolt attribute) so parsers know to treat the document as AMP. The page must load the official AMP runtime script from the AMP project, and it must include a particular boilerplate snippet of styles whose job is to hide the page until the runtime is ready and then reveal it cleanly, which prevents the flash of unstyled content AMP is designed to avoid. The character encoding must be UTF-8 and declared early, and a viewport meta tag set up for mobile is required.
Beyond that scaffolding, AMP replaces many ordinary HTML elements with AMP-specific components. Images use the AMP image component instead of a plain image tag so the runtime can manage loading and layout. Custom JavaScript is not allowed at all; interactivity comes from the sanctioned component set. All author styles must live in a single inline style block in the head, kept under a strict size budget, with no external stylesheets. The validator checks for these structural requirements — the AMP attribute, the runtime script, the boilerplate, correct encoding and viewport — and flags the obvious violations like disallowed custom scripts or external stylesheets that immediately invalidate the page.
The amphtml link and the pairing between versions
Most AMP setups are paired: there is a canonical, full-featured page for desktop and general use, and a separate lightweight AMP version of the same content. The two must reference each other correctly or search engines will not understand the relationship. The canonical page declares a link with the amphtml relation pointing at its AMP counterpart, and the AMP page declares a standard canonical link pointing back at the full page. This reciprocal pairing tells Google which page is the master and which is the accelerated alternate, so ranking signals consolidate on the canonical while the AMP version can be served when speed matters.
Getting this pairing wrong is one of the most common AMP failures. If the AMP page canonicalizes to itself instead of the main page, signals fragment between two near-duplicate URLs. If the amphtml link on the main page points at a missing or wrong AMP URL, the connection breaks. If the AMP page is a standalone document with no paired canonical at all, it can be treated as a separate page that competes with your real one. The validator checks both directions of this link relationship and tells you whether the master-and-alternate pairing is wired up the way it needs to be.
How to read the results
A clean result for an AMP page shows the AMP attribute on the html element, the official runtime script present, the required boilerplate styles in place, UTF-8 and viewport declared, no disallowed scripts or external stylesheets, and a canonical link pointing to the paired full page. For a non-AMP page that has an AMP version, a clean result shows a valid amphtml link pointing at a real, reachable AMP URL. Either way, the structure is sound and the two versions understand each other.
Warnings fall into two buckets. Structural violations — a missing runtime script, missing boilerplate, custom JavaScript, external stylesheets, oversized inline styles, or plain image tags where AMP components are required — mean the page is not valid AMP and will not be treated as AMP at all. Pairing problems — a broken or missing amphtml link, an AMP page canonicalizing to itself, an amphtml link pointing to a 404 — mean the relationship between your versions is broken even if each page is individually fine. The tool runs basic structural checks rather than the full official AMP validation, so treat a clean result as a strong signal that the fundamentals are right, and a flagged result as a clear list of things to fix.
The mistakes that quietly invalidate AMP
The most damaging AMP mistakes are the ones that invalidate the page silently while everything still looks fine in a browser. A single line of custom JavaScript — a stray analytics snippet, a chat widget, an A/B testing script added later — breaks AMP validity entirely, because AMP forbids author JavaScript outright. An external stylesheet pulled in by a plugin does the same. Inline styles that creep past the size budget as a design grows will invalidate the page once they cross the threshold. These often appear after the fact, when someone adds a feature to an AMP template without realizing AMP's rules are absolute, not advisory.
The other cluster of mistakes is about the pairing and about content parity. AMP pages that drift out of sync with their canonical versions — missing content, missing structured data, different metadata — cause problems because Google expects the AMP version to be substantially equivalent to the main page. Broken amphtml links after a URL change, AMP pages that have been orphaned because the main version was redesigned but the AMP template was forgotten, and AMP pages still being served long after the team stopped maintaining them are all common. The quiet danger of unmaintained AMP is that it keeps serving a degraded, possibly broken experience to mobile users while nobody is watching it.
How AMP fits modern SEO and the case for moving on
Because AMP no longer confers ranking or carousel advantages, the strategic question for many sites is whether to keep it at all. The original justification — AMP as the only path to certain mobile search features — no longer holds. Modern frameworks, good image optimization, sensible JavaScript budgets, and attention to Core Web Vitals can produce pages that load as fast as AMP without AMP's constraints, and those improvements benefit your entire site rather than a parallel AMP copy. Maintaining two versions of every page is real overhead, and divergence between them is a steady source of bugs.
For sites that decide to retire AMP, the safe path is to redirect AMP URLs to their canonical versions and remove the amphtml links, so search engines cleanly consolidate on the main pages. For sites that keep AMP — often because their platform generates it automatically or because it genuinely performs well for their audience — the priority is simply keeping it valid and in parity with the canonical pages. AI search and retrieval systems read the canonical version of your content, so as long as the pairing is correct and your main pages are strong, AMP becoming optional does not put your content at risk. The validator is most useful as the tool that tells you which situation you are actually in.
What to do after you run the validator
If you are keeping AMP and the validator flags structural violations, remove the offending pieces: strip any custom JavaScript, eliminate external stylesheets in favor of the single inline style block, bring inline styles back under the size budget, and replace disallowed elements with their AMP components. Restore any missing runtime script or boilerplate, and confirm UTF-8 and the viewport are declared. Then fix the pairing — make sure the AMP page canonicalizes to the full page and the full page's amphtml link points at a real, reachable AMP URL — and verify the two versions actually contain the same content and structured data.
If the validator confirms your AMP is broken, unmaintained, or no longer worth the upkeep, treat that as a signal to plan a clean retirement: redirect AMP URLs to their canonical pages, remove the amphtml links, and invest the saved effort in making your main pages genuinely fast through performance work that helps every visitor. Either way, after any change re-run the check on a representative AMP page and its paired canonical, and add this to your testing routine if AMP is part of your stack — AMP's strict rules mean a small, well-intentioned edit elsewhere can invalidate pages without any visible warning.