Could excluded AMP pages really indicate a bad implementation?

Why does Google refer to pages as 'alternates' rather than independent pages?

AMP pages are not indexed as standalone URLs in most cases. They function as accelerated versions of your classic pages, linked by a bidirectional relationship: the standard HTML page points to the AMP via a link rel=amphtml tag, and the AMP links back to the original through a canonical.

This architecture allows Google to serve the AMP version in contexts where speed is crucial — mobile results, Top Stories carousels — while keeping the HTML page as the canonical reference. Consequently, the engine does not duplicate content in its index: it stores a primary URL and associates the AMP as a variant.

What does 'a large number of pages marked as excluded' really mean?

In Search Console, the Coverage tab lists discovered but non-indexed URLs. If your AMP pages appear significantly in the categories "Excluded by noindex tag," "Alternative URL with appropriate canonical tag," or "Duplicated page without user-defined canonical URL," it signals a structural issue.

Google tolerates a few excluded AMP pages — for example, test URLs or intentionally de-indexed content. However, an abnormal volume generally indicates that the canonical linking is broken, that AMP/HTML tags are reversed, or that AMP validators detect critical errors blocking indexing.

Why does a poor AMP implementation pose a problem for SEO?

A faulty AMP configuration creates wasted crawl budget: Googlebot visits dozens or hundreds of pages that it eventually rejects. Worse, if the canonicals are misdirected, you risk having your AMP pages indexed instead of the HTML pages — which dilutes the ranking signals between the two versions and fragments your metrics.

Some sites have even seen traffic drops when launching AMP with reversed canonicals, forcing Google to favor a stripped-down version without the internal linking, CTAs, or JSON-LD schemas present on the standard page. The result: fewer conversions, less crawl depth, and a total misalignment between user intent and served content.

• AMP = alternate, not standalone: always linked to a classic HTML page via canonical.
• Massive exclusion = red flag: check canonicals, AMP validation, and URL conflicts.
• Reversed canonical: risk of indexing AMP instead of HTML, leading to loss of SEO signals.
• Crawl budget: rejected AMP pages = wasted crawl resources on unnecessary URLs.
• Fragmented metrics: two indexed versions = dilution of ranking and analytical confusion.

Is this statement aligned with real-world observations?

Yes, but with a significant nuance: Google does not specify the threshold at which 'a large number' becomes problematic. On sites with several thousand pages, seeing 10-15% of excluded AMP can be normal — pagination URLs, archived content, or pages intentionally marked as noindex. In contrast, if 50% or more of your AMPs are excluded, it's a critical signal.

The audits I’ve conducted show that the most frequent errors are: (1) canonical pointing to the AMP itself instead of the HTML page, (2) missing rel=amphtml tag on the classic page, (3) undetected AMP validation errors in development but blocking in production. Google does not always crawl AMPs at the same frequency as standard pages, so a delay of several weeks may occur before exclusions appear in Search Console.

Should I be concerned if my AMPs are marked 'Alternative URL with appropriate canonical tag'?

No, this is actually the expected behavior. This status confirms that Google has identified the AMP/HTML relationship and chosen to index the classic page as the reference. Many SEOs panic upon seeing hundreds of URLs in this category, even though this is exactly what Google recommends.

The real problem occurs when your AMPs are marked as 'Excluded by noindex tag' or 'Duplicated page without user-defined canonical URL.' Here, you have either a directive conflict (noindex tag server-side vs. absence of canonical) or a templating error generating orphaned AMP URLs with no link to the HTML.

In which cases does AMP implementation remain relevant today?

Let’s be honest: AMP has lost traction since Google removed the lightning badge and opened Top Stories to non-AMP pages that meet Core Web Vitals. For media outlets that have heavily invested in AMP, disabling the technology isn’t trivial — risk of loss of residual visibility, redesigning templates, and migrating URLs.

But for a new project, [To be checked] if AMP still provides a tangible advantage over a modern stack (Next.js, SSR, well-configured CDN). A/B tests I've seen show that the speed gains from AMP are often matched by a well-optimized HTML page, with the benefit of not having to manage two versions in parallel.

How to diagnose a bad AMP implementation in Search Console?

Go to Coverage > Excluded and filter by 'AMP' in the search bar. If you see an abnormal volume of URLs under 'Duplicated page without user-defined canonical URL' or 'Excluded by noindex tag', investigate the provided examples. Inspect the URL in the URL Inspection tool to see how Googlebot interprets the canonicals and relation tags.

Also check the Improvements > AMP tab: Google lists critical validation errors here (forbidden tags, too heavy inline CSS, unauthorized JavaScript). A validation error systematically blocks indexing, even if the canonical is correct. Do not overlook the warnings: they do not prevent immediate indexing but can degrade user experience to the point where Google eventually excludes the page.

What canonical errors should be absolutely avoided?

The classic mistake: placing a rel=canonical in the AMP that points to… the AMP itself. As a result, Google treats the AMP as the main page and ignores the HTML version. Another trap: forgetting the link rel=amphtml tag in the classic page — without this bidirectional link, Google does not make the connection and may index both as distinct contents, risking cannibalization.

Some CMSs generate AMP URLs with parameters (?amp=1) or subdomains (amp.example.com). Ensure that the canonicals always point to the URL without parameters and on the main domain. Lastly, if you are using CDNs or reverse proxies, verify that HTTP headers do not override HTML tags — a Link: rel=canonical in the header can conflict with that in the <head>.

What to do if I see a high volume of excluded AMP pages?

First, quantify the issue: if less than 10% of your AMPs are excluded and they correspond to marginal content (archives, test pages), there’s no need to panic. Beyond 20-30%, conduct a technical audit: crawl your site with Screaming Frog in AMP mode, export the canonicals, and compare them to the expected HTML URLs.

Next, correct the errors in order of priority: (1) reversed or missing canonicals, (2) critical AMP validation errors, (3) missing rel=amphtml tags. Once corrections are deployed, submit a sample of corrected AMP URLs via the inspection tool to force a quick re-crawl. Monitor changes in Search Console over 2-3 weeks — Google does not update exclusion statuses instantly.

• Filter excluded URLs in Search Console and isolate AMP pages.
• Inspect canonicals with Google’s URL inspection tool.
• Verify that each HTML page contains a link rel=amphtml pointing to its AMP.
• Validate AMPs using the official Google AMP Test tool or ampproject.org/validator.
• Crawl the site in AMP mode with Screaming Frog to detect broken canonicals.
• Submit corrected URLs for re-crawl via Search Console.