Site-origin responses are slow during the crawl
In the reportSlow host responses risk Googlebot crawl capacity
host_slow_crawl_budget_risk · Review item
This appears when your site answered our crawler slowly: at the 75th percentile, the measured response time exceeded the limit, 3 seconds by default. Google says it crawls less when a site's responses get slower. Look into your server's capacity and its slowest pages.
Severity: Medium. For review: it is one audit's measurement from our crawler, not Googlebot's.
Why it matters
Google's crawl budget guide says that when a site slows down, with longer response times, or answers with server errors, its crawl limit goes down and Google crawls less. The guide is written for large or fast-changing sites; a small site rarely needs to think about crawl budget.
What to do
- Look at the finding: it shows the 75th-percentile time, the number of responses and every time measured.
- Check your hosting: server load, slow database queries and pages generated without a cache are the usual causes.
- Compare with your server logs or the crawl stats in Search Console to see whether Googlebot meets the same delays.
When to leave it as it is: if your site is small, or the slowness came from a one-off event such as a deploy or a backup during the audit, you can leave it and see whether the next audit repeats it.
What we read
No extra requests are made: we use the audit's own requests for your pages, retries included, and leave out requests for robots.txt, sitemap files and other checks. Each response is timed from physical dispatch until the transport finishes reading it. A terminal reply whose body is not read is timed until the transport returns; only a redirected hop ends at the received headers. Our pacing waits and database checks are excluded.
The site is reported when, over at least the minimum number of responses, 10 by default, the 75th-percentile time is above the limit, 3,000 milliseconds by default. Both are audit settings, recorded with each audit.
With fewer responses than the minimum, the check can only clear the site, never report it, and only after an audit of the whole site that fetched every page it found, without leaving pages out because of the page limit and with no request left unanswered: the site is clear when every measured response time was within the limit; otherwise the check cannot conclude. An audit of selected pages cannot conclude with fewer responses. In every case the check cannot conclude when a single crawled address redirected, even only to add a trailing slash or to move from http:// to https://, or when an answer came from another host: then not every request can be put down to your server.
Example & evidence
Illustrative example — one audit's timings, not a live audit.
An audit of https://bakery.example/ timed 40 responses from the site:
75th percentile transport response time: 4,210 ms
responses timed: 40
limit: 3,000 msAt least a quarter of the responses took 4.2 seconds or more in the transport, above the 3-second limit, so the site is reported with every time measured.
A possible correction: cache generated pages, so that most transport response times stay within a second.
Confirm & check again
Check for yourself: open a few pages with your browser's developer tools on the Network tab and inspect the document request's duration, including the download. Compare it with server logs; browser and crawler measurements can differ.
Check again: Full audit — run a new audit of the site. The finding is confirmed fixed only when that audit times at least the minimum number of responses, none of them redirected, and the 75th-percentile time is within the limit, or, on a small site, when an audit of the whole site fetches every page it finds with fewer responses, with no redirect and no request left unanswered, and every measured response time is within the limit. An audit of selected pages with fewer responses than the minimum, or any audit in which a crawled address redirects, cannot confirm it. A higher limit in your audit settings also stops the finding; the finding records the limit it used.
Limits & sources
The times come from our crawler and its network in one audit; they are not Googlebot's and do not show that Google's crawl rate changed. The clock includes connection and response reading, excludes our pacing waits and database checks, and stops when the transport read ends. A body may be capped or omitted, so this is not a promise of a full download. Rendering is not measured. Earlier audits keep the timing values they recorded.
Confidence: Medium because one audit from one place is a short sample of how fast your server answers.
Sources
- Google, Optimize your crawl budget — says that when a site slows down or answers with server errors, its crawl limit goes down and Google crawls less, and addresses the guide to large or fast-changing sites. Checked 28 September 2026.
Editorial review: 3 November 2026