Slow Indexed Pages (GSC × Website Performance), Google Search Console

Names the URLs Google sends organic traffic to that fail Core Web Vitals, so the dev fixes the ranking penalty the same morning. How to read it, why it matters, and how to act on it.

Metrics type: Key Metrics • Category: Cross-Platform: Revenue at Risk

Pages Google sends traffic to that fail Core Web Vitals, a direct ranking penalty. Names the URL so the dev fixes it the same morning.

At a glance

A cross-platform alert table that joins Google Search Console page-level impressions and clicks against Website Performance Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift) for the same URL. It fires the moment a page that Google actively ranks and sends impressions to is also measured as slow. Because page experience is a confirmed Google ranking signal, a slow landing page is not just a UX problem, it is an active drag on the organic position that earns the traffic in the first place. The card names the exact URL so a developer can fix it the same morning, rather than chasing an abstract “the site is slow” complaint.

What it tracks	Every indexed URL where (a) Search Console reports it is receiving organic impressions, and (b) Website Performance measures its field or lab Core Web Vitals as failing. The two data sets are joined on the normalised URL.
Data source	Search Console Search Analytics API (page dimension: impressions, clicks, average position) joined to the Website Performance connector (CrUX field data plus PageSpeed Insights lab data: LCP, INP, CLS). See detail: “Pages Google sends traffic to that fail Core Web Vitals, a direct ranking penalty. Names the URL so the dev fixes it the same morning.”
Time window	30D. Search Console impressions are summed over the trailing 30 days; Core Web Vitals use the rolling 28-day CrUX field window where available, falling back to a fresh PageSpeed Insights lab run.
Alert trigger	any landing with LCP >4s and impressions >1000/mo. A page must clear both gates: it must be slow (LCP above 4 seconds, the “poor” threshold) AND material (more than 1,000 impressions in the month). This keeps the table to URLs where a fix has real organic upside.
Why both gates matter	A slow page with no impressions is harmless (nobody sees it). A fast page with high impressions is already healthy. The intersection (high-traffic AND slow) is where ranking and revenue are actively leaking.
Units	LCP and INP in seconds/milliseconds, CLS as an unitless score, impressions and clicks as counts, average position as a decimal rank.
Card class	Key Metrics, Alert Rules, and cross-platform: it is a headline pulse, it is configurable per profile in the Alert Rules tab, and it draws on two connectors at once.
Roles	owner, marketing, developer

Calculation

The card is built in three steps:

1. Pull the ranked pages. From the Search Console Search Analytics API, request the page dimension over the trailing 30 days and keep every URL with more than 1,000 impressions. These are the pages Google considers worth showing.
2. Pull the speed. For each of those URLs, read the Website Performance connector. Where Chrome User Experience Report (CrUX) field data exists, use the real-user 75th-percentile LCP, INP and CLS over the rolling 28-day window. Where a URL has too little field traffic to appear in CrUX, fall back to a PageSpeed Insights lab run for that exact URL.
3. Join and filter. Inner-join on the normalised URL (trailing slash, protocol and www reconciled), then keep only rows where LCP is above 4 seconds. Each surviving row is a page that Google ranks and that is measurably slow.

The alert fires on the count of surviving rows. The table itself lists the URL, its 30-day impressions, clicks and average position from Search Console, alongside its LCP, INP and CLS from Website Performance, so a developer can triage by impact (sort by impressions) rather than by guesswork.

Worked example

A UK homeware retailer running on its own headless storefront, both the Google Search Console and Website Performance connectors live. On 14 Apr 26 the card fires with four URLs over the 30-day window.

URL	Impressions (30D)	Clicks (30D)	Avg position	LCP (field, p75)	INP	CLS	Verdict
/collections/oak-dining-tables	18,420	612	6.2	5.8s	240ms	0.04	Poor LCP, high traffic, fix first
/products/extending-walnut-table	9,140	388	4.1	4.6s	180ms	0.02	Poor LCP, strong rank at risk
/blog/how-to-care-for-oak	3,260	95	11.4	4.3s	120ms	0.18	Poor LCP plus borderline CLS
/collections/sale	1,210	41	14.0	4.1s	95ms	0.01	Just over both gates, lower priority

Four numbered observations:

1. Triage by impressions, not by how slow. /collections/oak-dining-tables is the worst offender on both axes: 18,420 monthly impressions AND the slowest LCP at 5.8s. It earns a strong position 6.2 today, but page experience is dragging it. This is the same-morning fix: it has the most organic upside per engineering hour.
2. The “strong rank at risk” case is the urgent one. /products/extending-walnut-table ranks 4.1 (page-one, near the top). A poor LCP here is the most dangerous, because the page is one position drop away from falling below the fold. Protecting an existing high rank is usually cheaper than clawing one back.
3. The cause was a shared hero-image component. All three collection and product pages used an uncompressed hero image loaded above the fold without fetchpriority. The blog post’s CLS came from a late-loading author widget. The developer shipped two fixes that morning: compress and preload the hero image (LCP), and reserve space for the author widget (CLS).
4. What it looked like a fortnight later. On 28 Apr 26 the field LCP for the two collection pages had dropped under 2.5s (the “good” threshold), they cleared the table, and average position on /collections/oak-dining-tables had drifted from 6.2 to 5.4. The card had turned a vague “the site feels slow” into a named, fixed, measurable win.

Rule of thumb. If a URL is on this table, it is costing you rank on traffic you have already earned. Sort by impressions, fix the top of the list first, and re-check after the next CrUX window rolls.

Sibling cards merchants should reference together

Card	Why pair it with Slow Indexed Pages
Organic-to-Revenue Divergence	The other cross-platform revenue-at-risk card. Slow pages are one reason ranked traffic does not convert; this card finds the rest.
Pages Losing Traffic	If a slow page is also losing clicks week over week, the page-experience drag may already be biting its ranking.
Position by Page	Confirms the current average position of each URL on the table, so you can prioritise pages that are high-ranked and slow.
Top Pages by Impressions	Tells you which URLs carry the most organic visibility, the same impressions axis this card filters on.
Mobile Usability Errors	The other page-experience signal Search Console reports; slow LCP and a mobile usability error on the same URL compound the penalty.
High Impressions / Low Clicks	A slow page can suppress click-through even when it ranks; cross-check pages that appear on both.
Performance by Page Type	If slow pages cluster in one template (all PDPs, all collection pages), a single component fix clears many rows at once.
CTR by Page	Page-level click-through; useful to quantify the conversion upside of fixing a slow, high-impression page.

Reconciling against the source

This card joins two sources, so reconcile each side separately.

The Search Console side (impressions, clicks, position):

Rebuild the ranked-pages half in Google Search Console under Performance → Search results, switch to the Pages tab, set the date range to the last 30 days, and read impressions, clicks and average position per URL. Remember:

• GSC data is typically 2 to 3 days delayed, so the last couple of days will read low or empty.
• Rare queries are anonymised, so a long-tail page’s totals can be marginally lower than the true figure.
• The Pages report caps at 1,000 rows in the UI; use the Search Analytics API if you need the full set.

The Core Web Vitals side (LCP, INP, CLS):

Confirm the speed half in two native places:

• Search Console → Experience → Core Web Vitals report shows which URLs Google classes as “Poor”, “Needs improvement” or “Good”, grouped by similar pages, using CrUX field data. This is the report whose verdict directly informs ranking.
• PageSpeed Insights (run the exact URL) shows both the 28-day CrUX field assessment and a fresh lab run. The field LCP is what this card prefers; the lab run is the fallback for low-traffic URLs.

Why our number may legitimately differ:

Reason	Direction	What to do
GSC 2 to 3 day delay means our 30-day window ends ~3 days ago.	Impressions slightly lower than a same-day manual pull.	Match the date range and exclude the most recent 3 days.
Field (CrUX) vs lab (PageSpeed) LCP differ; field is real users, lab is a single throttled run.	Lab LCP is often higher (more pessimistic).	Trust field where it exists; treat lab as a flag for low-traffic URLs.
CrUX uses the rolling 28-day p75; a recent fix may not have aged into the window yet.	Page still shows as slow for up to 28 days after the fix.	Re-check after the window rolls; use a fresh PageSpeed lab run to confirm the fix landed.
URL normalisation (trailing slash, www, parameters) can split or merge rows.	A page may appear once in our join but as two rows in raw GSC.	Confirm the canonical URL matches between connectors.

The cross-platform point: neither connector alone tells you this. Search Console knows the page ranks; Website Performance knows it is slow; only the join tells you the page ranks AND is slow, which is the row worth a developer’s morning. For divergence investigations, use Vortex Mind.

Known limitations / merchant FAQs

Why does a page I just fixed still appear on this card? Core Web Vitals field data (CrUX) is a rolling 28-day 75th-percentile measurement. A fix you shipped yesterday only starts to move the number once enough real-user sessions on the fixed version accumulate, and it can take the full 28 days to fully clear. To confirm the fix landed immediately, run a fresh PageSpeed Insights lab test on the URL; if the lab LCP is now under 2.5s, the field number will follow.

Is LCP above 4 seconds really a ranking penalty, or just a UX issue? Both. Google has confirmed page experience, including Core Web Vitals, as a ranking signal. It is a tie-breaker rather than the dominant factor, so a slow page can still rank if its content is far stronger than competitors. But on competitive queries where content is comparable, the slow page loses, and it always costs you click-through and conversion even where rank holds.

Why 1,000 impressions a month as the threshold? Below roughly 1,000 monthly impressions, a page sees too little organic demand for a speed fix to pay back the engineering time, and CrUX often has too little field data to assess it reliably anyway. The gate keeps the table to URLs where a fix has measurable organic upside. You can adjust the threshold per profile in the Alert Rules tab.

A high-traffic page is slow but does not appear on the table. Why? Most likely its LCP is between 2.5s and 4s, which is “Needs improvement” rather than “Poor”. This card’s hard alert fires only on “Poor” LCP (above 4s) to keep the same-morning list short. Pages in the amber band still warrant attention; check the full Website Performance connector view or the native Core Web Vitals report for them.

Should I use field (CrUX) or lab (PageSpeed) numbers? Field data wherever it exists, because it reflects what real users on real devices and networks actually experience, which is what Google rewards. Lab data is a single throttled simulation; we use it only as a fallback for URLs with too little traffic to appear in CrUX, and as a fast way to verify a fix before the field window catches up.

Does this card cover INP and CLS as well as LCP? The alert gate is LCP-driven (LCP above 4s) because LCP is the most common ranking-relevant failure for ecommerce landing pages, but the table also surfaces INP and CLS for each URL so the developer can fix all three page-experience metrics in one pass. A page failing INP or CLS but passing LCP will not trip the hard alert; watch Mobile Usability Errors and the native Core Web Vitals report for those.

---

Tracked live in Vortex IQ Nerve Centre

Slow Indexed Pages (GSC × Website Performance) is one of hundreds of KPI pulses Vortex IQ tracks across Google Search Console and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.