Core Web Vitals Audit Tools: Google vs Crawlers vs Audra

A PageSpeed Insights result can diagnose one URL in minutes, while Google Search Console may group hundreds of affected URLs under one mobile or desktop Core Web Vitals issue. That difference is why choosing between Core Web Vitals audit tools is less about finding one winner and more about using the right evidence at the right stage.

This guide explains how field data, lab tests, crawl-scale analysis, and broader website audits fit together. The practical payoff is a defensible audit: teams can distinguish real-user experience from a controlled test, identify representative templates, prioritize fixes, and create a report that does not overstate what the evidence proves.

Core Web Vitals audit tools: the decision in one minute

Google’s workflow separates three jobs: evaluate overall health, debug and optimize issues, then monitor changes. That is a useful model because Search Console, PageSpeed Insights, Lighthouse, crawlers, and monitoring products do not answer the same question. (Google’s Core Web Vitals tools workflow)

A practical sequence looks like this:

• Start with Google Search Console to identify whether mobile or desktop URL groups are marked Good, Needs Improvement, or Poor.
• Inspect representative URLs in PageSpeed Insights to see whether URL-level or origin-level Chrome UX Report (CrUX) data is available and to obtain a current Lighthouse test.
• Use Lighthouse or Chrome DevTools to reproduce a particular issue and investigate likely technical contributors.
• Use a crawler-based workflow when the team needs to connect performance evidence to URLs, templates, directories, internal links, or other technical SEO findings.
• Use monitoring when releases happen frequently and historical change matters.

Audra belongs in the broader audit layer rather than replacing Google’s field-data sources. It is a local-first desktop auditing app that brings together AI answer-engine visibility checks with technical SEO, performance, accessibility, and link audits, producing client-ready reports without a subscription. Its value is context: a performance concern can be reviewed alongside other issues that affect a site’s search visibility and user experience.

What a Core Web Vitals audit measures

Core Web Vitals consist of three user-experience metrics. Google assesses them at the 75th percentile of page visits, and the assessment is evaluated separately for mobile and desktop when sufficient data exists. A passing Core Web Vitals assessment requires all three metrics to be in the Good range. (Learn Core Web Vitals)

The metric names help prevent vague recommendations. An LCP finding concerns when a major visible element becomes available. INP concerns the responsiveness of interactions, such as a menu opening, a filter changing, or a form control responding. CLS concerns movement that users did not expect after a page began rendering.

An audit should not turn these labels into generic fix lists. For example, a poor LCP result on a product-page template needs evidence about the actual LCP element and its loading path. A poor INP result needs a reproducible interaction where possible. A poor CLS result needs the shifting element identified before a development ticket can be useful.

Field data vs lab data: two different kinds of evidence

The most common reporting mistake is treating a Lighthouse result as proof of a field-data pass. Both are useful, but they measure different conditions.

Field data: evidence of real Chrome user experience

CrUX is Google’s dataset of real-user Chrome experience data. PageSpeed Insights can show CrUX data for an entered URL where enough data is available; when URL data is unavailable, it may show origin-level data instead. Google Search Console presents Core Web Vitals information as groups of URLs with similar issues rather than as a complete, page-by-page CrUX export.

CrUX data uses a rolling 28-day collection period. That makes it appropriate for assessing experience over time, but it also means a deployed fix does not immediately change the field-data result. (CrUX API documentation)

Field data can be unavailable or limited for several reasons:

• A URL may be new, low traffic, private, or not receive enough eligible data.
• Origin-level data can describe the broader site without proving that every page or section performs the same way.
• Search Console groups help show scale, but a group is not a diagnosis of every individual URL.
• A 28-day collection window means confirmation requires both time and sufficient new visits.

Lab data: evidence from a controlled browser test

Lighthouse is available in Chrome DevTools and can also be surfaced through PageSpeed Insights and automated workflows. It provides controlled diagnostics for performance, accessibility, best practices, and SEO. (Lighthouse documentation)

A lab test is valuable because it is immediate and repeatable enough to support debugging. It can help a developer inspect a rendered page, compare a change before and after deployment, and investigate likely contributors. It cannot reproduce every device, network, location, cache state, third-party response, or user interaction seen in the field.

The report should therefore label evidence plainly: “Lighthouse test improved on this representative URL” is not the same claim as “the site passes the Core Web Vitals assessment.”

Google tools vs crawler-based tools

Google’s free tools establish the baseline and support diagnosis. Crawler-based products add URL inventory context, which is often necessary for a site with multiple templates, language folders, product categories, or CMS sections.

Google Search Console and PageSpeed Insights

Search Console is the starting point for a Core Web Vitals website audit because it shows grouped mobile and desktop status for a verified property. The audit should record the affected group, dominant metric, device category, and date observed.

PageSpeed Insights is then useful for selecting representative URLs from those groups. It combines a current Lighthouse report with field data where available. A homepage, category page, product or service page, article, and conversion page are often more informative than repeatedly testing near-duplicate URLs.

The limitation is scope. PageSpeed Insights accepts one entered URL at a time. It is excellent for evidence on a selected page, but not designed as a standalone way to inventory a large site.

Screaming Frog SEO Spider and Sitebulb

Screaming Frog’s Core Web Vitals tutorial describes a crawl-based workflow using the PageSpeed Insights API, with selected metrics brought into crawl results. This can help technical SEOs connect performance information to URL patterns, crawl data, and exports. (Screaming Frog Core Web Vitals tutorial)

Sitebulb is another crawler-based website auditing product that can be used in technical audit workflows. Both products require teams to understand their configuration choices: a crawl’s URL scope, JavaScript rendering settings, API fields, and any sampling decisions all affect what the output represents.

Neither a crawler export nor a set of lab tests should be described as comprehensive field data. A crawler can show which URLs were audited or tested under a chosen setup; Search Console and CrUX provide a different type of evidence about real-user experience.

Monitoring tools vs one-off audits

Monitoring answers a different question from an initial audit: did performance change after a deployment, tag update, CMS release, or redesign? Auditzy’s public Core Web Vitals materials describe historical checking, performance analysis, and downloadable reporting, placing it in the monitoring-oriented category. (Auditzy Core Web Vitals Checker)

This is useful for sites that release changes often or agencies that need recurring evidence across a client portfolio. A historical chart can help connect a regression to a release period, although it cannot by itself prove the technical cause.

For a quarterly technical SEO review, a Search Console baseline plus representative lab tests and a scoped crawl may be sufficient. For ecommerce, SaaS, publishing, or a high-change marketing site, ongoing monitoring can provide an additional safety net.

Monitoring still needs diagnosis. If field data indicates that INP worsened, the next step is not simply to report the trend; it is to reproduce a relevant interaction, inspect the page and scripts involved, and identify what changed. The monitoring product supplies the signal. Browser investigation and implementation review establish the cause.

Where Audra fits in a wider website audit

Audra should be considered when the assignment is broader than a standalone Core Web Vitals report. It combines performance checks with technical SEO, accessibility, link audits, and AI answer-engine visibility checks in a local-first desktop workflow, and produces client-ready reports without a subscription.

That broader perspective matters when a performance issue shares a template, content process, or implementation owner with another audit finding. A consultant may need to explain that a page has a performance concern alongside broken internal links, accessibility gaps, or technical SEO issues. The resulting discussion can focus on the order of work rather than treating every score as an isolated project.

Audra does not replace Search Console, CrUX, PageSpeed Insights, or Lighthouse for their specific evidence roles. In particular, Google’s field-data products remain the appropriate sources when a report makes a claim about real-user Core Web Vitals status.

A useful client deliverable can pair performance findings with a prioritization framework that considers impact, affected scope, effort, and business importance. This approach is developed further in Audra’s guide to a SEO audit plan that prioritizes fixes. Security checks can also be relevant in a wider technical review, including the configuration considerations covered in Security Headers for Websites: What to Set and Where.

A compact Core Web Vitals audit workflow

A comparison page does not need a long operational checklist, but a four-stage process makes the roles of the tools clear.

1. Baseline the field-data picture. Review Search Console’s mobile and desktop Core Web Vitals groups. Use PageSpeed Insights on representative URLs and record whether the displayed field data is URL-level or origin-level.
2. Scope the affected patterns. Select representative templates and use a crawler, configured URL list, or wider website audit to identify whether an issue appears related to a directory, template, or page type. The precise scope depends on the tool configuration and available data.
3. Diagnose a representative page. Reproduce the issue in Lighthouse or Chrome DevTools. For LCP, identify the LCP element and investigate its loading path. For INP, test a meaningful interaction. For CLS, identify the element that moved and the conditions that triggered it.
4. Recheck and report accurately. Run lab tests after the change, then allow time for fresh field data to accumulate. State separately what was improved in lab testing and what later field data confirms.

This workflow avoids two unhelpful extremes: reporting only a high-level Search Console group with no technical diagnosis, or reporting a single Lighthouse score as if it represented all visitors.

How to improve Core Web Vitals from audit findings

Improvement work should follow the evidence collected in the audit. Google’s documentation and tools can identify opportunities and diagnostics, but implementation choices vary by stack, page design, hosting setup, and third-party dependencies.

For an LCP issue, the investigation should establish which element was largest and whether the delay relates to server response, resource discovery, transfer, or rendering. For INP, the audit should focus on the interaction that performs poorly and examine work on the browser’s main thread. For CLS, the audit should identify the component that shifts rather than assuming every layout movement has the same remedy.

A clear remediation ticket includes:

• The affected template or representative URL.
• The metric and evidence type, such as Search Console field-data grouping or a Lighthouse test.
• The observed element, interaction, or shift.
• The proposed owner, such as engineering, CMS administration, design, or a third-party vendor.
• The validation method after release.

Fix order should also reflect wider site health. If a page has an indexability or crawling problem, that may deserve attention before marginal lab-score tuning. Audra’s diagnostic guide for “Discovered – currently not indexed” explains why teams should identify the underlying blocker rather than rely on a single status label.

Which should you choose?

Choose Google Search Console plus PageSpeed Insights when the budget is limited and the immediate goal is to understand field-data groups and inspect a small number of important URLs. This is the strongest foundational combination because it joins grouped property reporting with page-level investigation.

Choose Lighthouse in Chrome DevTools when developers need to reproduce a page issue, evaluate a change quickly, or inspect diagnostics in a controlled environment. It is a debugging tool and a pre-release check, not a substitute for field-data confirmation.

Choose Screaming Frog SEO Spider when a technical SEO workflow requires crawl control, exports, and configured PageSpeed Insights API data alongside other crawl findings. The team should document exactly which URLs and metrics were included.

Choose Sitebulb when a crawl-based technical audit product suits the team’s workflow. Before presenting results, confirm the configured crawl scope and distinguish any lab-based output from field data.

Choose Auditzy or another monitoring-focused product when recurring checks and historical reporting matter more than a one-time diagnostic. Monitoring is most useful after an initial baseline and remediation plan exist.

Choose Audra when a client-ready website audit needs to bring performance together with technical SEO, accessibility, links, and AI-answer visibility. It is best paired with Search Console or CrUX when the report needs to make a field-data Core Web Vitals claim.

Verdict

No single product provides every kind of Core Web Vitals evidence. Search Console identifies grouped field-data risk; PageSpeed Insights and Lighthouse investigate representative URLs; crawler-based products add audit scope and URL context; monitoring records change over time; and Audra brings performance into a broader client-ready website audit.

The key reporting discipline is simple: state whether a finding is field data, a lab result, a crawl-based measurement, or a broader audit observation. That distinction makes recommendations more credible and helps clients understand why a green lab test is progress, not automatic proof of a field-data pass.

FAQ

How do I measure Core Web Vitals?

Start in Google Search Console to review mobile and desktop Core Web Vitals groups. Then test representative URLs in Google PageSpeed Insights, which can show CrUX field data when available and a Lighthouse lab report. Use LCP, INP, and CLS field data to assess real-user experience, and use Lighthouse to investigate likely causes on a specific page.

How do I audit Core Web Vitals across an entire website rather than one URL?

Use Search Console to identify affected URL groups, then choose representative templates such as homepages, categories, products, services, and articles. A configured crawler such as Screaming Frog or Sitebulb can add URL inventory context. Clearly document whether results are crawl-based lab measurements, API data, or Search Console field-data groups.

What is the difference between field data and lab data in a Core Web Vitals audit?

Field data reflects real Chrome user experiences collected through CrUX over a rolling 28-day period. Lab data is a controlled browser test, commonly run with Lighthouse. Field data is used to assess real-user Core Web Vitals status; lab data supports immediate debugging and comparison. A good Lighthouse result does not guarantee that field data will pass.

How do I pass the Core Web Vitals assessment?

At the 75th percentile of visits, LCP must be 2.5 seconds or less, INP must be 200 milliseconds or less, and CLS must be 0.1 or less. Review mobile and desktop separately. Identify the affected templates, diagnose the root cause on representative pages, deploy fixes, and wait for sufficient fresh field data to appear in CrUX or Search Console.

Which tool is best for auditing and reporting Core Web Vitals?

The best choice depends on the job. Search Console and CrUX are best for field-data status; PageSpeed Insights and Lighthouse are best for page-level diagnosis; Screaming Frog and Sitebulb support crawl-based technical workflows; Auditzy supports monitoring. Audra is suitable when performance reporting needs to sit alongside SEO, accessibility, links, and AI-answer visibility in one client-ready audit.