Do Core Web Vitals Affect How Often Google Crawls Your Site?

A developer fixes the layout shift, trims the JavaScript, and gets every page into the green. A month later somebody asks why the new pages are still taking a week to appear in search, and whether the Core Web Vitals work should have helped with that.

It should not have, and it did not. Crawling and Core Web Vitals are two systems that share a vocabulary and almost nothing else.

Do Core Web Vitals change how often Google crawls a site?

No. Crawl scheduling is decided from how your server behaves when it is asked for a page, and the Core Web Vitals metrics are measured in real visitors' browsers after the page has already been delivered.

The separation is mechanical rather than a matter of policy. Two of the three metrics cannot be observed by a crawler at all: interaction latency requires somebody to interact, and layout shift requires a viewport that scrolls and renders over time. A crawler fetching a URL does neither. There is no measurement to feed into a scheduling decision even in principle.

What actually sets your crawl rate?

Two things, working against each other: how much crawling your server can absorb, and how much Google wants to crawl you.

Capacity is a health measurement. Google's crawlers raise their request rate while responses stay fast and successful, and back off when response times climb or when the server starts returning errors and rate-limit responses. The behavior is self-regulating and deliberately conservative — the crawler's stated priority is not to take your site down.

Demand is about worth. Popular URLs and URLs that change get revisited more; pages nothing links to and nothing updates get revisited less. Neither half of that has an input where a rendering metric could go.

Why does the confusion survive?

Because both are reported as speed, and because one shared cause sits underneath them: server response time.

A slow server delays the first byte, which delays everything the browser does afterward, which pushes out the largest paint. The same slow response makes crawlers throttle back. One root cause, two symptoms, two dashboards — and a team that fixes it sees both numbers improve at once, which is excellent evidence for a relationship that does not exist.

The reverse case is the clearer one. Compressing a hero image improves the largest paint and does nothing whatsoever to crawl rate, because the crawler was never waiting on that image to decide anything.

Which speed problems affect which system?

Sorting them once makes the distinction hard to lose.

Only two rows are in both columns, and neither is what a Core Web Vitals report puts at the top of its recommendations.

How do you tell whether your server is the constraint?

The crawl stats report in Google Search Console answers this directly, and it is the only place that does.

Put average response time next to total crawl requests over the same months. Response time climbing while requests fall is a capacity limit — the crawler noticed your server struggling and eased off. Requests flat while response time is comfortable means capacity is not what is holding you back, and the problem is demand or discovery instead.

Check the response codes in the same report. A meaningful share of server errors or rate-limit responses is the strongest possible version of the capacity signal, and it usually points at a specific slow template or an origin without enough caching in front of it.

Does JavaScript rendering change the answer?

It changes what crawling costs you, without changing what schedules it. Rendering happens after the fetch, in a separate step, and heavy pages are expensive in a different way.

Every script, stylesheet, font, and image a page needs is its own request. A template that pulls in forty resources spends forty times as much of your crawl allowance per page as one that pulls in a handful, and on a large site that arithmetic is what decides whether the deep pages get visited this month. The fix is fewer files and better caching — which is a crawl-efficiency fix that happens to look like a performance fix.

What should you fix if crawling is the constraint?

Work in the order the two limits actually apply. Capacity first, because nothing else matters while the crawler is backing off, then waste, then demand.

1. Response time and errors. Cache at the edge, fix the slowest templates, and stop returning errors under load.
2. Wasted requests. Parameter variants, faceted combinations, and endless calendar pages consume the allowance without earning anything.
3. Discovery. Internal links from pages that are crawled often, and sitemaps whose dates are honest about what changed.
4. Freshness signals. Pages that genuinely change get revisited; pages with a touched timestamp and identical content do not, for long.

None of that appears in a Core Web Vitals report, and the vitals work is still worth doing — it is a ranking and organic search conversion argument, made on its own terms.

So decide which problem you have before you pick the fix. If pages are slow for visitors, the vitals report is the right document. If pages are not being crawled, open the crawl stats instead — and if the two sets of recommendations barely overlap, that is the systems working as designed rather than a contradiction to resolve.