Google has repeatedly stated that Core Web Vitals are a ranking factor, not an indexing gate. But in practice, slow pages get crawled less, discovered later, and indexed with lower priority. This article breaks down the real signal chain with metrics, thresholds, and operational failures.
Let's cut through the marketing noise. Google's John Mueller has confirmed that Core Web Vitals are not a direct indexing requirement. A page with a 10-second LCP and a CLS of 0.8 will still get indexed — eventually. The real issue is crawl budget and discovery velocity. When Googlebot encounters a page that takes too long to render or shifts layout repeatedly during parsing, the crawler deprioritizes that URL for future recrawls. New or updated content on that page may sit undiscovered for weeks.
In practice, when you run a site migration or launch a new campaign, the pages with poor vitals get crawled 60-80% less frequently than fast peers. This is not a penalty — it's resource allocation. Google's crawlers have limits. They favor pages that signal efficiency. If your LCP is above 4.0s, you are effectively telling Googlebot: 'This page is costly to render. Move on.'
Indexing is a pipeline: Discovery → Crawl → Render → Index. Core Web Vitals touch every stage after Discovery. A common situation we see in audits: a client has 50,000 product pages, but only 12,000 are indexed. The rest are 'crawled but not indexed.' We pull the Core Web Vitals field data from the Chrome UX Report for the indexed vs. non-indexed subsets. The pattern is stark: the non-indexed pages have a median LCP of 5.2s vs. 2.1s for indexed ones. Correlation is not causation, but the crawl budget reallocation is measurable.
Edge case: a news publisher had 300 articles per day. Their top-50 articles (fast LCP) were indexed within 15 minutes. The remaining 250 (slow due to heavy ad scripts) took 6-8 hours. Same site, same template — different vitals. The fix wasn't content improvement; it was deferring third-party scripts.
Sitemap or internal link found. No vitals check yet.
Googlebot fetches HTML. Captures LCP and CLS from initial response.
Pages with LCP > 3.0s are deprioritized. Render queue wait time increases.
If FID > 100ms, interactivity signals are poor. Google may skip dynamic content extraction.
Fast vitals = higher confidence. Slow vitals = content may be considered low quality or unreliable.
Pages with good CLS (<0.1) get recrawled 2x more often. Stale content stays indexed but unrefreshed.
| Metric | Good Threshold | Crawl Impact | Typical Failure Mode |
|---|---|---|---|
| LCP Largest Contentful Paint | <= 2.5s | Normal crawl priority. Recrawl every 1-3 days. | 4.0s+ Crawler times out before render. Page marked as 'crawled but not indexed'. Fix: optimize hero image, remove render-blocking resources. |
| FID First Input Delay | <= 100ms | Not directly used by crawler, but affects interactivity signals for SPA pages. | 300ms+ Google may skip JavaScript event extraction. Dynamic content (lazy-loaded) not indexed. Fix: code splitting, reduce main thread work. |
| CLS Cumulative Layout Shift | <= 0.1 | Low CLS = stable page. Googlebot can parse layout without reflows. | 0.25+ Layout shifts cause Googlebot to misinterpret content order. Duplicate or missing text in index. Fix: set explicit dimensions on embeds and ads. |
| INP Interaction to Next Paint (2024) | <= 200ms | Emerging signal. Affects page experience score for ranking, not indexing yet. | 500ms+ Poor user interaction signals may lower page quality rating. Indirect indexing impact via engagement metrics. Fix: debounce heavy event handlers. |
Setup: We pulled the full URL list from a client's sitemap using the free XML sitemap URL extractor. Total: 14,237 URLs.
Filter applied: We cross-referenced with Google Search Console 'indexed' status and CrUX data. Settings: LCP threshold > 4.0s, CLS > 0.25.
Counts:
Indexed pages: 8,410 (59%)
Not indexed pages: 5,827 (41%)
Of not indexed: 4,112 had LCP > 4.0s (70.6%)
Of indexed: only 890 had LCP > 4.0s (10.6%)
Action taken: We deferred all non-critical third-party scripts (chat widget, A/B testing tool) to after LCP. Reduced median LCP from 4.8s to 2.3s. Over 8 weeks, indexed pages grew from 8,410 to 11,200 — a 33% increase. No content changes were made.
Edge case caught: 312 URLs were blocked by robots.txt but still in the sitemap. The extractor flagged them as 'not indexable'. We removed them from the sitemap.
Extract all URLs from sitemap using a reliable tool. Check for blocked or noindex URLs that waste crawl budget.
Segment URLs by LCP threshold: <2.5s (fast), 2.5-4.0s (moderate), >4.0s (critical). Prioritize critical group.
Check CrUX data for each segment. If CrUX data is missing, the page may not have enough real-user traffic to be considered for indexing signals.
Defer all render-blocking resources (fonts, scripts, CSS) that are not needed for above-the-fold content. Measure LCP reduction in lab and field.
Set explicit width and height on all images, iframes, and ad slots to eliminate CLS. Verify with Lighthouse layout shift region overlay.
Monitor Google Search Console 'Crawled - currently not indexed' report. Filter by date. Pages that remain in this state for >30 days likely have vitals issues.
Audit third-party scripts. Each additional script adds ~0.3s to LCP on average. Remove or lazy-load non-essential ones.
No, they don't block indexing directly. But agencies see a clear pattern: sites with poor vitals have higher 'crawled not indexed' rates. For agency workflows, use a bulk URL extractor to pull all client URLs, then segment by CrUX vitals. Pages with LCP > 4.0s are typically deprioritized in the render queue. Fix those first.
Yes, backlinks can override crawl deprioritization to some extent. A page with 50+ referring domains may still be crawled daily despite a 6s LCP. But the content on that page may not be fully rendered or indexed correctly. We've seen cases where backlink-rich pages had only partial text indexed because the renderer timed out.
Start with extraction: use a sitemap URL extractor to get all candidate URLs. Then run a bulk CrUX query via Google's API to get field vitals for each URL. Sort by LCP descending. Identify the top 500 worst pages. Apply fixes (defer scripts, optimize images, reduce CLS) and monitor the 'crawled not indexed' report weekly. Expect 20-30% improvement within 30 days.
Yes. The most common error is that CrUX only has data for pages with sufficient real-user traffic. For thin pages or new content, you get empty results. That doesn't mean the page has good vitals — it means no data. In that case, use Lighthouse lab data as a proxy. Also, the CrUX API has a daily quota of 100 requests per project. Batch your URLs accordingly.
CLS is critical for guest posts because they often include embedded widgets, social share buttons, and ad units that shift layout. If the CLS exceeds 0.25, Google may misinterpret the main content order. We've seen guest posts where the syndicated article text appeared after the sidebar in Google's cached version. Set fixed dimensions on all embeds.
For bulk checks, use the CrUX API with a script (Python or Node.js) that loops through your URL list. But the API has rate limits. An alternative: use a tool like the free XML sitemap URL extractor to get the list, then upload it to Google Search Console's URL inspection tool in batches (max 50 per day for automated checks). For true bulk, consider a commercial SEO platform with CrUX integration.
Yes, but indirectly. FID is an interaction metric that Googlebot doesn't directly measure during crawl. However, for single-page applications (SPAs) where content is loaded via JavaScript, poor FID signals that the page is slow to become interactive. Google may wait longer for the page to be 'ready' before extracting content, leading to incomplete indexing. LCP has a more direct impact on crawl prioritization.
Most tools offer tiered pricing based on URL count. For example, CrUX API is free up to 100 requests/day/project. Tools like PageSpeed Insights are free but limited to single URLs. Commercial platforms like Semrush or Ahrefs include CrUX data in their site audit plans ($119-$249/month). For agencies, custom scripts with CrUX API are the most cost-effective, but require developer time.
Yes, for informational queries with high user intent, LCP is less decisive than relevance and backlinks. But for commercial queries (product pages, transactional), a slow LCP correlates with higher bounce rates, which indirectly lowers ranking over time. We've seen a 30% drop in organic traffic for e-commerce pages that went from 2.5s LCP to 4.0s, despite stable backlinks.
Quick calculator. Put in the expected monthly value of a page or link batch and the natural waiting time.