Semrush Site Audit vs CrUX: Core Web Vitals Data Collection

Semrush Site Audit collects Core Web Vitals measurements primarily with Google Lighthouse, meaning its results are controlled lab tests rather than aggregated visitor experiences. For teams deciding how to handle Core Web Vitals data collection, the practical payoff is knowing which tool can find a site-wide issue, which can explain it, and which can confirm that real visitors actually experienced an improvement.

That distinction matters because a page can produce a poor lab Largest Contentful Paint (LCP) result from a test server while its 28-day Chrome UX Report (CrUX) data remains healthy—or the reverse can happen when real mobile visitors encounter slow devices, third-party scripts, or networks that a single synthetic test does not reproduce.

Semrush Site Audit vs CrUX: the direct answer

The direct answer is straightforward: Semrush’s published Site Audit methodology says that Google Lighthouse is its primary Core Web Vitals data-collection tool. Lighthouse is an automated, open-source lab-testing tool. The cited Semrush documentation describes collecting LCP and Cumulative Layout Shift (CLS) in that laboratory environment, then using Total Blocking Time (TBT) as a lab proxy for the older First Input Delay (FID) metric.

That explanation needs a current interpretation. Google’s current Core Web Vitals are LCP, Interaction to Next Paint (INP), and CLS. INP replaced FID as the responsiveness Vital in March 2024. A reader should therefore treat the Semrush article’s FID/TBT discussion as an explanation of a synthetic testing model, not as proof that TBT and INP mean the same thing. TBT is still useful for diagnosing main-thread blocking in a lab run, but it cannot observe every interaction a real visitor makes during a session.

CrUX measures something fundamentally different. It aggregates eligible real-user Chrome experiences over a rolling 28-day window. Google surfaces that field data in PageSpeed Insights and Search Console, subject to sufficient data being available for a URL or origin. The tools answer related but different questions:

• Lighthouse-based lab data: “Under this defined test profile, what happened on this page load, and what likely caused it?”
• CrUX field data: “Across actual Chrome visitors over recent weeks, how did this URL, URL group, or origin perform?”
• First-party RUM data: “How did this site’s own visitors perform, broken down by the segments the owner chooses to collect?”

No lab crawler, including a local desktop crawler, replaces field data. Equally, field data alone does not reveal enough page-level diagnostic detail to make a fix efficiently.

What Core Web Vitals data collection actually means

“Data collection” is often used as if it describes one thing. In practice, it includes the test environment, visitors included, pages sampled, aggregation period, device profile, network conditions, and the metric being reported.

A Lighthouse crawl collects a synthetic observation. The auditor chooses or inherits a controlled configuration and the tool loads a page under that condition. Semrush’s published settings illustrate why that context belongs in every client report: its mobile profile uses a 360 × 640 viewport, Slow 4G throttling, and a four-times CPU slowdown; its desktop profile uses a 1350 × 940 viewport, 10 Mbps network throttling, and no CPU slowdown. The documentation also notes that its servers are US-based, which can affect tests for sites and audiences elsewhere.

CrUX does not replay a controlled device or connection. It aggregates performance from real Chrome users who meet Google’s eligibility rules. That makes it valuable for prioritizing actual user experience, but it also means the result changes with the audience mix. A US desktop-heavy B2B site and a mobile-first ecommerce site can have very different field distributions even when their page templates are similar.

First-party real-user monitoring (RUM) adds another layer. It collects data from actual visitors through instrumentation selected by the site owner. Unlike CrUX, it can include data from supported browsers beyond Chrome and can connect performance to country, template, logged-in status, conversion flow, or release version—provided the implementation captures those dimensions. The trade-off is implementation, consent, privacy, data retention, and vendor or infrastructure costs.

LCP, INP, and CLS: what each source can tell teams

Core Web Vitals are user-experience metrics, but the method used to collect them changes how confidently they should be interpreted.

Largest Contentful Paint (LCP)

LCP approximates when the largest visible content element—often a hero image, heading, or product image—renders. Google classifies LCP at 2.5 seconds or less as good at the 75th percentile; over 4 seconds is poor.

A Lighthouse test can identify the likely LCP element, render-blocking resources, slow server response, oversized images, or costly JavaScript. That makes it excellent for diagnosis. CrUX can verify whether real visitors at the 75th percentile have a good LCP across the last 28 days. A useful workflow is to use Search Console or PageSpeed Insights to identify a field problem, then use a controlled Lighthouse crawl to find recurring causes across pages.

Interaction to Next Paint (INP)

INP measures responsiveness across a visitor’s interactions and reports a high-percentile value representing the worst interactions most users encounter. Google’s current thresholds classify 200 milliseconds or less as good, over 500 milliseconds as poor.

This is where lab-versus-field confusion causes the most mistakes. A lab tool can run scripted interactions and expose JavaScript work, but it cannot reproduce every real action, device capability, session state, embedded widget, or user journey. TBT can flag blocking work during load; it is not a direct substitute for field INP. If Search Console shows poor INP, the next step is to investigate long tasks, event handlers, and third-party code with lab tooling, while using field or first-party RUM data to confirm which interactions and visitor segments are affected.

Cumulative Layout Shift (CLS)

CLS measures unexpected visual movement. Google considers 0.10 or below good and above 0.25 poor. A Lighthouse test is particularly effective at catching predictable shifts such as images without dimensions, late-loaded banners, font swaps, or injected embeds.

However, a single lab pass may miss a consent banner, personalization module, ad slot, A/B test, or late client-side state that only certain visitors see. Field CLS is therefore the final check for whether layout stability is consistently acceptable in production.

Lighthouse lab data vs field data from CrUX

Google’s recommended pattern is not to choose one source and discard the other: collect field data when it is available, then use lab tooling to diagnose and improve issues. PageSpeed Insights makes that division visible in one report by showing CrUX data for real users alongside a Lighthouse audit.

CrUX has important coverage limits. Google does not disclose the exact traffic threshold, but it requires pages and origins to be publicly discoverable and sufficiently popular. A new landing page, private portal, low-traffic regional site, staging environment, or recently launched template may have no URL-level field data. Absence of CrUX data is not a passing score; it means there is not enough eligible public Chrome experience to report.

The 28-day window also means field data is not immediate release monitoring. A deployment today can be examined in Lighthouse immediately, but its full effect on CrUX will emerge gradually as newer visitor data enters the rolling average. For urgent regressions, first-party RUM is often the faster production signal.

Where PageSpeed Insights and Search Console fit

PageSpeed Insights is the quickest comparison point for an individual URL because it combines two evidence types. Its field section can show URL-level CrUX data when available and origin-level data when URL-level data is absent; its diagnostic section runs Lighthouse. That makes it a practical handoff tool when an SEO, developer, and client are reviewing one important page.

Google Search Console is better for site-level monitoring. Its Core Web Vitals report uses CrUX data and groups URLs that provide similar experiences rather than presenting every crawled page as a separate field-data row. That grouping is useful for recognizing a template-wide issue: for example, a product-page group might show poor mobile LCP while editorial articles remain good.

Neither tool is a complete crawl-based QA system:

• PageSpeed Insights is page-by-page, so testing hundreds of URLs manually is inefficient.
• Search Console reports field groups, not a full technical inventory of every canonical, redirect, orphaned, or low-traffic page.
• CrUX can lag the code change because it represents a rolling 28-day window.
• Neither source replaces a crawl that checks performance alongside technical SEO, accessibility, broken links, and best-practice issues.

For triage, an audit plan should separate pages that need immediate lab investigation from template groups that need field validation. That is the same prioritization principle behind a SEO audit plan that prioritizes fixes: impact, scale, confidence, and effort should drive the queue rather than a long undifferentiated issue list.

Semrush Site Audit and local desktop audits: coverage and repeatability

Semrush Site Audit is useful when a team wants subscription-platform crawling, scheduled audits, and Lighthouse-derived performance checks inside a broader SEO workflow. Its controlled conditions make crawl-to-crawl comparisons meaningful when the same configuration is retained. But its lab values should not be presented to a client as if they were their visitors’ real-world Core Web Vitals results.

A local desktop audit has different strengths. A tool such as Audra can crawl the selected site from the analyst’s own machine, run repeatable checks, retain the audit locally, and compile technical SEO, accessibility, performance, link, and AI visibility findings into a client-ready report. This is especially useful for agencies handling pre-launch checks, privacy-sensitive sites, or a portfolio of smaller client domains where recurring subscriptions are not the preferred cost model.

The limitations should remain explicit:

• A local crawl is still synthetic testing; it cannot create CrUX data for a low-traffic page or replace first-party RUM.
• Results can vary with the auditor’s device, connection, crawl configuration, and test timing unless those conditions are documented.
• A local audit is strongest for repeatable discovery and reporting, not for claiming a site passed Google’s field assessment.

For migrations, controlled before-and-after crawling can be more actionable than waiting for field data to mature. A Screaming Frog vs Audra migration audit workflow illustrates how crawl-based checks can support redirect, page, and technical validation while Search Console and CrUX continue to provide post-launch field confirmation.

A practical Core Web Vitals audit workflow

A reliable Core Web Vitals audit uses each source for the task it performs best. The workflow below avoids treating one red score as a universal diagnosis.

1. Start with field evidence. Review the Google Search Console Core Web Vitals report and PageSpeed Insights for the highest-value URLs. Identify whether LCP, INP, CLS, mobile, desktop, or a template group is the actual problem.
2. Record the reporting context. Note whether the number is URL-level or origin-level, the device category, the date range, and whether data is CrUX, first-party RUM, or lab data. A 28-day field metric should never be compared casually with one Lighthouse run.
3. Run controlled diagnostics. Use Lighthouse through PageSpeed Insights, Semrush Site Audit, or a local audit to inspect repeatable causes. For example, a recurring LCP problem across 200 category pages may point to a shared hero component, image policy, or render-blocking asset.
4. Crawl for scope. A multi-page crawler identifies whether the issue is isolated, template-wide, or caused by a technical pattern such as redirects, heavy assets, failed resources, or inconsistent page markup.
5. Prioritize fixes by exposure. A poor field metric on a conversion template deserves more attention than a lab warning on a low-value archive page. Combine traffic, revenue relevance, affected-page count, and fix confidence.
6. Re-test in the same lab conditions. Keep the device profile, location where possible, and crawl settings consistent. This demonstrates whether the implementation changed the synthetic result.
7. Validate with users. Watch CrUX/Search Console for the subsequent rolling-window trend, or use first-party RUM for faster release-level feedback.

Performance should also be reviewed with adjacent site-quality findings. A resource that harms LCP may also introduce accessibility or best-practice problems; similarly, unsafe third-party delivery or misconfigured headers can affect the reliability of a page experience. Teams reviewing the broader technical layer can use this guide to website security header configuration alongside their performance audit.

Monitoring frequency, history, privacy, and cost

The right monitoring cadence depends on release frequency and site volatility, not a universal calendar rule. A site that deploys daily should run lab regression checks in its release process and review field trends at least weekly. A stable brochure site may use a monthly crawl and a quarterly deeper review, with an additional audit after a redesign, tag-manager change, CDN migration, consent-platform launch, or major campaign.

For historical reporting, each option has a different shape:

• Search Console provides a practical free view of field Core Web Vitals trends, but it is limited to its reporting model and URL groups.
• CrUX History API and CrUX Vis provide weekly historical views where data exists; Google documents up to 40 weeks in the History API workflow.
• Semrush and similar platforms can retain scheduled crawl histories according to the account and project setup, which is useful for showing lab progress.
• RUM can offer the most tailored historical analysis, but the owner is responsible for implementation choices, privacy governance, and retention.
• Local audit reports provide an auditable snapshot of what was tested at a point in time, with the privacy benefit of keeping crawl work on the analyst’s device.

Cost is not only the vendor invoice. Subscription crawlers reduce setup work but create recurring platform costs. Free Google tools reduce direct tool cost but require more manual interpretation. RUM requires engineering and data-governance effort. A local desktop tool can reduce recurring software cost for agencies and consultants, but it does not remove the need to consult free field data where it exists.

Which should you choose?

Choose Semrush Site Audit when the team already operates in Semrush, needs scheduled broad SEO crawling, and wants Lighthouse-style performance signals inside the same subscription workflow. It is well suited to repeated technical discovery, provided reports label the results as lab data.

Choose PageSpeed Insights when diagnosing a small number of high-value URLs. It is the clearest free comparison of Lighthouse lab diagnostics and CrUX field outcomes in one place.

Choose Google Search Console and CrUX when the priority is Google’s view of real-user Core Web Vitals trends. They are the baseline for verifying whether eligible visitors pass the assessment, especially across mobile and desktop URL groups.

Choose first-party RUM when teams need to understand production experience by country, browser, template, customer state, release, or conversion path. It is the strongest choice for high-traffic products where performance is a continuous operational metric.

Choose a local desktop audit such as Audra when the work requires reproducible multi-page checks, local handling of site data, combined SEO/accessibility/link/performance reporting, and a no-subscription desktop workflow. It should be used beside—not instead of—CrUX or RUM when field data is available.

Verdict

Semrush Site Audit and CrUX are not competing measurements of the same event. Semrush’s published approach is primarily Lighthouse-based lab collection, optimized for controlled crawling and diagnosis. CrUX is aggregated field data, optimized for showing how eligible Chrome users experienced a site over a rolling 28-day period.

The strongest Core Web Vitals audit combines them: field data to establish the real-user problem, lab data to reproduce and diagnose it, a crawler to measure scope, and follow-up field monitoring to confirm the fix reached visitors.

FAQ

How do I measure Core Web Vitals?

Use Google Search Console or CrUX to see field performance from eligible real Chrome users, then use PageSpeed Insights or Lighthouse to diagnose individual pages. For a larger site, add a crawler such as Semrush Site Audit or a local desktop audit to test many URLs consistently. Record whether each number is field data, lab data, URL-level, origin-level, mobile, or desktop.

How does Semrush Site Audit collect Core Web Vitals data?

Semrush’s published methodology says Site Audit primarily uses Google Lighthouse in a lab environment. Its documentation describes specific mobile and desktop emulation profiles and uses LCP and CLS directly, while describing TBT as a lab proxy in its older FID-era explanation. Those results are synthetic tests, not aggregated CrUX visitor data.

What is the difference between Lighthouse lab data and real-user field data from CrUX?

Lighthouse runs a controlled synthetic test at a point in time, making it useful for repeatable diagnosis. CrUX aggregates eligible real Chrome-user experiences over a rolling 28-day period, making it useful for assessing what visitors experienced. Lighthouse can test a page with no traffic; CrUX may have no data for low-traffic, private, or insufficiently popular pages.

Which tools are available to test Core Web Vitals?

Google PageSpeed Insights combines Lighthouse diagnostics with CrUX field data where available. Google Search Console monitors CrUX-based Core Web Vitals groups across a verified property. Lighthouse supports controlled lab testing, while Semrush Site Audit and local crawlers extend lab-style checks across many pages. First-party RUM tools provide the most site-specific production monitoring.

How often should Core Web Vitals be monitored or audited?

Teams with frequent releases should include lab checks in deployment or release QA and review field trends weekly. Stable sites can usually crawl monthly and perform a deeper quarterly review, plus audits after major changes such as redesigns, CDN moves, tag-manager changes, consent banners, or new third-party scripts. Because CrUX uses a rolling 28-day window, field validation takes time.