Article · Core Web Vitals

Core Web Vitals in a client report: what to show and how to explain it

A client sees "Poor" in Search Console and asks whether it is hurting rankings. Report the status Search Console gives each group of pages, per device, say what is being done about it, and answer the ranking question in Google's own words. Includes a status table, client wording and a developer ticket you can copy.

Google documentation checked on 29 October 2026.

What the report groups, and why it uses field data

The Core Web Vitals report in Search Console takes its data from the Chrome User Experience Report (CrUX), which, in the words of Google's help page, gathers "anonymized metrics about performance times from actual users". That is field data: what real visitors experienced, not a test run on one machine.

Know five things about how the report is built before you put it in front of a client:

• Groups, not pages. URLs with a similar user experience are grouped. Google assumes such groups share a common framework, so poor results in a group likely have the same underlying cause. Each example URL stands for a group of similar URLs.
• One device at a time. Mobile and desktop are reported separately. A group can be Good on desktop and Poor on mobile.
• The weakest metric decides. A group's status is the slowest status among its metrics for that device. One Poor metric makes the group Poor.
• 75 percent of visits, last 28 days. A group's LCP, for example, is the time that 75 percent of page requests in the last 28 days met or beat. Data from all locations is combined.
• Indexed pages, sampled. Only indexed URLs can appear, and Google describes the report as showing a sample of pages, not every URL.

Why field data and not a lab test? web.dev describes Core Web Vitals as field metrics first. Lab tools help during development and catch regressions before release, but do not replace field data. The PageSpeed Insights documentation describes its lab data as a simulated load on a single device with fixed network conditions, and its field data as a history of how a URL performed. The two can differ. The Search Console status follows the field data.

The three metrics and their thresholds

Each metric is judged at the 75th percentile of visits, with mobile and desktop counted separately.

Thresholds as listed in Search Console Help and on web.dev, checked on 29 October 2026.

Older reports may show a different metric. web.dev announced that INP would replace First Input Delay (FID) as a Core Web Vital on 12 March 2024, and that FID would be removed from Search Console at that point. Do not put FID and INP in the same column of a long-term comparison.

Good, Need improvement, Poor: what each status tells the client

Search Console labels groups Good, Need improvement and Poor. web.dev and PageSpeed Insights write "needs improvement". Use the label the client will see in the tool you cite, and keep it the same every month.

• Good: the slowest metric for that group and device is in the good range. Say so in one line and move on.
• Need improvement: the slowest metric is between good and poor. Plan it, after the Poor groups.
• Poor: at least one metric is past the poor threshold. Google's help page recommends fixing everything labeled Poor first, then prioritizing by how many URLs are affected or how important they are.

The report's overview chart counts URLs with each status on each day. Use those counts for a one-line summary; use the groups for the detail.

A status can also change when nobody touched the site. Google's help page gives examples: a sharp rise in traffic, a latency change at the service that serves the images, a widely adopted browser update, or more visitors on slower networks. Groups close to a threshold are the ones that tip. Before you tell the client the site got worse, check whether browser, device or location changes line up with the date.

Why a page, or the whole report, can have no data

Expect gaps on low-traffic sites. Google's help page gives these reasons a page, or the whole report, can be missing:

• New property. It can take a few days after a property is created for existing CrUX data to appear.
• Not enough CrUX data for that device type. The report shows "No data available".
• Too little data for a group. If a URL group does not have a minimum amount of data for both LCP and CLS, the URL is left out of the report.
• Not indexed. Only indexed URLs can appear. Check the page in the page indexing report first.
• Sampling. The report shows a sample of pages, so a page you care about may simply not be listed.

When a URL group lacks enough data, Search Console can show an origin group instead: data for all URLs on the same protocol, host and port. http and https count as separate origins. Tell the client when a row describes the whole origin rather than a set of pages.

In the report, call missing data a gap, not a pass or a fail. For numbers on one key page, use PageSpeed Insights. It falls back to origin-level field data when a page has too little, and shows no real-user data when the origin has too little too. Then you only have lab data: label it a lab test with the date, and keep it out of the status column.

The 28-day validation, and why fixes show up slowly

When the developer says an issue is fixed, open the issue details page in the report and click Start Tracking. That starts a 28-day monitoring session of CrUX data. Google's help page says it does not trigger re-indexing or any other active behavior from Google. The issue counts as fixed only if it appears on no URL during the 28 days; one URL with the issue is enough to mark it not fixed.

Google's permissions table gives "Verify fixes" and "Share report links" to Owners and Full users, not to Restricted users, so ask the client for Full user before the fix ships; see access in the Search Console reporting setup.

The group values also cover the last 28 days of visits. A fix shipped on the 20th shares that window with visits from before it, so the status can lag the fix. In the report, give the date tracking started and the date the 28-day window ends. If validation fails, fix again, then open the validation details page (See details in the issue's validation status section) and click Start new validation.

The monthly status table you can copy

One row per URL group and device. Copy the statuses as Search Console shows them; do not average them into a site score. Above the table, add one summary line from the overview chart:

Example only: a hypothetical heating and cooling company with made-up URLs and statuses. Replace every row with what Search Console shows for your client, and keep each month's copy as your record of the change.

Where it goes in the report

The table belongs in the site health section of the report outline and answers question 1 of the five questions. Treat Core Web Vitals as a diagnostic, not a KPI: it describes part of the visitor experience, not a business outcome, in the sense of outcomes, KPIs and diagnostics. If the client wants something to aim at, Google's own recommendation is to achieve good Core Web Vitals. Write that as a site health aim, such as no Poor groups on mobile for the money pages, not as a score. For the search traffic section, see the monthly table in the GA4 organic search report.

In the monthly report email, Core Web Vitals takes at most one clause of sentence three, "Visibility and site health". Pick the line that fits the month:

How to explain that good scores do not guarantee rankings

A client who has read that page speed is a ranking factor may expect a fix to move rankings. Google's documentation gives you both halves of the answer:

• They count. Google says Core Web Vitals "are used by our ranking systems", and its Core Web Vitals page recommends that site owners achieve good Core Web Vitals for success with Search.
• Not one switch. On page experience, Google says "There is no single signal"; its core ranking systems look at a variety of signals.
• No guarantee. Google writes that getting good results in reports like Search Console's Core Web Vitals report or third-party tools "doesn't guarantee that your pages will rank at the top of Google Search results".
• Relevance first. Google says Search seeks to show "the most relevant content, even if the page experience is sub-par".

Google also writes that "trying to get a perfect score just for SEO reasons may not be the best use of your time". Point to that when a client asks you to get a testing tool to 100.

What not to say

• "Fixing this will move us up." Google says good report results do not guarantee top rankings.
• "We pass Core Web Vitals," based on a lab score. The Search Console status comes from real visits. PageSpeed Insights' own assessment passes when the 75th percentiles of all three metrics are Good in its field data.
• "The site fails Core Web Vitals," when the report says No data available. That is a gap in the data.
• "It's fixed," before validation shows Passed. Say the fix is live and the re-check is running.
• "Rankings dropped because of Core Web Vitals," without evidence. Work through how to explain a ranking drop instead.

What to hand to a developer

Google's help page tells non-technical site owners to share the report with whoever will update the pages. Make that a short ticket, not a screenshot of the chart.

Notes worth adding to the ticket, from web.dev and Google's help pages:

• Order: within a group, Search Console lists URLs by impressions, highest first, and Google's developer guidance says to fix them in the order shown.
• LCP: name the element that counts as LCP. web.dev lists the candidates: an image, an image inside an SVG, a video, an element with a background image loaded through url(), or a block-level element with text.
• INP: web.dev says Lighthouse cannot measure INP because a lab run has no user input, and names Total Blocking Time as a lab proxy. Reproduce the problem with real clicks, taps and key presses.
• CLS: causes web.dev lists include images or videos without known dimensions, web fonts that render larger or smaller than their fallback, ads or widgets that resize themselves, and content added above existing content. Lab tools only measure shifts during page load, so lab CLS can be lower than what visitors see.
• Page weight: Google's report help suggests keeping a page and all its resources under 500KB, and limiting a page to 50 resources for performance on mobile.
• Testing: Google's help points to PageSpeed Insights and Lighthouse to test fixes before you click Start Tracking.

On access: Google's permissions table lets only an Owner add users, so if the developer needs their own access, the client adds them. In an audit, the same issue becomes a row in the findings table, with evidence, impact, effort and an owner.

---

Sources

checked on 29 October 2026

• CrUX data, URL groups, status per device, 75 percent of page requests over 28 days, thresholds, reasons for missing data, origin groups, overview chart, status changes without site changes, Start Tracking and validation states, URL order by impressions, steps for site owners and developers, page size suggestions: Search Console Help, Core Web Vitals report
• "Verify fixes", "Share report links" and "Add users" by role: Search Console Help, managing owners, users and permissions
• Core Web Vitals used by ranking systems, no single signal, no guarantee of top rankings, most relevant content, perfect scores: Understanding page experience in Google Search results
• Recommendation to achieve good Core Web Vitals for success with Search: Understanding Core Web Vitals and Google search results
• Field metrics first, role of lab data, 75th percentile by device, Lighthouse cannot measure INP, Total Blocking Time as an INP proxy: web.dev, Web Vitals
• LCP definition, element types and thresholds: web.dev, Largest Contentful Paint
• INP definition, interactions counted and thresholds: web.dev, Interaction to Next Paint
• CLS definition, input exclusion, common causes, lab vs field values: web.dev, Cumulative Layout Shift
• Category names "good", "needs improvement" and "poor": web.dev, defining the Core Web Vitals thresholds
• INP replacing FID on 12 March 2024, and FID's removal from Search Console: web.dev blog, INP becomes a Core Web Vital
• Field vs lab data, 28-day collection period, origin fallback, Core Web Vitals assessment: About PageSpeed Insights