Crawl Stats Report

How to read Google Search Console's Crawl Stats report — total requests, download size, response time, and the breakdowns by response, file type, Googlebot type, and purpose.

First published: Jun 23, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #8 in Search Engine Tools#11 in Tools#193 in Technical SEO#267 on the site

The Crawl Stats report (Search Console → Settings → Crawl stats) shows how Google crawled your site over the last 90 days: total crawl requests, total download size, and average response time, plus breakdowns by response code, file type, Googlebot type, and purpose (Discovery vs Refresh). It's only available for root-level properties — a Domain property or a URL-prefix property verified at the site's root — not subfolder properties. For most sites it isn't a crawl-budget dashboard to optimize — it's a server-health early-warning system. Rising response times or 5xx make Google back off; sustained robots.txt unavailability can halt crawling. It's the closest GSC gets to log data, but it covers Google's crawlers only and isn't guaranteed to be request-complete.

TL;DR — Crawl Stats (Settings → Crawl stats, root-level properties only — Domain or root URL-prefix) reports total crawl requests, total download size, and average response time over ~90 days, plus breakdowns by response, file type, GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. type, and purpose (Discovery vs Refresh). Read it as a server-health monitor, not a crawl-budget vanity dashboard: rising response time or 5xx makes Google reduce crawl capacityThe number of URLs an engine will crawl in a timeframe., and a sustained robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. failure can halt crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. It’s the closest GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. gets to log data, but it covers Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. only and isn’t guaranteed to be request-complete — for all bots, users, and a complete record you still need server logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened.. Google scopes its own crawl-budget guidance to large, frequently-changing sites; for most smaller sites, in my experience, it almost never matters.

Evidence for this claim The Crawl Stats report shows Googlebot request totals, download size, response time, host status, and request breakdowns. Scope: Current Search Console Crawl Stats report. Confidence: high · Verified: Google Search Console: Crawl Stats report Evidence for this claim Google says crawl-budget management is mainly relevant to very large or rapidly changing sites; most sites can rely on normal crawling. Scope: Google's current crawl-budget guidance. Confidence: high · Verified: Google Search Central: Crawl budget management

What it is and where it lives

Google’s own framing is direct: “The Crawl Stats reportA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). shows you statistics about Google’s crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. history on your website.” You get to it under Settings → Crawl stats — not in the main report sidebar, which trips a lot of people up.

The single biggest reason people think the report is “missing” or “broken”: Google only shows it for root-level properties. In their words, “This report is available only for root-level properties.” That covers both a Domain property and a URL-prefix property verified at the site’s root (for example, https:// example.com) — it isn’t limited to protocol-less Domain properties. If you verified a URL-prefix property scoped to a subfolder or subpath, re-verify at the root level and it appears. There’s nothing wrong with your site.

Should you care? The crawl-budget reframe

Most sites do not need to optimize crawl budgetThe number of URLs an engine will crawl in a timeframe., and the report’s real value is health monitoring rather than budget tuning. Google scopes its own crawl-budget guidance to large sites (1M+ unique pages) and medium-or-larger sites (10k+ pages with daily change). Below that, this is a diagnostic, not a project.

Google also frames the report itself as built for advanced users, and says sites under roughly 1,000 pages generally don’t need to dig into it at this granularity — a smaller threshold than the crawl-budget guidance above. My own rule of thumb is looser: for most sites under about 10,000 pages, I still wouldn’t spend much time on crawl budget. Treat that as practitioner judgment, not an official cutoff.

Crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. is governed by two things working together — crawl capacity limit and crawl demandCrawl demand is the 'want' side of crawl budget — how much a search engine wants to crawl a site or URL, driven by popularity, staleness, and perceived inventory (plus temporary spikes from site moves). It's distinct from crawl rate/capacity, the 'can' side.. Capacity is what your server can handle. Google defines the capacity limit as “The maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” Demand is how much Google wants to crawl, driven by factors like popularity and staleness. The report is where the consequences of both show up. (More on the concept in crawl budget.)

A few scope details worth knowing before you read the numbers: the report counts the actual URL GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. requested rather than the canonical it resolves to, and it counts duplicate requests and each server-side redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. hop separately (client-side redirects aren’t counted as redirect responses here). It’s scoped to the property or host you’re viewing — resources on other domains, and sometimes sibling or child domains, can be under- or over-represented depending on property type. And per Google’s own documentation, the report reflects most crawl requests but can omit some, so a small mismatch against your own server logs is expected, not a bug.

This is the closest thing Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. gives you to log-file data — but it’s Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. only, aggregated, and not guaranteed to be request-complete. If you want hits from all bots and users, or a guaranteed complete record, you need your server logs. Treat Crawl Stats as the free first look before you invest in log analysis.

The three top-line metrics

Read these as trends, not targets:

  • Total crawl requests“The total number of crawl requests issued for URLs on your site, whether successful or not.” Every request counts, including the ones that errored.
  • Total download size“Total number of bytes downloaded from your site during crawling, for the specified time period.”
  • Average response time“Average response time for all resources fetched from your site during the specified time period.” This is effectively a server-health proxy. A sustained spike is a performance alarm, and Google may respond by dropping your crawl capacity limit — so the SEO harm is indirect (slower, less crawling), separate from any page-speed ranking factor.

Breakdown: By response

This table, in Google’s words, shows “the responses that Google received when crawling your site, grouped by response type, as a percentage of all crawl responses.” The response types include OK (200), Moved permanently (301), Moved temporarily (302), Not found (404), Server error (5XX), and robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. not available.

How I read each pattern:

  • 200 should be the large majority. Google doesn’t publish a specific target percentage, so judge this against your own baseline and watch for sustained shifts rather than chasing an exact number.
  • Lots of 404s isn’t fatal but signals wasted crawl — Google spending requests on URLs that don’t exist.
  • Lots of 301s points at redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. or internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. still aimed at old URLs. Fix the links to point at the final destination.
  • A 5xx spike is the most damaging pattern in the report. Your server is erroring under crawl load, which drops the capacity limit, which means less crawling. Sustained 5xx can effectively throttle Google to a crawl.
  • robots.txt not available shouldn’t show up in any sustained, meaningful way. Google doesn’t publish a fixed target percentage, but a persistent share means Google periodically couldn’t fetch your robots.txt. That matters because if your robots.txt stays unavailable, Google will conservatively pause crawling for a while rather than guess. (For what robots.txt does and doesn’t control, see robots.txt.)

Breakdown: By file type

Google groups crawling by file type — HTML, image, JavaScript, CSS, JSON, PDF, and others. This is a diagnostic lead, not proof of waste on its own — how much JS, CSS, image, or JSON crawling is normal depends on how your site is built (a JS-heavy app legitimately needs more resource crawling than a static HTML site). A JS/CSS/image share that’s high relative to your own baseline, or that jumps suddenly, is worth investigating as possible render-resource overhead. Unexpected file types showing up can reveal a crawl trap — an infinite or near-infinite URL space generating junk.

Breakdown: By Googlebot type

This splits crawling by which Googlebot did the fetching — smartphone, desktop, image, video, page resource load, and AdsBot. Google doesn’t document a required mix, but in a mobile-first crawl, Smartphone typically leads for most sites. A desktop-heavy profile, or unexpected volume from Image or AdsBot, is a lead worth investigating rather than a violation by itself — it can mean Google isn’t treating your site as mobile-first, that ad/image crawling is eating into budget you’d rather spend on content, or just that your site has unusual resource needs.

Breakdown: By purpose — Discovery vs Refresh

Two categories, and Google defines them only by prior crawl history — the labels alone don’t tell you whether the mix is healthy:

  • Discovery“The URL requested was never crawled by Google before.”
  • Refresh“A recrawl of a known page.”

A rise in Discovery is expected during a launch or migration (Google is finding your new URLs); the same rise is a problem if it’s coming from infinite-space or parameter URLs — that’s crawl budget going to garbage. A Refresh-heavy mix is normal for an established site that isn’t publishing much new content. Judge either against your own baseline and what you know changed, not against a fixed “healthy” ratio.

Host status — the most actionable block

Host statusThe at-a-glance availability indicator at the top of Google Search Console's Crawl Stats report. It shows whether Googlebot hit significant problems reaching your site in the last 90 days across three checks — robots.txt fetching, DNS resolution, and server connectivity. summarizes whether Google hit availability problems trying to crawl you, grouped into three sub-checks: robots.txt fetch, DNS resolution, and server connectivity. A red host status is one of the most actionable signals in the report — it usually means Google was blocked or throttled at the infrastructure level, before it ever got to your content, during that window. It’s an aggregate alert, though, not proof that every URL was affected or that the problem is still happening now — check the timeline and confirm current status (a live fetch, URL Inspection, or your logs) before you consider it fixed. Still, treat a red host status as the first thing to investigate. (Covered in its own right under Host status.)

Reading spikes and drops

The mechanism to internalize: your server’s behavior feeds back into how much Google crawls. If the site responds quickly and reliably, Google’s capacity limit can rise; if it slows down or starts returning server errors, the limit drops. So:

  • Response-time spike → capacity limit can drop → less crawling.
  • 5xx surge → capacity limit drops → less crawling; sustained, it can throttle you hard.
  • robots.txt unavailable → if it stays unavailable, Google pauses crawling conservatively.

None of this is a ranking penalty. The damage is indirect: if pages aren’t crawled and indexed, they can’t rank at all — but extra crawling doesn’t lift rankings either. (See the crawl budget concept for the full capacity-plus-demand model.)

Crawl Stats vs server logs

Crawl Stats is the closest GSC gets to logs, but the gaps matter:

Crawl Stats reportServer logs
Who it coversGoogle’s crawlers onlyAll bots and all users
GranularityAggregated; may omit some requestsEvery individual request
Retention~90 daysWhatever you keep
Per-URL detailNoYes
CostFree, in GSCStorage + analysis effort

If you outgrow Crawl Stats — you need per-URL data, non-Google bots, or longer history — that’s when you graduate to log file analysisLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened.. Crawl Stats tells you something’s off; logs tell you exactly where.

TIP Move from Crawl Stats trends to the exact wasted URLs

Search Console shows Google-level trends; server logs identify the request paths and responses behind them. This sample also separates spoofed claims and AI-crawler policy from crawl waste.

Inspect a log sample with my free Log File Analyzer Free

  1. Export a representative access-log window that overlaps the Search Console anomaly.
  2. Verify crawler identity and group requests by status, path, and crawler purpose.
  3. Fix broken links, redirect chains, and server errors, then watch both logs and Crawl Stats for recovery.
The three findings require three decisions; only the non-200 group explains wasted crawl paths.

The log sample reports 30 requests spoofing a verified crawler, AI-training crawlers at 32.1 percent of crawler traffic, and Googlebot spending 49.6 percent of 129 requests on non-200 responses, including 404 and 410 URLs, redirects, and server errors.

How this relates to the rest of crawling

The Crawl Stats report is your view into crawling after the fact. For the indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. side of what happens next, the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. is the companion — Crawl Stats shows what Google fetched; Page Indexing shows what made it into the index. And Host status, surfaced inside this report, is the infrastructure-level signal worth leading with.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.