Validate a Core Web Vitals fix

Set realistic expectations for the 28-day field-data window and group-level validation.

GSC UI required Intermediate

Core Web Vitals validation in Search Console is a 28-day monitoring process for one device-and-issue combination. Start it only after the fix is deployed across the affected URL group and external testing gives reasonable evidence that the underlying problem is gone.

The button does not ask Google to recrawl or reindex pages. It restarts Search Console's monitoring clock over Chrome UX Report field data. An instant “Good” result is therefore not expected, even when a release clearly improves lab measurements.

This guide reflects Google's documentation on July 18, 2026.

What is being validated

The Core Web Vitals report organizes evidence by:

device type: mobile or desktop;
status: Poor, Need improvement, or Good;
metric issue: LCP, INP, or CLS threshold;
group of URLs with a similar user experience.

Validation belongs to a specific issue row, not to the entire property or one URL. A site can simultaneously have:

mobile LCP validation in progress;
desktop LCP already passing;
a separate CLS issue not started;
INP still failing for another group.

Record the exact device, status, metric, group examples, and affected count before changing code.

Why the process takes 28 days

Search Console uses CrUX measurements from real Chrome users. Its group LCP, INP, and CLS values describe the 75th percentile over the previous 28 days.

A production release does not erase pre-release visits. At first, the rolling window contains mostly old experiences. Each day replaces only part of that evidence with post-release traffic. The mix of devices, networks, countries, browsers, cache states, page variants, and user behavior continues to matter.

The validation period is therefore an observation window, not a processing delay that can be bypassed by requesting indexing.

Do not start validation immediately after deployment

Before choosing Start Tracking, confirm:

the fix is live in production;
every relevant template, variant, and route received it;
caches and CDN versions are current;
no experiment or segment still serves the old behavior;
representative lab tests improved;
real-user monitoring, when available, shows improvement;
no new regression offsets the target metric;
the issue is no longer reproducible in important user flows.

Starting too early wastes the monitoring window and can fail because some group members still expose the issue.

Sample the URL group deliberately

Each example row in Search Console represents a group of similar URLs. The examples table is not every group member and is limited to 200 rows.

Test more than the first example. Include:

the representative URL shown by Search Console;
other URLs revealed in the group details;
high-impression pages near the top of the group;
each major template and content variant;
image-heavy and text-heavy examples;
authenticated or personalized states when relevant;
pages with ads, embeds, consent layers, or late-loaded content;
fast and slow server-response cases;
mobile and desktop separately;
URLs created after the release.

The shared framework often explains a group issue, but outliers can keep the group from passing. A fix to one hero image or one landing page does not prove the template is healthy.

Build a pre-validation evidence sheet

Field	Record
Search Console issue	Device, metric, status, group value
Affected scope	Templates, group examples, approximate URL count
Release	Commit, deployment time, feature flag, CDN purge
Root cause	Render-blocking asset, long task, unstable layout, third party, server latency, other
Lab evidence	Before/after runs under consistent conditions
Field evidence	RUM or CrUX trend after release
Regression checks	Other vitals, errors, conversions, accessibility
Owner	Engineering and product contact
Decision	Ready to start tracking or further work required

Preserve measurement conditions. A faster laptop, warmer cache, different network, or changed test location can create a misleading before/after comparison.

Use lab and field data for different jobs

Lab tools

PageSpeed Insights lab data and Lighthouse run a controlled test. They help reproduce problems, inspect traces, identify main-thread work, locate an LCP element, or reveal layout-shift contributors.

Lab data is fast and diagnostic, but one run does not represent the site's real-user distribution. INP also depends on actual user interactions over a visit, so synthetic tests cannot reproduce every field interaction.

Field tools

CrUX and the Search Console report describe eligible real-user experiences. First-party RUM can provide faster and more detailed field evidence when it records the right attribution and respects privacy.

Field data proves impact; lab data helps explain and debug it. Use both rather than expecting one to match the other exactly.

Why PageSpeed Insights can disagree with Search Console

Google documents several important differences:

Search Console combines URLs into groups; PageSpeed Insights generally reports an individual URL when it has enough data.
One URL can be an outlier within its Search Console group.
Search Console distinguishes URLs with parameters; PageSpeed Insights strips parameter data before assigning results to the bare URL.
Search Console and PageSpeed Insights can display different scopes of field data when URL-level data is insufficient.
a current lab run measures now; Search Console's field status reflects a rolling history.

A green lab test immediately after release is positive evidence, not proof that group validation must pass.

Start the 28-day tracking window

After pre-validation checks:

Open Core Web Vitals.
Select mobile or desktop.
Open the exact Poor or Need improvement issue.
Confirm its group and affected scope.
Choose Start Tracking.
Record the start date and expected 28-day completion date.

Google says starting tracking does not trigger indexing, crawling, or another active behavior. Do not submit sitemaps or mass indexing requests to accelerate Core Web Vitals validation.

Understand the issue-level statuses

Status	Meaning
Not started	At least one issue instance has never been part of a validation request
Started	Monitoring began and no remaining instance has yet been found
Looking good	Checked instances are fixed so far; the window is still open
Passed	All evaluated URLs passed during the requested validation
N/A	Google found the issue gone without a validation request
Failed	At least one URL remained affected during validation

“Looking good” is provisional. Keep monitoring the release, field measurements, and group members until the window completes.

Understand URL-level statuses

During active tracking, individual URLs can be:

Pending: Search Console is waiting for enough evidence;
Passed: the URL appears no longer affected;
Failed: the URL remains affected.

One affected URL is enough to make the issue-level validation fail. Google continues evaluating individual URLs throughout the 28 days even after the overall issue is marked not fixed.

URLs removed from the web with no data in the last 28 days no longer appear in the report or validation history. Removing valuable pages simply to change the report is not a performance fix.

Monitor during validation

Track at least:

validation status and group values;
first-party RUM distributions by template and device;
deployment, rollback, and feature-flag changes;
new URLs entering the affected template;
backend latency and cache hit rate;
third-party scripts, ads, consent tools, and tag changes;
browser errors and failed resources;
conversion, engagement, and accessibility guardrails.

Avoid unrelated large performance changes during the observation window when possible. If another release is required, annotate it so the field trend remains interpretable.

If validation fails

Open the validation details and identify failed URLs. Then ask:

Was the fix missing from a template or route?
Did a cached or experiment variant retain old code?
Is the group near a threshold and sensitive to a few slower pages?
Did geography, device mix, or traffic change?
Did a third-party or backend regression erase the gain?
Did the lab test cover the real interaction or layout behavior?
Is a different metric now the group's worst status?

Fix and validate the underlying problem again. Search Console allows Start new validation from the validation details page, which restarts the monitoring period.

Do not restart repeatedly without a materially changed deployment and new evidence. The button does not clear field history.

If the report changes without a deployment

Real-user data can cross a threshold because of:

a traffic or country shift;
a browser or device-population change;
slower image, CDN, API, ad, or third-party service;
a group value already near the threshold;
enough new field data becoming available;
URLs entering or leaving the indexed sample.

Inspect metric values and field context before assuming a code regression. Small sitewide changes can move many borderline groups between Good, Need improvement, and Poor.

Set realistic success criteria

Passing Search Console validation is useful, but it is not the only success measure.

Require:

the target issue passes or sustains a clearly improving field trend;
important templates meet the intended 75th-percentile threshold;
no vital regresses while another improves;
conversion and task completion remain healthy;
accessibility and visual correctness are preserved;
improvements persist beyond one 28-day window.

Core Web Vitals are one component of page experience. Google advises site owners to pursue good overall experiences rather than optimizing only for an SEO score.

Automation boundary

Starting or restarting Search Console validation requires the UI. Search Console APIs do not expose a supported Core Web Vitals validation endpoint.

Automation can support:

Lighthouse checks in CI for regression budgets;
first-party RUM by metric, template, and device;
CrUX API or BigQuery trend monitoring;
release annotations and cohort comparisons;
crawling to confirm template deployment;
alerts for third-party and backend regressions.

SearchConsole.ai cannot start validation or retrieve the full Core Web Vitals report. Provide exported issue data and external measurements when asking it to prioritize affected templates.

Common mistakes

Starting tracking before the fix reaches every group member.
Treating a representative URL as the entire group.
Expecting validation to request crawling or indexing.
Expecting a same-day result from a 28-day field window.
Treating one green Lighthouse run as proof of field recovery.
Mixing mobile and desktop evidence.
Ignoring PageSpeed parameter stripping and group differences.
Restarting failed validation without a new fix.
Removing pages only to make the report change.
Optimizing one metric while breaking another vital or a business outcome.
Declaring success before the improvement persists.