Guide · about 7 minutes
Audit Core Web Vitals across your site with AI
By the GSC PAP team · Updated
A Core Web Vitals audit answers two questions: which of your important pages fall short of Google's thresholds for real visitors, and what to fix first. PageSpeed Insights gives you the numbers one URL at a time. The work is running it across the pages that get search traffic and ranking the fixes.
GSC PAP is a hosted MCP server with two PageSpeed Insights tools: `pagespeed_insights` for the Lighthouse lab run and `pagespeed_field_data` for CrUX field metrics at the 75th percentile. They share a 24-hour cache, so calling both for the same URL costs one PageSpeed request.
This guide covers lab versus field data and the thresholds first, then walks a multi-URL audit prompt that reads your top Search Console pages, runs PSI on each, and produces an action-ranked report.
Lab data vs field data: which Core Web Vitals numbers matter?
PageSpeed Insights reports two kinds of numbers for every URL. Lab data comes from one Lighthouse run on Google's servers with a simulated device and network. It is repeatable enough to catch regressions and debug a slow page, but it is a single visit, and the score moves from run to run.
Field data comes from the Chrome User Experience Report (CrUX): what real Chrome users experienced on that page over the last 28 days, reported at the 75th percentile. That is what your visitors actually get, so when lab and field disagree, trust the field numbers and use the lab run to find the cause.
Two practical differences. Interaction to Next Paint (INP) needs real user interactions, so a lab run cannot measure it; Lighthouse reports Total Blocking Time (TBT) instead, which web.dev treats as a lab proxy for INP, not a substitute. And low-traffic URLs often have no URL-level field data because CrUX lacks enough samples. In that case `pagespeed_field_data` also returns origin-level data for your whole domain when CrUX has it.
What are the Core Web Vitals thresholds?
Google's thresholds, as published on web.dev, are measured at the 75th percentile of page loads, separately for mobile and desktop. A page passes when all three metrics are in the good range. Anything between good and poor is rated needs improvement.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint, loading) | 2.5 s or less | 2.5 s to 4 s | Above 4 s |
| INP (Interaction to Next Paint, responsiveness) | 200 ms or less | 200 ms to 500 ms | Above 500 ms |
| CLS (Cumulative Layout Shift, visual stability) | 0.1 or less | 0.1 to 0.25 | Above 0.25 |
- ·Largest Contentful Paint (LCP), loading: good at 2.5 seconds or less, poor above 4 seconds.
- ·Interaction to Next Paint (INP), responsiveness: good at 200 milliseconds or less, poor above 500 milliseconds.
- ·Cumulative Layout Shift (CLS), visual stability: good at 0.1 or less, poor above 0.25.
Running a Core Web Vitals audit with Claude
The prompt works in any client connected to GSC PAP. Not set up in Claude yet? Connect GSC PAP to Claude
The scenario
Google recommends good Core Web Vitals for success in Search and says they align with what its core ranking systems seek to reward. Running PageSpeed Insights by hand on every important URL is slow, and a single run is a shaky basis for decisions because lab scores vary between runs. You want one chat where the AI runs PSI on your top pages, shows lab and field data side by side, and prioritizes fixes by potential time savings.
The prompt
Use the gsc-pap MCP. For https://example.com, get my top 10 organic-traffic pages from the last 28 days via Search Console. For each one run pagespeed_insights mobile + pagespeed_field_data mobile. Build a table: page_path, perf_score, LCP_lab, LCP_field_p75, INP_field_p75, CLS_field_p75, and the #1 PSI opportunity by ms savings. Sort by perf_score asc so my worst-performing high-traffic pages bubble to the top.What happens
- 1
AI fetches the top 10 organic-traffic pages
Claude calls `search_analytics_query` with dimension `page` for the last 28 days, takes the top 10 by clicks. This is your prioritization set: fixing CWV on a page nobody visits is wasted effort.
- 2
AI loops PSI calls (parallel-safe)
For each page the AI calls `pagespeed_insights(url, mobile)` and `pagespeed_field_data(url, mobile)`. Both share GSC PAP's PSI cache so this is at most one Google PSI hit per (url, mobile) pair per 24h.
- 3
AI builds the report and surfaces fixes
Output is a sortable table with both lab and field metrics + the highest-impact opportunity per page. The AI also highlights pages where lab and field disagree (lab says fast, field says slow → environment-specific issue) or where field data is missing (low-traffic URL with no CrUX samples → fall back to lab and origin-level field data).
Outcome
The pages to fix first are the ones with high organic traffic whose field LCP, INP or CLS sits outside the good range, even when their lab score looks fine. Those are the problems real visitors hit, on the pages Search sends them to. Field data covers a rolling 28-day window, so after you ship a fix, expect the field numbers to improve gradually over the following weeks rather than overnight.
Where to take it next
- ·Re-run weekly to catch regressions from new deploys.
- ·Pair with `correlate_gsc_to_ga4` to weight CWV fixes by actual revenue impact.
- ·For URL templates (e.g. blog posts or product pages) sample 3-5 representative URLs rather than auditing every one.
Frequently asked questions
Is there a PageSpeed Insights MCP server?
Yes. GSC PAP is a hosted MCP server that includes pagespeed_insights (a Lighthouse lab run) and pagespeed_field_data (CrUX real-user metrics), next to its Search Console and GA4 tools. You connect it by signing in with Google and pasting one bearer token into Claude, Cursor or Claude Code. There is no Google Cloud project to set up.
Can Claude audit Core Web Vitals for my whole site?
It can work through a list of URLs, such as your top pages from Search Console, and call the PageSpeed tools for each one. Each URL costs one or two tool calls, and GSC PAP allows 60 tool calls per minute and 1,000 per hour per user. For large sites, audit the pages with the most traffic and sample a few URLs per template instead of every page.
Why does my page have no Core Web Vitals field data?
CrUX only reports a URL when enough real Chrome users loaded it during the last 28 days. When URL-level data is missing, pagespeed_field_data still returns origin-level data for your whole domain if CrUX has it, and the pagespeed_insights lab run can still point to page-specific problems. The URL also has to be public: PageSpeed Insights cannot reach localhost or staging URLs that Google's servers cannot load.
Other guides
All guidesAI queries in Google Search Console: how to tell people, AI Mode and agents apart
Search Console mixes AI Mode follow-ups, AI agent searches and scripts into your query report. How to spot each one, with regex filters and real data.
Good position, no clicks: find the SERP features eating your CTR
Ranking third and getting no clicks usually means something sits above you: an AI Overview, a featured snippet or a map pack. How to check which, query by query.
Find the pages quietly losing organic traffic, before the rankings go
Content decay is slow enough to miss on a dashboard. How to find the pages whose clicks keep sliding, tell decay from seasonality, and decide what to refresh.
Traffic changed: how to compare two Search Console periods and find out why
Clicks are down 18% and nobody knows why. How to compare two periods properly, avoid the three traps that fake a drop, and find the queries and pages behind it.
Google Search Console anonymized queries: measure the traffic you can't see
Search Console hides anonymized queries from query rows but counts them in totals. Learn what they are, why no tool reveals them, and how to measure them.
GSC clicks vs GA4 sessions: why they differ and how to tie clicks to conversions
A Search Console click and a GA4 session measure different things. Why the numbers never match, what gap is normal, and how to compare and combine them page by page.
Google Search Console historical data: how to keep it past 16 months
Google Search Console keeps 16 months of historical data, then deletes it. Here is what it includes and how to keep it longer, from BigQuery to an archive.
Build a weekly SEO health report with Claude
Automate a weekly SEO report with Claude: one saved prompt pulls Search Console changes, quick wins, decaying pages, GA4 conversions and Core Web Vitals.
Bulk URL inspection in Google Search Console: diagnose indexing issues at scale
Search Console inspects one URL at a time. The URL Inspection API allows 2,000 checks a day per property. How to inspect in bulk and find indexing issues.
Track keyword rankings in Google Search Console, past the 16-month limit
See a keyword's position history in Google Search Console, what that average really measures, and how to keep ranking history past the 16-month limit.
How to find striking distance keywords in Google Search Console
Striking distance keywords rank just off page one of Google. Find them in Search Console, pick the ones worth fixing, and learn what to change on the page.
How to find keyword cannibalization in Google Search Console
Check for keyword cannibalization in Google Search Console: find queries where your pages compete, judge whether it hurts, and fix the cases that do.