Google Search Console vs Semrush Core Web Vitals: Why Results Differ

Google Search Console can report a URL group as failing Core Web Vitals while a Semrush Site Audit test of one page looks healthy—or the reverse. GSC vs Semrush Core Web Vitals becomes much easier to reconcile once teams separate Google’s 28-day real-user evidence from a controlled technical test, then use each report for the decision it is built to support.

The short version: neither report is automatically wrong. Google Search Console (GSC) draws on Chrome User Experience Report (CrUX) field data, while Semrush Site Audit uses crawl-based measurements and Lighthouse-style lab testing. Those methods differ by visitor population, device conditions, reporting window, URL scope, and timing. Google describes Core Web Vitals as real-world measures of loading, responsiveness, and visual stability; the recommended “good” thresholds are LCP at or below 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. (developers.google.com)

GSC vs Semrush Core Web Vitals: the measurement mismatch

The central difference is not the LCP, INP, or CLS definition. Both tools refer to the same Core Web Vitals concepts. The difference is who or what is being measured.

GSC’s Core Web Vitals report is based on CrUX, which aggregates eligible real-user Chrome experiences. It is therefore influenced by the phones, desktops, networks, cache states, connection quality, and behavior of an actual site audience. Search Console explicitly describes its Core Web Vitals report as performance based on real-world, or field, usage data. (developers.google.com)

Semrush’s explanation of the discrepancy says its Site Audit Core Web Vitals collection primarily uses Google Lighthouse in a lab environment with simulated page loading. That makes it useful for a repeatable diagnostic snapshot: the page can be tested after a deployment rather than waiting for visitor data to accumulate.

Consider a product-category page:

• A lab crawl may test it from a stable test configuration and show an LCP of 2.2 seconds.
• Real visitors on mid-range mobile devices, using cellular networks and loading a personalized recommendation widget, may produce a poorer 75th-percentile LCP over the following 28 days.
• GSC can consequently mark the associated mobile URL group as needing improvement even though the latest Semrush crawl looks acceptable.

The opposite is equally plausible. A single crawl may encounter a slow origin server, an uncached asset, a transient third-party script failure, or a geographic routing issue. The audit may fail at that moment while the site’s broader CrUX population still passes.

Field data vs lab data: what each source can prove

Field and lab data answer different questions, so comparing their headline scores as though they were interchangeable creates confusion.

What GSC and CrUX can prove

CrUX represents real-world Chrome user experiences for public, sufficiently popular pages and origins. Google does not publish the exact traffic threshold for inclusion, which means a low-traffic landing page may have no URL-level CrUX record even when its domain has origin-level data. (developer.chrome.com)

CrUX results are aggregated over the preceding 28 days. Its API supports page- and origin-level data and can be segmented by form factor, including phone, tablet, and desktop. (developer.chrome.com) In practical terms, GSC is the best evidence for whether an established audience has encountered a Core Web Vitals problem at scale.

What Semrush Site Audit can prove

A Semrush crawl is a controlled diagnostic. It can expose a page’s render-blocking requests, oversized assets, redirect chains, layout movement, or resource-delivery pattern during the test. It is particularly useful immediately after a change, because it does not need to wait for the CrUX rolling window to reflect that release.

That does not make the result a forecast of every user’s experience. One crawl is a sample of a page under a specific test setup. A client report should label it as a crawl or lab observation, not as a direct substitute for real-user performance.

PageSpeed Insights is helpful because it places both evidence types in one interface: CrUX field data shows what users experienced, while Lighthouse lab data is intended to diagnose why a page behaves as it does in a controlled run. (developer.chrome.com)

Why GSC groups URLs instead of listing every page

A common source of friction is that GSC may show a problem affecting a group of URLs rather than provide a separate Core Web Vitals status for every URL. This is deliberate, not a reporting omission.

Google’s CrUX documentation states that Search Console presents Core Web Vitals as aggregates of groups of similar pages. The goal is to highlight site sections likely to share a common page-experience issue, such as a product template, a paginated category template, or article pages using the same ad slot configuration. (developer.chrome.com)

That grouping has two important consequences:

1. The example URL is not necessarily the only failing URL. It is a representative page within a broader pattern.
2. A page-level Semrush test may not mirror the group result. The selected URL may have less content, a faster image, fewer ads, a different cookie state, or lower interaction complexity than its peers.

For example, /guides/technical-seo/ may pass a lab run while the GSC group for /guides/* fails mobile LCP. Before declaring the reports contradictory, audit at least five URLs from that template: a recent long article, an older article, a page with a large hero image, a page with embeds, and the GSC example URL. Look for a shared asset, template component, or third-party script.

This is also why an audit plan should prioritize patterns before isolated scores. A structured SEO audit plan that prioritizes fixes helps teams distinguish a template-wide problem from a one-off URL anomaly.

Devices, locations, and timing can move the result

The same HTML response can produce materially different Core Web Vitals outcomes across mobile and desktop. Mobile visitors often have slower processors, weaker connections, smaller memory budgets, and a different interaction pattern. GSC separates mobile and desktop data, so a mobile failure can coexist with a desktop pass.

Test timing matters too:

• GSC/CrUX: a rolling 28-day view of eligible user experiences.
• Semrush Site Audit: the moment or period when the crawler ran.
• PageSpeed Insights: a current Lighthouse run alongside a 28-day CrUX summary when field data is available.

A fix deployed on August 29 may improve a lab test that day but will not instantly erase the earlier poor experiences inside a 28-day field-data window. This delay is expected, not evidence that the fix failed.

Geography can also contribute to a mismatch. A controlled audit run originates from its configured testing environment, whereas CrUX reflects the site’s actual eligible Chrome audience. A U.S.-based ecommerce site with visitors across rural mobile networks, overseas markets, or regions distant from its CDN may show field data that is worse than a single well-connected crawl. The precise mix of users is not fully exposed in GSC’s Core Web Vitals report, so it should not be guessed from one lab result.

Core Web Vitals thresholds are shared, but the pass decision is not simplistic

Google’s recommended thresholds are clear: LCP at or below 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. (developers.google.com) However, the practical “Core Web Vitals assessment” is not the same as three isolated median scores from one speed test.

Field reporting relies on distributions and percentile-based evaluation. A page can feel fast for many sessions while still failing if enough users have poor experiences. Conversely, a poor single lab run does not establish that the user population is failing.

INP deserves special care in this comparison. It measures responsiveness after interactions, so it depends on what users actually do: open filters, type into search, add a cart item, expand an accordion, or use a configurator. A crawl may load the page without reproducing the full interaction mix that generates real INP field data. That makes GSC/CrUX especially valuable when investigating responsiveness regressions.

Teams should avoid reducing the exercise to “green versus red.” The more useful questions are:

• Which metric fails: LCP, INP, CLS, or more than one?
• Does the failure occur on mobile, desktop, or both?
• Is it a field-data trend, a reproducible lab defect, or both?
• Which page template and shared component explain the largest affected URL group?

A step-by-step reconciliation checklist for one URL

When a failing Semrush audit and passing GSC status appear to conflict, investigate the evidence in a fixed order. This avoids chasing a test artifact or dismissing a real user problem.

1. Write down the exact canonical URL. Confirm protocol, hostname, trailing slash behavior, locale, and query parameters. A crawl can test a URL variant that does not receive the same traffic as the canonical page.
2. Check GSC’s affected URL group and device tab. Record whether the issue is mobile or desktop and identify the representative URLs. Do not assume the chosen URL alone defines the group.
3. Open PageSpeed Insights for that same canonical URL. Compare its CrUX field section with its Lighthouse diagnostic section. If no field data appears, note that insufficient CrUX data is a limitation rather than a pass.
4. Run or review Semrush Site Audit for the identical URL. Record crawl date, user agent/device configuration, metric values, redirects, status code, and prominent audit findings.
5. Test several template peers. A five-URL sample is usually more useful than repeatedly retesting one page. Include both a simple and content-heavy variation.
6. Compare release timing with the CrUX window. If the code was changed less than 28 days ago, improvement in the lab result may simply precede field-data confirmation.
7. Separate root cause from validation. Use Semrush and Lighthouse diagnostics to fix the cause; use GSC/CrUX to validate whether real users improved.

For agencies, a local workflow can retain these screenshots, crawl findings, exact URLs, and timestamped results together. A subscription-free desktop audit tool such as Audra can be useful for collecting technical, performance, accessibility, and link evidence in the same client-ready project, while GSC remains the source for Google’s field-data status.

Which Core Web Vitals report should teams trust?

The answer depends on the decision.

Trust GSC first for real-user status in Google’s ecosystem. It is the appropriate source when reporting whether Google has observed a problem in real-world usage, identifying affected mobile or desktop URL groups, and tracking whether a change is reflected in field data over time.

Trust Semrush Site Audit and Lighthouse first for diagnosis and iteration. They are more actionable when a developer needs to test a deployment today, inspect a set of URLs, identify technical patterns, and verify whether a proposed fix improves a controlled result.

Use PageSpeed Insights as the bridge. It presents the field-versus-lab distinction directly, making it the fastest sanity check when a stakeholder asks why a GSC report and a crawl report disagree.

None of these sources should be treated as a universal authority for every purpose. Google itself distinguishes site-wide Core Web Vitals numbers in Search Console from individual-page testing in PageSpeed Insights. (developers.google.com) The strongest reporting practice is to state the data type beside every finding: “CrUX field status,” “GSC URL group,” or “Semrush crawl result.”

Limitations that should appear in every client report

Core Web Vitals data is valuable, but it has boundaries. Calling out those limits increases the credibility of an audit.

• CrUX does not cover every page. Pages need enough eligible traffic, and Google does not disclose the exact threshold. A missing URL-level record is not proof of good performance. (developer.chrome.com)
• Field data is delayed by design. The rolling 28-day window makes it stable enough for trend analysis but unsuitable as same-day release validation.
• Lab data is a scenario, not a population. It cannot fully reproduce every device, connection, cache condition, consent flow, personalization rule, or interaction sequence.
• URL grouping is efficient but imperfect for diagnosis. It points to likely shared causes, but the group’s representative URL may not be the worst-performing page.
• Core Web Vitals are not a full website-quality audit. Accessibility defects, broken internal links, indexability, security headers, and content usefulness can affect visitors or search performance even when LCP, INP, and CLS pass.

A broader site audit should therefore pair performance evidence with checks such as website security header configuration and crawl/indexation diagnostics. For example, a quick page may still be absent from search because it is blocked, canonicalized elsewhere, or stuck in a discovery/indexing workflow.

Which should you choose?

Choose Google Search Console when the objective is to understand how Google’s real-user dataset sees the site, prioritize affected URL groups, and verify whether users improved after the CrUX reporting window catches up.

Choose Semrush Site Audit when the objective is to crawl a known set of pages, inspect technical performance defects, create repeatable before-and-after tests, and investigate a newly released template without waiting weeks.

Choose PageSpeed Insights when one page needs a fast field-versus-lab comparison. It is especially effective in stakeholder reviews because it makes the two evidence layers visible on one screen.

Choose a combined local audit workflow when an SEO consultant or agency needs to test a site without treating one vendor dashboard as the entire audit. The practical sequence is: use GSC to find field-impact patterns, use Semrush or another crawler to reproduce and diagnose technical causes, then consolidate the technical evidence with accessibility, SEO, links, and AI visibility findings for the client.

Verdict

GSC and Semrush Core Web Vitals results differ because they measure different conditions, not necessarily because either tool is broken. GSC is the better evidence of real-user experience over the prior 28 days; Semrush Site Audit is the better tool for controlled, immediate technical investigation. Treat a disagreement as a lead: align URL, device, test date, template, and data type before deciding what needs fixing.

FAQ

Why do Google Search Console and Semrush show different Core Web Vitals results?

GSC uses CrUX field data from eligible real Chrome user experiences over a rolling 28-day period, while Semrush Site Audit uses controlled crawl-based, Lighthouse-style measurements. The tools may therefore test different device conditions, network conditions, URLs, and time periods. A disagreement often reflects different evidence, rather than an error in either report.

Does Google Search Console use real-user data while Semrush uses simulated tests?

Yes, that is the primary distinction. Search Console’s Core Web Vitals report is based on CrUX field data, whereas Semrush says its Site Audit uses Lighthouse-based lab measurements for Core Web Vitals collection. Lab tests are useful for rapid diagnosis; GSC is useful for validating the experience of real users over time.

Which Core Web Vitals report should I trust: GSC, Semrush, or PageSpeed Insights?

Use GSC for Google’s real-user, URL-group status; use Semrush for crawl-scale technical diagnosis; and use PageSpeed Insights to compare CrUX field data with Lighthouse diagnostics for a single URL. The best report depends on the question. No single score should replace checking the URL, device type, reporting period, and data collection method.

Why does GSC group URLs instead of reporting every page individually?

GSC groups URLs with similar user-experience patterns so site owners can fix shared template or component problems efficiently. A representative URL signals that related pages may be affected, but it is not necessarily the worst page in the group. Test several pages from the same template before selecting a technical fix.

How can a Semrush audit fail while GSC Core Web Vitals passes?

A Semrush crawl can fail because of a temporary test-time condition, such as a slow uncached response, third-party request issue, or a configuration that differs from real users. GSC can still pass if the broader 28-day CrUX population has acceptable 75th-percentile experience. Confirm the URL, device, crawl date, and template before treating the conflict as meaningful.