Core Web Vitals Report in Search Console: Read It and Prioritize Fixes

The core web vitals report in Search Console is different from a speed test. A speed test loads one page once, in a controlled setup, and gives you a score. The report summarizes what real visitors experienced on your site, grouped into sets of similar pages and labeled Good, Need improvement or Poor. That makes it excellent for spotting site-wide patterns and poor at answering "how fast is this one URL right now?"

This guide is for site owners and developers who have opened the report and want to know what it is telling them. You will learn how the statuses are decided, what the groups mean, why some sites see "No data available", how to turn the list into a short fix order, and how the 28-day validation window works.

The report shows an experience, not a verdict about rankings. Google recommends good Core Web Vitals as part of a good user experience, but this guide does not promise any ranking or traffic change from improving them.

Before you begin

You need a verified Search Console property. If your site is new, or the property is new, expect to wait: the report relies on public field data that takes time to appear. You also need a way to test individual pages and make changes, which usually means a developer or access to your theme or build setup.

This work carries more risk than reading other reports because the fixes change how pages load. Test on a staging copy where you can, and keep a backup of templates and scripts before editing. If you are not set up yet, start with Set Up Google Search Console.

What the report measures

The report is built on three metrics, each with a Good and a Poor boundary published by Google:

Metric	What it measures	Good	Need improvement	Poor
Largest Contentful Paint (LCP)	Loading: when the largest visible element renders	2.5 s or less	up to 4 s	over 4 s
Interaction to Next Paint (INP)	Responsiveness to clicks, taps and key presses	200 ms or less	up to 500 ms	over 500 ms
Cumulative Layout Shift (CLS)	Visual stability: unexpected layout movement	0.1 or less	up to 0.25	over 0.25

The numbers come from real usage data, often called field data, collected in the Chrome User Experience Report (CrUX). Each value shown for a group is the 75th percentile: the value that 75% of visits met or beat in the last 28 days. A URL group's status is its worst metric. If a group has Poor CLS and Good INP, the group is Poor.

Step-by-step instructions

Step 1: Open the core web vitals report and choose a device

Open the Core Web Vitals report for your property. The overview page splits data by Mobile and Desktop and shows trend charts for URLs in each status. Open the report for one device at a time. The same page can be Good on desktop and Poor on mobile, and a mobile problem and a desktop problem often have different causes. For the mobile gap, see Mobile Lighthouse Score Lower Than Desktop.

What success looks like: You know your Poor, Need improvement and Good counts for each device.

Step 2: Understand what is, and is not, in the report

Only indexed URLs can appear. The report is not a complete list of every indexed URL; it shows a sample to help you judge performance. A URL group needs a minimum amount of data for both LCP and CLS to be included, otherwise it is omitted. Data is assigned to the actual URL rather than the canonical URL, which is different from most other Search Console reports.

If you see "No data available", either the property is new, or the CrUX data does not contain enough information for that device type. It can take a few days after a property is created before existing CrUX data shows up. Sites with little traffic may not have enough data.

What success looks like: You can explain why a missing page or device is missing.

Step 3: Read the groups, not single pages

Search Console groups pages with a similar user experience, on the assumption that they share a framework and so share causes. The status applies to the whole group. Some URLs inside may do better or worse, but 75% of visits to the group had the status shown.

When a group lacks enough data, Search Console creates a wider origin group covering every URL under the same protocol, host and port, for example all of https://m.example.com. The origin group includes URLs even if they also belong to another group, and http:// and https:// count as separate origins.

Open a row in the "Why URLs aren't considered good" table to reach the issue details page. Each example URL stands for a group, and the table is limited to 200 rows. Group URLs are listed by impressions, highest first, so the top ones influence the status most.

What success looks like: You can name your worst groups by template or page type, such as "product pages" or "blog posts".

Step 4: Rank the work

Google recommends fixing everything labeled Poor first. Within a status, prioritize issues that affect the most URLs or your most important URLs. Need improvement is worth fixing but less urgent than Poor.

Do not be confused by totals. The chart counts each URL once, for its slowest issue. The table counts every issue attached to a URL, so one URL with a Poor and a Need improvement issue appears in both rows of the table but once in the chart.

A simple ranking:

Poor groups with the most URLs.
Poor groups containing your highest-traffic pages.
Need improvement groups on key pages.

What success looks like: You have a short, ordered list of groups, each with one metric to fix.

Step 5: Find the cause with a page-level test

The report points to groups; it does not explain causes. Click an example URL to open a PageSpeed Insights test, or use Lighthouse in Chrome. Keep two differences in mind. The report combines URLs into groups, while PageSpeed Insights usually shows an individual URL, which may be an outlier. The report treats URLs with different parameters as distinct pages, while PageSpeed Insights strips parameters.

Then work on the metric that is failing:

Lab tools, such as Lighthouse, run under fixed conditions and can disagree with field data. That is normal and not a sign that either is wrong. See Improve Lighthouse Performance Without Breaking Your Website.

What success looks like: For each priority group, you have a reproduced problem and a specific change to make.

Step 6: Ship the fix and start tracking

Fix the issue on all URLs in the group before validating. Then, on the issue details page, click Start Tracking. This starts a 28-day monitoring session. If the issue is absent from every URL during the window, it is considered fixed. The presence of the issue on any URL marks the issue as not fixed, though each URL keeps being evaluated for the full 28 days.

Start Tracking does not trigger re-indexing or any other action by Google. It only restarts a four-week monitoring period of CrUX data. If validation fails, fix the remaining URLs and choose Start new validation.

What success looks like: The validation status shows Started, then Passed after the window.

Step 7: Expect delay and noise

Because the data is a rolling 28 days of real visits, a fix does not show instantly. Improvements appear gradually as old visits drop out of the window. Statuses can also change without any edit on your side. Google gives two reasons: a borderline group tipped by a site-wide event such as a traffic surge or a slow image service, or a change in your visitor mix, such as a new browser version or more users on slower networks.

What success looks like: You review the report at a steady interval, such as monthly, not daily.

Final verification checklist

You reviewed Mobile and Desktop separately.
You know which groups are Poor and which metric makes them Poor.
Fixes were tested on a representative example URL of each group.
Start Tracking was clicked only after the fix reached every URL in the group.
The 28-day window is noted in your calendar.
You did not use the report to judge a single URL.

Common mistakes to avoid

Treating the report like a speed test. It reflects real visits over 28 days. Use a page-level test to reproduce a problem.
Fixing one URL in a group. The group status is shared. Fix the template or shared resource.
Chasing a Lighthouse score instead of the failing metric. The report uses LCP, INP and CLS only.
Clicking Start Tracking too early. A remaining instance on any URL means a failed validation.
Expecting instant changes. Field data is a rolling window. Wait for it.
Ignoring the device split. A mobile problem will not be found by testing only on a desktop.
Assuming the report is a complete URL list. It is a sample of indexed pages with enough data.

Frequently asked questions

Why does my site show "No data available"?

Either the property is new, or there is not enough CrUX data for that device type. Wait a few days for a new property, and note that sites with little traffic may not have enough data.

Which metrics decide the status?

LCP, INP and CLS. A group's status is its worst-performing metric.

Does Start Tracking ask Google to recrawl my pages?

No. It starts a 28-day monitoring period using CrUX data and does not trigger re-indexing.

Why does PageSpeed Insights show different numbers?

It usually reports on one URL, strips parameters, and can combine lab and field data. The report shows grouped field data.

Do browsers other than Chrome count?

CrUX data comes from Chrome users who opted in. Chrome on iOS is not included, because it uses the underlying WebKit engine. Your own analytics may include other browsers, so the numbers will differ.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.