Core Web Vitals showing “not enough data” in Search Console is the single most common thing I get asked about that turns out not to be a problem. The report opens, it says “No data available”, and the reasonable assumption is that something is broken. Usually nothing is broken. The report is telling you something true about your traffic, not something wrong about your site.
Here is what it is actually reading from, what has to be true before a URL appears in it at all, and the one number everybody quotes that Google has never published.
What the report is built from
The Core Web Vitals report is not a measurement of your site. It is a read of the Chrome User Experience Report, the field dataset Google assembles from real Chrome users, and every limit in it comes from that dataset rather than from Search Console.
Google’s own help page says it plainly: “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).”
Two properties of CrUX matter more than anything else. It is a “28-day rolling average of aggregated metrics”, and it is “updated daily around 04:00 UTC”. So the report is always describing the last four weeks in aggregate, which is why a site that got faster last Tuesday sees nothing move for weeks.
The number nobody can source
Search the phrase and you will be told, repeatedly and with confidence, that you need 100 unique Chrome users per device type per 28 days before data appears. Some posts say 75 samples. I went looking for where that came from and it does not come from Google.
The CrUX methodology page addresses this directly: “A page is determined to be sufficiently popular if it has a minimum number of visitors… An exact number is not disclosed, but it has been chosen to ensure that we have enough samples to be confident in the statistical distributions for included pages. The minimum number is the same for pages and origins.”
An exact number is not disclosed. That is the state of it, and every specific figure you have read is somebody’s estimate that lost its hedging somewhere along the way. I am not going to add another one. What the sentence does tell you, and it is useful, is that the threshold for an origin is the same as the threshold for a page, which is why the fallback described below helps far less than people expect.
Everything a URL has to pass first
Gate one is the one that connects this to the rest of Search Console, and it is the reason I care about this report at all. “Only indexed URLs can appear in this report.” A URL sitting in crawled and currently not indexed will never have Core Web Vitals data no matter how fast it is, which means an unexpectedly empty report is occasionally a symptom of an indexing problem rather than a traffic one. If that is a live possibility on your site, the Page indexing report is the place to settle it, and the full list of indexing statuses will tell you which bucket the URLs are in.
Gate four is the one that quietly explains whole categories of site. If your audience is on iPhones, your CrUX coverage is thinner than your analytics suggests, because Chrome on iOS is excluded outright. Same for a developer audience on Edge, and same for anything loaded inside an Android app’s WebView. These are not edge cases, and none of them appear in the report’s error message.
Gate five is the one that produces the confusing half-empty state. Google: “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group.” So you can end up looking at a report that is technically populated but is describing your whole origin rather than the pages you asked about.
What to do when the report is empty
In order, and the order matters:
- Check PageSpeed Insights for the same URL. PSI falls back where Search Console does not always make the fallback obvious. Google’s documentation on this is explicit: “A page might not have sufficient data if it has been recently published or has too few samples from real users. When this happens, PSI will fall back to origin-level granularity… Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data.” If PSI shows origin-level field data, you have field data, just not at the resolution you wanted.
- Query the CrUX API for the URL and then for the origin. This is the check that tells you which tier actually holds samples, and it answers in seconds what guessing at the report will not.
- Fall back to lab data, and know what it cannot tell you. Lighthouse will happily give you a score with no real users at all. Google’s guidance on when to trust which is direct: “if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” And there is a specific hole worth remembering, which is that Interaction to Next Paint has no lab equivalent, because it measures real interactions that a synthetic run does not perform.
- Confirm the URL is indexed, per gate one, if anything about the emptiness surprises you.
- Then stop. This is the step people skip.
The part I say to clients
An empty Core Web Vitals report on a low-traffic site is not a defect and there is nothing in it to fix. It means too few eligible Chrome users visited those URLs in 28 days for Google to publish a distribution without exposing individuals. That is a privacy floor doing its job.
This site is a working example. Search Console shows 4,517 impressions and 28 clicks across the 28 days to 5 September 2026. A property at that scale is not going to clear a per-URL field-data threshold on most of its pages, and no amount of caching plugins will change that, because the missing ingredient is visitors rather than milliseconds.
I treat this exactly the way I treat the gaps in the crawl stats report and the lag in Search Console’s data generally. These are reports about your site, assembled on Google’s side, with their own rules about what they will and will not show. Reading “no data” as “no problem detected” is wrong, and reading it as “problem detected” is equally wrong. It means the report has nothing to say, which is a third thing, and on a small site it is the expected thing.
One clarification while I am here, since it comes up in the same conversation every time. Core Web Vitals is not a confirmed standalone ranking factor, and Google’s wording is deliberately softer than the way it gets repeated: “We highly recommend site owners achieve good Core Web Vitals for success with Search… This, along with other page experience aspects, aligns with what our core ranking systems seek to reward.” Recommend and align are the words on the page. The three metrics as of today are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, assessed at the 75th percentile of page loads, with INP having replaced First Input Delay in 2024.
Sources
- Google Search Console Help, Core Web Vitals report, for the “No data available” explanation, the URL group minimum and origin group fallback, “Only indexed URLs can appear in this report” and “Data is assigned to the actual URL, not the canonical URL”, checked 6 September 2026
- Chrome for Developers, CrUX methodology, for “An exact number is not disclosed” on the popularity threshold, the sameness of the page and origin minimums, the user eligibility criteria, and the exclusions of Chrome on iOS, Android WebView and other Chromium browsers, checked 6 September 2026
- Chrome for Developers, CrUX API, for the 28-day rolling average and the daily update around 04:00 UTC, checked 6 September 2026
- Google, About PageSpeed Insights, for the origin-level fallback when a page has too few samples, checked 6 September 2026
- Google Search Central, Core Web Vitals and Google Search results, for the current metric set and the exact ranking wording, checked 6 September 2026
- web.dev, Web Vitals, for the LCP, INP and CLS thresholds at the 75th percentile and INP becoming a stable Core Web Vital in 2024, checked 6 September 2026
- web.dev, Lab and field data differences, for the guidance to prioritize using field data where both exist, checked 6 September 2026
- Search Console performance data for sc-domain:shahidali.co, 9 August to 5 September 2026, pulled 6 September 2026