Core Web Vitals and Indexing: What Really Matters

Core Web Vitals do not decide whether a page gets indexed. They are a ranking signal of modest weight, used by Google to separate pages of similar relevance. What does affect crawling, and through it indexing speed, is something related but different: how quickly and reliably your server responds to Googlebot. A site can fail every Core Web Vital and be fully indexed, and a site with perfect scores can have half its pages stuck if the server throttles Googlebot.

Keeping those two ideas apart saves a lot of wasted effort.

The three metrics, briefly

Metric	Measures	Good	Poor
Largest Contentful Paint (LCP)	Loading: when the largest visible element is rendered	2.5 s or less	over 4 s
Interaction to Next Paint (INP)	Responsiveness: delay between a user interaction and the next visual update	200 ms or less	over 500 ms
Cumulative Layout Shift (CLS)	Visual stability: how much content jumps around	0.1 or less	over 0.25

Google assesses them at the 75th percentile of real visits, from the Chrome User Experience Report (CrUX), over a rolling 28 day window. INP replaced First Input Delay as a Core Web Vital in March 2024.

Two consequences of "real users":

• Googlebot's crawl is not the measurement. The numbers come from people using Chrome.
• A page with few visitors has no field data. Google then may fall back on data for similar pages or the whole origin, or has nothing at all. No data is not a penalty.

What Google says about ranking

Google's page experience documentation states that Core Web Vitals are used by its ranking systems. The same documentation says, in effect, that Google tries to show the most relevant content even when the page experience is sub-par, and that page experience matters more when there is a lot of similarly helpful content to choose from.

How to read that in practice:

• Going from "Poor" to "Good" will not lift a weak page over better content.
• In competitive results where several pages answer the query equally well, it can be the difference.
• There is no bonus for going from good to excellent. An LCP of 1.2 s does not outrank an LCP of 2.3 s on speed grounds.
• Chasing a Lighthouse score of 100 for SEO reasons is poor use of time. Do it for users and conversions, where speed has clear value.

What Google says about indexing

Nothing in Google's documentation makes Core Web Vitals a condition for indexing. The indexing pipeline looks at whether the page can be fetched, whether it can be rendered, whether it is allowed to be indexed, whether it is a duplicate and whether it is worth keeping. Visual stability and interaction latency are not part of that.

So if your question is "my pages are not indexed, should I fix Core Web Vitals?", the answer is no, look elsewhere first: why is my page not indexed.

Where speed really does affect indexing

Server response time and crawl capacity

Google's crawl budget documentation describes a crawl capacity limit: the maximum number of parallel connections and the delay between fetches that Googlebot uses for your site. It goes up when the site responds quickly for a while and goes down when the site slows or returns server errors.

The same document says that making a site faster improves the user experience and increases crawl rate, and that for Googlebot a speedy site is a sign of healthy servers.

This concerns the raw HTTP response, not LCP or CLS. The relevant numbers are time to first byte and total download time for the HTML and resources that Googlebot requests.

Who should care:

Site	Does server speed limit indexing?
Small site, a few hundred pages	Rarely. Google can crawl it all even on a slow server
Medium site, tens of thousands of URLs	Sometimes, especially with slow dynamic pages
Large site, hundreds of thousands of URLs or more	Often. Crawl capacity decides how fast new and updated pages are picked up

See crawl budget explained for the full model.

How to check it

Search Console > Settings > Crawl stats.

• Average response time. Look at the trend. Google gives no official threshold. In our experience, a few hundred milliseconds is healthy and sustained values above a second coincide with reduced crawling on larger sites.
• Total crawl requests against response time. A classic pattern: response time rises, crawl requests drop a few days later.
• Host status. Shows whether Google had problems with robots.txt fetching, DNS resolution or server connectivity in the last 90 days.
• By response. A growing share of 5xx or 429 responses makes Googlebot slow down.

For a single URL, the HTTP Headers Checker shows the status and caching headers the server sends, which is useful for spotting pages that bypass your cache.

Rendering cost

Google renders pages with headless Chrome. Heavy JavaScript does not give you a "slow" label, but it has side effects:

• Rendering is queued separately, so content that needs JavaScript is indexed later than content in the HTML.
• If API calls needed for the content time out or fail during rendering, Google indexes a page with missing content. That can lead to "Soft 404" or "Crawled - currently not indexed".
• Every script, stylesheet and API call counts towards crawling of your host.

Server-side rendering or static generation of the main content fixes all three, and usually improves LCP along the way. More in JavaScript SEO: rendering and indexing.

Fixes that help both crawling and Core Web Vitals

Some work pays twice. Prioritise it.

1. Cache HTML at the edge or on the server. A cached page answers Googlebot in tens of milliseconds and users get a faster LCP. Check that pages send cacheable headers and that query string junk does not bypass the cache.
2. Fix slow database queries on templates with many URLs. Category, search and listing pages are the usual culprits. One slow template multiplied by 50,000 URLs is what drags the crawl stats average down.
3. Serve properly sized, compressed images (WebP or AVIF), with width and height attributes. Helps LCP and CLS and cuts bytes for Googlebot.
4. Remove redirect chains. Every hop is a separate request for Googlebot and a delay for users. Check with the Redirect Checker.
5. Return 304 Not Modified for unchanged content when Googlebot sends If-Modified-Since or If-None-Match. Google's documentation recommends supporting these headers to save resources.
6. Do not let bot protection throttle Googlebot. Rate limits that return 429 or 503 to Googlebot reduce crawl capacity directly. Verify real Googlebot by reverse DNS or Google's published IP ranges and exempt it.
7. Reduce URL waste. Parameters, session IDs and faceted combinations consume crawl requests that your real pages could have had. See faceted navigation and indexing.

Fixes that help Core Web Vitals only

Worth doing for users and for the ranking tiebreak, with no effect on indexing:

LCP

• Preload the hero image and do not lazy-load it: <img src="hero.avif" fetchpriority="high" width="1200" height="600" alt="...">
• Inline critical CSS, defer the rest
• Avoid rendering the LCP element with client-side JavaScript

INP

• Break up long JavaScript tasks
• Remove unused third-party scripts, and load the remaining ones after interaction or with defer
• Keep DOM size reasonable

CLS

• Set dimensions on images, videos, ads and embeds
• Reserve space for banners and cookie notices instead of pushing content down
• Use font-display: swap with matched fallback font metrics

How to measure properly

Tool	Data type	Use it for
Search Console > Core Web Vitals	Field (CrUX), grouped by similar URLs	Finding which templates fail for real users
PageSpeed Insights	Field for the URL and origin, plus lab	Checking one URL, seeing both data types side by side
Lighthouse / Chrome DevTools	Lab only	Debugging during development
CrUX dashboard or BigQuery	Field, historic	Trends over months
Search Console > Crawl stats	Googlebot's own experience	Server response time and crawl health

Remember that lab scores and field data often disagree. Ranking uses field data. After a fix, the Search Console report takes up to 28 days to reflect it fully, because of the rolling window. You can click Validate fix in the report to start a monitoring period.

Misconceptions worth retiring

"Google will not index slow pages." Not true. There is no speed threshold for indexing.

"A PageSpeed score of 90+ is needed to rank." The Lighthouse performance score is not used by Google Search. Core Web Vitals field data is, modestly.

"Googlebot measures my Core Web Vitals." It does not. CrUX data comes from Chrome users.

"No CrUX data means Google thinks my site is slow." It means there are not enough Chrome visits to report. Nothing more.

"Improving Core Web Vitals will fix Discovered, currently not indexed." Only if the real cause is server slowness, in which case the fix is server response time, not CLS. The usual causes are covered in discovered, currently not indexed.

Where to put your effort

If pages are not getting indexed: check blocks, canonicals, content quality and internal links first, then Crawl stats for response time and errors.

If pages are indexed and ranking on page one or two against similar content: Core Web Vitals are worth improving, together with the content itself.

If the site is large and new pages take weeks to be picked up: server response time is one of the few levers you control directly, and it is worth real engineering time.