What crawl stats measure
Crawl stats sit in Search Console settings and describe the conversation between Googlebot and your server. The headline figures are how many requests were made over the period, how much was downloaded, and how long your server took to respond. Underneath, the same requests are split several ways: by response, so you can see successful fetches next to redirects, missing pages and server errors; by file type, separating HTML from images, scripts and stylesheets; by purpose, separating the discovery of new addresses from the refreshing of ones already known; and by crawler, since the smartphone, desktop, image and video bots are counted apart.
There is also a host status panel. It reports whether your robots file could be fetched, whether the domain name resolved, and whether the server accepted connections. If any of those fail, crawling slows or stops regardless of how good the pages are.
Why crawl stats matter
They explain timing. When content is published and does not appear in results for a long while, the question is whether Google has been to look. Crawl stats answer that at site level, and the discovery-versus-refresh split shows whether the crawler is spending its visits on new material or re-reading pages it already has.
They are also an early warning about hosting. Response time creeping upwards, or connection failures appearing, usually shows here before anyone complains about the site feeling slow. For a site on shared hosting — common for smaller businesses in Nepal — that signal is worth watching, because a server that struggles under a crawler is also struggling under real visitors.
Where crawl stats go wrong
The most common misreading is treating more crawling as better performance. Heavy crawling can mean a healthy, frequently updated site, or it can mean the crawler is stuck in endless filter combinations and calendar pages, burning crawl budget on addresses you would never want indexed. Volume alone tells you nothing without knowing what was requested.
Day-to-day movement is the other trap. Requests naturally rise and fall, and a single quiet day means very little. What matters is a sustained direction, or a sudden change that lines up with something you did.
How to act on it
Start with host status, because a fetch failure there invalidates everything below it. Then read the response breakdown: a growing share of server errors or missing pages means the crawler is meeting problems your visitors probably meet too, and those are worth fixing before anything to do with content.
If the file type split shows the crawler spending most of its effort on images and scripts rather than pages, look at what is being requested and whether it needs to be. When the picture is unclear, server logs record every request from every crawler and give the detail this report summarises. Persistent crawl waste, slow responses and error patterns are all technical SEO problems, and they are usually fixed at server or template level rather than page by page.