What the crawl stats report measures
Every time Googlebot asks your server for a file — a page, an image, a stylesheet, a script — that request is recorded. The crawl stats report, tucked under Settings in Google Search Console, summarises those requests across the whole property for a recent rolling window. It gives you the number of requests, the total download size and the typical server response time, plotted as trends rather than single figures.
Below the chart, the same requests are grouped by response code, by file type, by purpose and by crawler. Purpose separates refresh crawls, where Google is re-checking a URL it already knows, from discovery crawls, where it is fetching something new. Crawler separates smartphone Googlebot from the desktop, image and ad crawlers, which is how you tell ordinary indexing traffic apart from a shopping feed check or an ad landing page review.
Why the crawl stats report matters
It is the one place in Search Console that shows your site from the server’s side rather than the index’s side. A page that never appears in search might have been crawled and rejected, or it might never have been requested at all, and those two problems have completely different fixes. Crawl stats tell you which one you are dealing with.
It is also an early warning system. Response times drifting upward, a rise in server errors, or a slump in total requests usually shows here before rankings move. On cheap shared hosting — common for smaller sites in Nepal — a slow response under crawl load is a genuine constraint, and this report is where it becomes visible. If your own server is throttling how much Google can fetch, no amount of content work will help until the hosting is fixed.
Common mistakes with crawl stats
The first is treating more crawling as better. A rising request count can mean Google has found a faceted navigation or an events calendar generating endless URLs, and attention is being spent on pages you never wanted in the index. Read request volume next to what is actually getting indexed, never on its own.
The second is reading it like a page-level tool. Crawl stats are aggregated for the whole property and will not tell you when one particular URL was last fetched — that is what the URL Inspection tool is for. The third is panicking at a single spike. Crawling is naturally uneven, and one unusual day in a chart is not a trend.
How to act on it
Start with host status, which flags whether robots.txt fetching, DNS or server connectivity failed recently. Then read the response codes. Server errors and not-found responses in any quantity deserve investigation, because both waste requests and both suggest something is broken.
If requests are being spent on the wrong URLs, the fix is structural: block genuinely useless paths in robots.txt, stop linking to them internally, and make sure your XML sitemap lists only pages you want indexed. If response time is the problem, it belongs with hosting and technical SEO work rather than with content. A small brochure site needs a glance at this report once or twice a year; a large catalogue deserves a monthly look alongside crawl budget.