Googlebot is crawling my AMP pages more than they are crawling my desktop pages. I have the appropriate canonical from AMP to desktop and amphtml from desktop to AMP. The desktop version also has a self-referencing canonical. Only canonical pages are in the sitemap.

This is a concern because less than 10% of our traffic is from mobile devices (unique, I know), yet it's more than 50% of our crawl budget.

The one thing that we do, which I'm not sure if this is appropriate or not, is whenever a desktop page 1 links to an internal page 2, the AMP version of page 1 links to the AMP version of page 2. Therefore, there are internal links pointing to AMP pages, but only from other AMP pages.

The other thing I was wondering is whether anyone has heard of Google serving AMP pages to desktop users behind low bandwidth connections, where they could benefit from AMP. Supposedly AMP doesn't have to be for only mobile anymore, but Google hasn't really demonstrated this. We don't get a lot of mobile traffic, but we do get a lot of third-world / low-bandwidth traffic.

Dani AI

Generated

Useful, practical follow-ups for (and thanks to for the quick thumbs-up): Google discovers AMP via the rel="amphtml" / rel="canonical" pairing and will follow whatever crawlable links it finds. Because alternate URLs (AMP, hreflang alternates, embedded resources) all consume crawl budget, a dense graph of AMP-to-AMP internal links makes AMP pages more attractive to crawlers — so the behavior you see is expected from how discovery + crawl budget work. (amp.dev)

How to diagnose quickly: check Search Console’s Crawl Stats and the AMP status report to see which agent and URL-types Google is fetching, and use URL Inspection for “Crawled as / Indexed as” details. For a ground-truth view, scan server logs for Googlebot requests to AMP paths (example):

# simple log check — counts Googlebot hits to AMP URLs
grep -i 'googlebot' /path/to/access.log | grep '/amp/' | wc -l

The Crawl Stats report shows Googlebot types and request purpose; the AMP/validation report shows discovery/indexing problems you should fix. (developers.google.com)

Remediations that reduce AMP crawl noise without breaking discovery:

  • Stop publishing visible, site-wide links to AMP versions; keep the rel="amphtml" link in the head so Google can discover AMP, but make navigation/internal anchors point to your canonical pages instead.
  • Keep only canonical URLs in your XML sitemap (don’t list AMP variants unless the AMP page is canonical).
  • Don’t block AMP files with robots.txt (Google needs to fetch AMP to read the rel=canonical).
  • If you truly want AMP out of Search, remove rel="amphtml" or return a redirect from the AMP URL to the canonical page — Google documents safe removal steps. (developers.google.com)

About desktop/low-bandwidth serving: Google may show AMP via the AMP Viewer or via Signed Exchanges (SXG); SXG lets the browser show the publisher URL where supported. Official docs note desktop AMP isn’t typically served from Google’s AMP viewer/cache the way mobile results are, though SXG changes how it appears in some browsers. If desktop/slow-network users matter, consider either making canonical pages faster (Core Web Vitals) or publishing AMP as the canonical version and monitoring index/crawl impact. (developers.google.com)

Best and beneficial information. Thank you very much to share this information. I was very worry about amp. Thanks again to solve my problem

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.