AMP pages clogging the Coverage Report

Dani 1 314 Views

AMP pages are clogging the Valid Pages coverage report, grouped as Indexed, Not Submitted In Sitemap.

My AMP pages are linking to the AMP version of the URLs the desktop versions link to. Desktop links to desktop. AMP links to AMP.

What this means is that sometimes the AMP version of a page gets discovered before the non-AMP version. When that happens, it gets indexed as its own page, cluttering up the coverage report. Once the non-AMP version gets crawled, the AMP version leaves the coverage report.

With millions of pages, and new pages constantly added, the coverage report is completely useless in helping me to discover any URLs that actually should be in the sitemap but aren’t, or should be noindexed but aren’t.

I guess this is more of a pet peeve than anything. Any suggestions?

Dani AI

Generated

Short summary and root cause (as described): AMP pages can be discovered and indexed independently of their non‑AMP counterparts, so Search Console will surface them under the “Indexed / (previously) Indexed, not submitted in sitemap” bucket when they aren’t listed in the sitemap Google has on file. That behaviour is expected when discovery order differs and is what makes the Coverage / Pages index view noisy on very large sites. (Search Engine Journal , Onely / GSC Page indexing notes).

Concrete checklist (quick, high‑value fixes and checks):

  • Confirm bidirectional linking: the canonical (non‑AMP) page must link to the AMP URL with rel="amphtml" and the AMP page must include rel="canonical" pointing back to the canonical URL. This is the primary signal Google expects for AMP/HTML pairs. 

    <!-- on canonical page -->
<link rel="amphtml" href="https://example.com/article/amp">

<!-- on AMP page -->
<link rel="canonical" href="https://example.com/article">

    (See Google Search Central: Enhance AMP content; AMP spec).
    (Google: Enhance AMP content, AMP spec)

  • Sitemap signals: sitemaps should contain the canonical URLs that are intended for indexing; AMP alternates may be expressed with <xhtml:link rel="amphtml"> if desired, but the canonical sitemap should prioritize the canonical (non‑AMP) URLs for clarity. (Google: Sitemaps overview, example use of xhtml:link).

  • Validate and inspect: run the AMP Validator and the GSC AMP report / URL Inspection on representative problem URLs to confirm which URL Google treats as canonical and whether the AMP page is valid. If the AMP version should stop being indexed, remove the rel="amphtml" from the canonical page or implement redirects per Google’s removal guidance. (Validate AMP, Remove AMP pages).

  • AMP implementation sanity check (to ’s point): loading arbitrary external JS or external stylesheets on AMP pages violates AMP rules—AMP disallows author JS in the head and requires inline style amp-custom (subject to the size limit in the spec). Use AMP components or amp-iframe for custom widgets and re-run validation. (AMP spec: scripts & styles)

Scale / automation tip for very large sites: treat the Coverage noise as a signal, not a bug. Sample URLs, use the Search Console URL Inspection API to programmatically inspect canonical choice and AMP validity (script a crawl of sitemap + API calls), and flag patterns (wrong canonical hosts, missing rel tags, validation failures) for batch fixes. Be mindful of API quotas and throttle accordingly. (Search Console API / URL Inspection references). (Search Console URL Inspection API notes)

Short take: the fix is almost always canonical/sitemap alignment + AMP validation. If canonical signals are correct and AMP is valid, the noise will drop as Google consolidates index choices; if AMP pages are unwanted, remove the rel="amphtml" / redirect them off search.

Member Avatar for _1_1
_1_1 -3 Newbie Poster

I though you were staying away from amp. I noticed a few interesting things:

  1. You're using a cdn - are your amp page versions not moved to Google's servers?
  2. You're loading external .js and .css from your cdn. Isn't this a violation of AMP standards?
  3. You write nice code. Still, some over my had a little, but not much of it.

What package do you use to minimize your .js and .css?
Al the best - Dave

Edited by _1_1
Member Avatar for Dani
Dani 5,664 The Queen of DaniWeb

I definitely was in no rush to embrace AMP. I finally added it over the summer as part of a huge SEO initiative. When Google Search Console released Core Web Vitals, mobile vitals were tipping between Poor and Need Improvement for speed. I added AMP to make sure that mobiel would be listed as Good.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview