Where do Core Web Vitals data in Search Console really come from?

Does Search Console create its own Core Web Vitals metrics?

No, and this is a crucial point that many SEO professionals overlook. Search Console does not perform any proprietary calculations for Core Web Vitals. It simply displays the data collected by the Chrome User Experience Report (CrUX), a public database powered by real Chrome users who consent to sharing their usage statistics.

Practically speaking, this means that the LCP, FID, and CLS scores you see in Search Console reflect the actual experience of your Chrome visitors, not a lab simulation. This is known as field data — as opposed to lab data from Lighthouse or PageSpeed Insights in test mode.

Why don't my monitoring tools match the numbers from Search Console?

Because your Real User Monitoring (RUM) tools may capture all browsers — Safari, Firefox, Edge — while CrUX only collects data from Chrome. If 40% of your traffic comes from Safari, you are comparing two different populations.

Another factor is the publication delay. CrUX aggregates data over a rolling 28-day period and publishes it with a lag. A spike in slowness yesterday will not instantaneously appear in Search Console. Thus, your real-time tools may show degradation that CrUX hasn’t yet incorporated.

What should I do if Search Console reports no data for my site?

This means your site has not reached the minimum Chrome traffic threshold required by CrUX. Google does not publish the exact number, but it is estimated that several thousand Chrome visitors per month are needed for a URL or group of URLs to enter the dataset.

In this case, Search Console displays “Insufficient data.” You can still query the CrUX API directly to check if some isolated pages have data, or use PageSpeed Insights, which sometimes displays CrUX data even when Search Console remains silent.

• Search Console = showcase of CrUX data, not a standalone measurement tool
• Field data reflects real Chrome users over a rolling 28-day period
• No CrUX data = insufficient traffic, not necessarily a performance issue
• To investigate a discrepancy, cross-reference CrUX API, PageSpeed Insights, and your own RUM tools
• Lab data (Lighthouse) and field data (CrUX) measure different things — do not confuse them

Is this statement consistent with what we observe in the field?

Yes, and it is one of the few assertions from Google where the mechanics are transparent and publicly verifiable. CrUX is an open data repository — anyone can query the API or download BigQuery datasets. Therefore, we can verify that Search Console displays exactly the same figures as CrUX for a given URL.

What is less clear is how Google utilizes this data in its ranking algorithm. We know that Core Web Vitals are a ranking signal since the Page Experience Update, but Google does not specify if an LCP of 2.4s is penalized differently from an LCP of 2.6s. [To be verified]: the marginal impact of small variations in the “Good / Needs Improvement / Poor” thresholds.

What nuances should be applied to this statement?

The first nuance is that CrUX aggregates at the domain, origin, and URL level. Search Console displays data grouped by similar URLs, which can mask disparities. A super-fast page could be drowned in a group where other pages are slow.

The second nuance is that CrUX data is sensitive to geographical distribution and devices. If your Chrome traffic primarily comes from countries with slow connections, your CrUX scores will be poor even if your server is optimized. Google does not weight by region — it aggregates everything.

In what cases does this rule not apply?

If you have blocked Chrome's consent to collect usage statistics in your scripts (rare, but possible through aggressive CSP policies), your users do not send CrUX data. As a result, Search Console remains empty while your site has traffic.

Another edge case is intranet sites or those behind strict authentication. CrUX only collects publicly accessible pages without login. If your site is a B2B SaaS with all content behind a login, you will never have CrUX data, even with millions of Chrome users.

What concrete actions should I take if my Search Console data diverges from my RUM tools?

Firstly, check the measured population. Export your RUM data and filter only for Chrome desktop + mobile traffic. Then compare this sub-population with the CrUX figures via PageSpeed Insights or the CrUX API. If the discrepancy persists, it is likely a measurement period issue — CrUX aggregates over a rolling 28-day period, while your tools may be on a 7-day basis.

Next, query the CrUX API directly for your critical URLs. You can obtain more granular data than in Search Console — especially the distribution of the P75 percentiles, which is the threshold Google uses to classify a URL as “Good / Needs Improvement / Poor.” If your P75 is just above the threshold, a small optimization could shift the entire page into the green.

What mistakes should I avoid when analyzing Core Web Vitals?

Mistake #1: focusing solely on Lighthouse. Lighthouse measures in a lab, under controlled conditions — often far better than the real-world situation. A Lighthouse score of 90+ does not guarantee a “Good” CrUX. What matters to Google is the actual user experience, not the synthetic test.

Mistake #2: ignoring device segmentation. CrUX separates mobile and desktop data. If your mobile LCP is poor but your desktop is excellent, Search Console may display “Needs Improvement” overall. Dive into the details to target your optimizations — often, it’s mobile that drags scores down.

How can I verify that my site is being tracked by CrUX?

Go to PageSpeed Insights and test a URL. If the section “Discover what your real users experience” appears with data over 28 days, your site is in CrUX. If you only see lab data (Lighthouse), it means you do not have enough Chrome traffic or your pages are not public.

You can also use the CrUX API via BigQuery for massive analyses. Google publishes monthly datasets — you can cross-reference your URLs with CrUX data and identify which pages are tracked. This is particularly useful for large sites with thousands of URLs.

• Filter your RUM data to keep only Chrome traffic and compare over a rolling 28-day period
• Query the CrUX API for your strategic URLs and analyze the P75 distribution
• Do not rely solely on Lighthouse — prioritize field data for your optimizations
• Segment your analyses by device (mobile vs desktop) to target the real friction points
• Verify via PageSpeed Insights that your main pages are indeed present in CrUX
• If you have no CrUX data, focus on increasing Chrome traffic or making your contents publicly accessible