Google sends an email: “New Core Web Vitals issue detected on your site.” You log in to Search Console, find a chart with red and amber bands, a table of issues with names like “LCP issue: longer than 2.5 s (mobile)”, and a count of “similar URLs” in the hundreds. Your site does not have hundreds of pages you think of as different. Where do you even start?
The Core Web Vitals report in Search Console is easier to read than it first looks, once you know what each screen shows, what URL groups are, why some sites see “not enough data”, how validation works and why the numbers take so long to move. None of that fixes the metrics themselves, but it makes sure you fix the right thing.
Finding the Core Web Vitals report in Search Console
In Search Console, open the left-hand menu and look under Experience for Core Web Vitals. You need a verified property; a Domain property covers every version of the site (with and without www, http and https), which is usually what you want.
The report does not run tests of its own. It uses field data from the Chrome User Experience Report: real visits by Chrome users who share usage statistics, gathered over a rolling 28-day period. That one fact explains most of the report’s behaviour, including the slow updates and the gaps for quiet sites. If the idea of field data versus test data is new, how real-user data differs from lab tests sets it out.
The metrics are the three Core Web Vitals, LCP, INP and CLS, judged against Google’s thresholds at the 75th percentile. Our plain explanation of LCP, INP and CLS covers what each one means if you need it.
The overview: two charts, three colours
The first screen has two charts, Mobile and Desktop. Each shows how many URLs fall into Poor, Need improvement and Good over recent months.
A few things to read from the overview before clicking anything:
- Mobile versus desktop. They are measured separately. Most small business sites have more trouble on mobile. Start there unless your audience is almost entirely desktop.
- The trend, not today’s bar. A sudden step from green to amber on a particular date often lines up with a theme update, a new plugin or a new marketing script. Note the date.
- The total count. The URLs here are ones Google has field data for and knows about. It will rarely match your sitemap exactly.
Each chart has an Open report link. That is where the useful detail sits.
The issue table: why URLs are not good
Inside the mobile or desktop report, below the chart, you will find a table listing each issue, the status (Poor or Need improvement), and the number of URLs affected. Issue names spell out the metric, the threshold crossed and the device type.
Two rules about how URLs are counted help here:
- A URL takes the status of its worst metric. If LCP is good and CLS is good but INP needs improvement, the URL counts as Need improvement.
- A URL can appear under more than one issue. A page with both slow LCP and high CLS appears in both rows. So the row counts can add up to more than the total.
Sort your attention by the Poor rows first, then by the number of URLs. An issue affecting a few hundred product pages is usually one shared template, and therefore one fix.
URL groups: why 300 pages count as one problem
Click an issue and you see URL groups rather than a long list of separate pages. Each group has an example URL, a count of similar URLs and a group value for the metric.
Google groups pages that appear to give a similar experience, typically because they share a template: all your blog posts, all product pages, all category pages. The group value is the 75th percentile for the whole group, not for the example page alone.
This grouping is the most practical part of the report. It means you do not need to test three hundred product pages. Pick the example URL, plus one or two others from the group, and investigate those. Fix the template and the whole group should improve together.
Clicking a group shows a sample of URLs from it. Look down the list for patterns. If every URL in a poor group is a product page with a video, or every one is in a particular category, that pattern points straight at the cause.
Taking an example URL into PageSpeed Insights
Once you have an example URL, test it in PageSpeed Insights. The top section shows field data for that URL (if it has enough of its own visits) and for the origin. The lab section underneath runs a test and lists diagnostics, including which element is the LCP and what is shifting.
Search Console tells you what is failing and where. PageSpeed Insights helps you see why on a specific page. Going through that second report section by section is a job of its own, covered in how to read a PageSpeed Insights report.
“Not enough data” and missing pages
Smaller sites often see an empty report, or a message that there is not enough usage data for a device type. This is not an error and not a penalty.
- Why it happens: CrUX only publishes figures when enough real Chrome visits have been recorded in the period. A local business site with modest traffic may not reach that level, especially on desktop.
- Some pages, not all: busy pages may appear while quiet ones never do. Your homepage and top service pages are the most likely to show.
- Only indexed pages: the report is based on pages Google has indexed, so pages blocked from search will not appear even if visitors use them.
What to do instead: rely on PageSpeed Insights lab tests for key pages, check the origin-level field data there if it exists, and test on a real mid-range phone. The absence of data does not mean the pages are fast or slow; it just means Google is not reporting on them.
Validation: telling Google you have fixed something
On each issue’s details page there is a Validate fix button. Press it only after the fix is live on the whole affected template.
Validation does not re-test the page instantly. Google monitors the affected URLs using new field data over about 28 days, because that is the length of the data window. During that time the status shows progress, and it can end as passed or failed. If it fails, the report shows which URLs still have the problem.
Practical points:
- Do not start validation the moment you change a setting. Confirm in the lab, on several example URLs, that the fix holds.
- Do not change other things on the same template during validation if you can avoid it; you will not know what caused the result.
- Write down the date you started. If a later plugin update breaks it again, you will want that history.
Why the report is slow to change
A frequent frustration is “I fixed it last week and Search Console still says poor”. The reason is the 28-day window. Each day, the oldest day of visits drops out and a new one is added. If you improved the site on day one, it takes until roughly the end of that window for all the old, slow visits to have left the figure.
The chart also updates periodically rather than continuously, so a change can take a little longer to appear. Expect a gradual drift from red to amber to green rather than a sudden flip.
If one metric is failing everywhere and you are not sure which to tackle first, what to do when the Core Web Vitals assessment fails sets out an order of work.
How the report fits into your wider speed work
Treat the report as a monthly health check, not a daily dashboard. Look at it after significant changes to the site, after a redesign, and when Google emails you. For how it connects with hosting, caching, images and scripts, the guide to making a website faster gives the wider picture.
Frequently asked questions
Why does Search Console show different numbers from PageSpeed Insights for the same page?
Search Console shows the group value for many similar URLs, while PageSpeed Insights shows field data for one URL or for the whole origin, plus a separate lab test. They also may be updated at slightly different times. Both draw on the same kind of real-user data, so they should agree broadly but rarely match exactly.
Can other people see my site’s Core Web Vitals?
The Search Console report is only visible to people you add to the property. The field data behind it is public, though, so anyone can enter one of your URLs in PageSpeed Insights and see the same real-user figures for that page or your origin, if there is enough data. It is worth knowing that before an agency sends you a screenshot of it.
Can I see Core Web Vitals in Search Console for a brand new site?
Usually not at first. A new site needs enough real Chrome visits over the data period before anything is reported, and pages must be indexed. Until then, the report may be empty. Use lab testing and real phones in the meantime, and check back once traffic has built up.
What happens if a validation fails?
Search Console marks it as failed and shows URLs that still did not meet the threshold. Look at those URLs for something your fix missed, such as a different template, a mobile-only element or a third-party script that only loads on some pages. Fix that, confirm it in the lab, and start validation again.
Search Console tells you which template to look at; changing that template safely is the next job. Our website speed optimisation service can take that on, starting with an audit and a prioritised fix list, and leaving the validation to run once the changes you approved are live.
Next in this series: Field Data vs Lab Data: Which Speed Numbers to Trust
