Skip to content
Searcle Book a demo

Crawl Stats Shows Fetching; Page Indexing Shows Index Outcomes

Nina Okonkwo

Learn why Search Console crawl requests never match indexed-page totals, which report to use, and how to diagnose discovery, fetching and indexing issues.

Crawl Stats and Page Indexing measure different stages of Google Search. Crawl Stats answers what Google requested from your site and how the server responded. Page Indexing answers which known URLs Google indexed, which it did not, and why.

Do not treat the two totals as a conversion funnel or expect them to match. One crawl request is not one indexed page.

The practical difference

Question Use this report What to examine
Is Google encountering DNS, server or robots.txt availability trouble? Crawl Stats Host status, response codes and response time
What is Googlebot spending requests on? Crawl Stats File type, crawl purpose, Googlebot type and example URLs
Are important pages indexed? Page Indexing Indexed status, exclusion reasons and sitemap filters
Why is one important URL missing? URL Inspection Indexed result, live test, crawl status, noindex and canonical selection
Is a large site wasting crawl capacity? Crawl Stats plus server logs Duplicate URLs, redirects, errors and low-value URL patterns

Google describes crawling, indexing and serving as separate stages: it first downloads content, then analyzes and may store it in the index, then selects results for a query. Not every page proceeds through every stage, and indexing is not guaranteed (Google Search Central).

Why fetched URLs and indexed documents differ

Crawl Stats counts requests, not unique pages

Crawl Stats records requests to URLs on the property, successful or unsuccessful. Repeated requests to the same URL count repeatedly. Requests for on-site resources such as images, JavaScript and CSS can count too. A server-side redirect chain can generate a separate request for every URL in the chain (Search Console Help).

A single page might therefore produce several crawl requests, while the same page can be fetched again during the reporting period. Conversely, a URL Google knows about can remain uncrawled or fail to be fetched.

The examples in Crawl Stats are only representative, not a complete URL list. Google also says the report captures most, but not necessarily all, crawl requests, so use server logs when you need a request-level audit rather than treating the report as a complete export (Search Console Help).

Page Indexing reports status, not crawl volume

The Page Indexing report covers the indexing status of URLs Google knows about. Its top level separates indexed from non-indexed URLs and groups the latter by reason (Search Console Help).

That does not mean every known or crawled URL should become an indexed document. Google can cluster similar pages and select one canonical page while treating the others as alternate versions. Its own guidance says the goal is to index the canonical version of every important page—not to achieve 100% indexing coverage (Google Search Central; Search Console Help).

Expected non-indexed URLs can include duplicates, alternate URLs and genuinely removed pages returning 404. Unexpected exclusions on commercially important service, product or article pages deserve investigation.

Diagnose in the right order

1. Start with the business-critical URL set

Define the pages that should generate discovery or qualified demand: core product and service pages, useful comparison pages, high-intent articles and conversion routes. Compare that controlled list with your XML sitemap and Page Indexing data. A sitewide percentage can look healthy while an important page remains excluded.

Sitemaps help Google discover pages, while crawlable links let Googlebot navigate from one URL to another (Google Search Central). Keep the sitemap limited to URLs you actually want considered for indexing.

2. Use Page Indexing for patterns

Ask:

  • Is the important URL indexed?
  • If not, which reason does Google report?
  • Is that outcome intentional?
  • Does the problem affect a page template, directory or sitemap group?

Prioritize website-controlled problems affecting intended canonical pages. Do not open a development ticket merely because duplicate, alternate or deleted URLs are excluded.

3. Inspect individual URLs

The Page Indexing report is for patterns; Google directs users to URL Inspection for a specific page. URL Inspection separates information about Google’s indexed version from a live test of the current URL. It can show the last crawl, whether crawling and indexing were allowed, whether fetching succeeded, and Google’s selected canonical (Search Console Help).

That distinction matters after a fix: the indexed result can reflect an older fetched version, while the live test checks current accessibility and potential indexability. A successful live test does not itself mean the URL has been indexed.

4. Open Crawl Stats when the failure is about fetching

Use Crawl Stats when many important URLs show fetch problems, indexing falls after a migration, server errors rise, or Googlebot appears to spend substantial effort on redirects and unwanted URL variants.

Check host status first, then response groups and example URLs. Crawl Stats is available only for root-level Domain properties or root-level URL-prefix properties, and Google positions it as an advanced report rather than a routine requirement for small sites (Search Console Help).

Crawl-budget work is usually unnecessary for a modest site whose new pages are crawled promptly. Google’s crawl-budget guide is aimed mainly at very large sites, rapidly changing sites, and sites with many URLs marked “Discovered – currently not indexed.” For other sites, Google says an up-to-date sitemap and regular Page Indexing checks are generally adequate (Google Crawling Infrastructure).

Report the outcome without combining incompatible totals

A useful search report should keep these layers separate:

  1. Discovery: Are intended URLs linked and included in the sitemap?
  2. Fetching: Can Google retrieve them reliably, and what is consuming requests?
  3. Indexing: Are the intended canonical pages indexed?
  4. Visibility: Do indexed pages earn relevant impressions and clicks?
  5. Business value: Do those visits contribute qualified enquiries or pipeline?

That layered approach avoids a common reporting error: presenting increased crawl requests as SEO growth. More requests can reflect useful discovery, routine refreshes, duplicate URLs, resources, redirect chains or errors. Judge Crawl Stats by fetch efficiency and server health; judge Page Indexing by whether the right canonical pages are eligible for search. Then connect visibility to the page’s commercial role with a post-launch SEO measurement loop.