Core Web Vitals: not enough data in Search Console

What "No data available" means

The Core Web Vitals report in Search Console does not measure your site. It reads the Chrome User Experience Report (CrUX), a public dataset of page loads from real Chrome users. When CrUX has too few visits for your pages, Search Console has nothing to show. You get "No data available" or an empty chart for mobile, desktop or both.

That does not mean your site is slow. It does not mean your site is fast either. It means Google does not know, and neither do you.

Why CrUX has no data for your site

First of all, there is a traffic threshold. A page or an origin (protocol plus domain, like https://www.example.com) has to be "sufficiently popular" before CrUX reports it. Google does not publish the number. It only says the threshold is high enough to be confident in the distribution.

Also, only a small part of your visitors count. CrUX only collects from Chrome users who turned on usage statistics, sync their browser history and have no sync passphrase. It only counts Chrome on desktop and Android. Chrome on iOS does not count. Safari, Firefox, Edge and in-app browsers do not count. On a site with a lot of iPhone traffic, most visitors never reach the dataset.

Mobile and desktop are counted separately. A site can have desktop data and "No data available" on mobile, or the other way around. The empty one is the device with less Chrome traffic.

The page itself has to qualify. CrUX skips pages that return anything other than a 200 status after redirects. It also skips pages with a noindex meta tag or an X-Robots-Tag: noindex header. Search Console adds one more rule: only indexed URLs appear in the report.

Finally, a new Search Console property shows no data until Search Console has processed it. That one fixes itself.

Pages without data get the origin's score

This part confuses people more than the empty report. Search Console groups similar URLs. When a group does not have enough data, Search Console uses an origin group instead: every URL on the same protocol, host and port. A page with no data of its own can show up as "Good" or "Poor" because of the rest of your site.

Your homepage and your blog get most of the traffic, so they decide the origin number. Your product pages or your checkout can be much slower, and Search Console will not show it. (That is also why a sitewide CrUX number is a bad target. It is weighted by traffic, not by the pages that make you money.)

Waiting and Lighthouse will not fix this

The usual advice is to run PageSpeed Insights or Lighthouse while you wait for data. That advice is useless here. A lab test loads the page once, on one simulated device and one simulated network, with an empty cache. It does not tell you what your visitors get.

Lab tests miss the problems that fail in the field. INP needs real clicks and taps on real devices, and Lighthouse does not click anything. CLS shows up when a visitor scrolls, when the cookie banner appears, when an ad loads late. LCP depends on the visitor's phone, network and distance to your CDN. None of that shows up when you run Lighthouse on your own laptop.

Waiting only works if your traffic grows. CrUX looks at the last 28 days of visits (and the delay is shorter than most people think, see why the 28 day delay is a myth). If you have too few qualifying Chrome visits this month, you will have too few next month.

Measure your own visitors with RUM

Real user monitoring (RUM) measures the Core Web Vitals in the browser of every visitor and sends the numbers to you. It is the same kind of field data as CrUX, without the traffic threshold and without the Chrome filter.

That changes what you can see:

• Every page, including the ones with 50 visits a month.
• Every browser that reports the metric. Since Safari 26.2 (December 2025), Safari measures LCP and INP, so your iPhone visitors finally show up. CrUX still leaves them out.
• The element behind the number: the LCP image, the button behind a slow interaction, the block that shifted.
• Results within minutes of a deploy, not a 28 day average.

Core/Dash is the RUM tool I built for this. You add one script tag (or install the WordPress plugin) and data comes in with the first pageview. Core/Dash sets no cookies and collects no personal data, so it does not need a consent banner. That matters on a small site: every visitor who ignores your cookie banner is a visitor you would not measure. Plans start at $16 a month billed annually, and the 14-day trial needs no credit card.

Once CrUX does pick up your site, keep the RUM data. Search Console tells you that a group of URLs is slow. RUM tells you which page, which element and which visitors.

Check what CrUX has on you right now

Before you change anything, check whether CrUX has data for your origin at all. The CrUX History tool on corewebvitals.io shows the historical CrUX data for any site. If mobile comes back empty there, Search Console will stay empty on mobile too.

See also: installing Core/Dash, the browser dimension for the visitors CrUX leaves out, and the device type dimension for splitting mobile and desktop.

Sources: Search Console Help: Core Web Vitals report, CrUX methodology, Safari 26.2 adds LCP and INP.