# Core Web Vitals and SEO: how much do they affect rankings?

> Core Web Vitals are part of how Google ranks pages, but a small part: relevance comes first, and good scores never guarantee the top spot. What Google says, and how to act on it.

Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/core-web-vitals-seo

Yes, Core Web Vitals affect SEO, but less than most people fear. Google's Search Central documentation says "Core Web Vitals are used by our ranking systems", and in the same breath that Google "always seeks to show the most relevant content, even if the page experience is sub-par". For Core Web Vitals SEO, that means passing LCP, INP and CLS helps you win between pages that answer a query equally well; it never lifts a weak page above a better answer.

This guide is for site owners and marketers deciding how much time to spend on Core Web Vitals for search: what Google has said, which numbers it reads, and what a pass or a fail can do for rankings. For the basics (what LCP, INP and CLS measure), read [Core Web Vitals explained for site owners](https://getreport.app/guides/core-web-vitals-for-site-owners).

## Quick answer

- **They are a ranking factor, a modest one.** Google uses Core Web Vitals in its ranking systems as part of page experience, and relevance and helpful content come first.
- **Only field data counts.** Google reads what real Chrome visitors experienced (the Chrome UX Report), at the 75th percentile over 28 days. A Lighthouse or PageSpeed lab score is not used for ranking.
- **The target is "good", not 100.** LCP within 2.5 s, INP within 200 ms, CLS at 0.1 or less. Past that line, Google says chasing a perfect score "just for SEO reasons" may not be the best use of your time.
- **Fix templates, mobile first.** Search Console groups similar URLs and reports mobile and desktop separately; mobile usually fails first.
- **Expect weeks, not days.** The field data covers a rolling 28 days, so a fix shows in full after about four weeks.
- **The bigger payoff is visitors.** A page that loads late, lags or jumps loses people whatever its position.

## What Google says about Core Web Vitals and rankings

The primary source is Google's Search Central page "Understanding page experience in Google Search results" (last updated 22 September 2026). Four statements on it settle most arguments:

1. **"Core Web Vitals are used by our ranking systems."** They are a real input, and Google recommends that site owners achieve good Core Web Vitals.
2. **"There is no single signal."** Google's core ranking systems look at a variety of signals that align with overall page experience. There is no page experience score you pass or fail as a whole.
3. **Relevance wins.** "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." The same page adds that, for many queries, there is lots of helpful content available, and in those cases a great page experience "can contribute to success in Search".
4. **Good scores guarantee nothing.** Good results in Search Console's Core Web Vitals report or third-party tools do not guarantee that your pages rank at the top, and there is more to page experience than Core Web Vitals scores alone.

Besides Core Web Vitals, the same page lists the other aspects of page experience Google asks site owners to think about: serving the page over HTTPS, displaying well on mobile devices, avoiding an excessive number of ads that distract from the main content, avoiding intrusive interstitials, and making the main content easy to tell apart from the rest of the page.

It also says Google's core ranking systems "generally evaluate content on a page-specific basis, including when understanding aspects related to page experience", while noting that Google has "some site-wide assessments". In practice, a slow blog archive does not sink a fast product page, but a template that fails across thousands of URLs is worth fixing.

## How Core Web Vitals became a ranking factor

The history explains a lot of the confusion around the Core Web Vitals ranking factor:

| When | What changed |
| --- | --- |
| 2020 | Google announced Core Web Vitals and the page experience update. |
| June–August 2021 | The page experience update rolled out for mobile results. |
| February–March 2022 | Page experience rolled out for desktop results. |
| April 2023 | Google announced that the separate Page Experience report in Search Console would go away, and removed the "page experience system" from its ranking systems guide. |
| 12 March 2024 | Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric. |
| November 2024 | The Page Experience report was removed from Search Console. The Core Web Vitals and HTTPS reports remain. |

Dropping the "page experience system" from the ranking systems guide caused a stir, but it changed the wording rather than the signal: Google's current page experience documentation, quoted above, describes page experience as something its core ranking systems look at, not as a separate system. None of these changes switched Core Web Vitals off; the documentation above still says they are used.

## Which numbers Google reads

Google judges Core Web Vitals from **field data**: timings from real Chrome visitors, collected in the Chrome UX Report (CrUX). Each metric is taken at the 75th percentile, the value three out of four visits stayed within, over a rolling 28 days. Mobile and desktop visits are assessed separately.

The thresholds come from Google's Core Web Vitals documentation and web.dev:

| Metric | Measures | Good | Poor |
| --- | --- | --- | --- |
| LCP (Largest Contentful Paint) | Loading of the main content | ≤ 2.5 s | > 4.0 s |
| INP (Interaction to Next Paint) | Response to taps, clicks and key presses | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Unexpected movement of content | ≤ 0.1 | > 0.25 |

What Google does **not** read for ranking is the Lighthouse performance score, or the 0–100 score at the top of PageSpeed Insights. Those come from one simulated visit on a throttled phone in a data centre: useful for finding causes, but not what visitors experienced. A page can score 100 in the lab and fail in the field, and the reverse. [Field data vs lab data](https://getreport.app/guides/field-data-vs-lab-data) walks through the four combinations, and [why a Lighthouse score of 100 does not mean fast](https://getreport.app/guides/lighthouse-score-vs-core-web-vitals-why-100-does-not-mean-fast) covers the score itself.

Search Console's Core Web Vitals report shows the same CrUX data for sites you have verified. It groups URLs with a similar experience, rates each group by its worst metric (poor CLS with good LCP and INP is "Poor"), and falls back to an origin group, all URLs on the host combined, when a group has too little data. Pages and small sites without enough Chrome traffic have no field data at all. Google has not documented a ranking penalty for having no data; in that case, the lab test is your guide to what visitors are likely to feel.

## How much Core Web Vitals matter for SEO in practice

Google does not publish weights, so no one outside Google can give you a percentage. What the documentation supports is a clear order of priorities:

1. **Relevance and helpful content first.** If a competitor answers the query better, a faster page will not overtake it.
2. **Crawlability and indexing.** A page Google cannot crawl or index has no ranking for Core Web Vitals to influence.
3. **Page experience, including Core Web Vitals,** as a factor that can make the difference when several pages are similarly useful.

So the Core Web Vitals SEO impact is largest where competition is close: commercial queries with many similar pages, such as product categories, local services and comparison content. It is smallest where your page is the obvious answer, such as your own brand name.

Be wary of case studies that credit a traffic jump to Core Web Vitals alone. A redesign that fixes speed usually changes content, internal links and templates at the same time, and rankings move for many reasons. Google's web.dev publishes case studies about speed and business results; read them as evidence that visitors respond to speed, not as a ranking formula.

## Should you prioritise Core Web Vitals for SEO?

Use this decision order:

- **All three good in the field on mobile and desktop:** you are done for SEO purposes. Keep watching for regressions; don't chase lab points.
- **One metric poor on your main templates:** fix it. It is a known, documented ranking input, and the same fix helps every visitor.
- **"Needs improvement" only:** worth doing, after content and indexing problems. The gap between "needs improvement" and "good" is small for rankings and noticeable for visitors.
- **No field data:** work from the lab test, and fix anything that is clearly poor, such as a 6 s LCP image. There is nothing for Google to read yet.

Where to start depends on the failing metric. LCP fails most often and has the clearest fixes: page caching, a compressed hero image that is not lazy-loaded, and fewer render-blocking files. [Largest Contentful Paint: what it is and how to improve it](https://getreport.app/guides/fix-largest-contentful-paint) goes through each part. For the wider speed picture, including how page speed relates to SEO beyond the three vitals, see the [page speed guide](https://getreport.app/guides/page-speed).

## How to check where you stand

Start with the pages that bring search traffic: the home page, your main category or service pages and your top landing pages.

> **Free tool:** [Core Web Vitals test: check LCP, INP and CLS](https://getreport.app/tools/core-web-vitals): Free Core Web Vitals test: LCP, INP and CLS from real Chrome users next to the lab values, rated against Google's thresholds, with what to fix. No sign-up.

The Core Web Vitals test reads LCP, INP and CLS from the Chrome UX Report for the URL and for the whole origin, rates each against Google's thresholds, and runs a Lighthouse lab test beside it to show the cause. INP only appears in the field data, because a lab run does not interact with the page.

> **Check: Real-user Largest Contentful Paint.** LCP is when the biggest element on screen finishes loading. Google's threshold for "good" is 2.5 s at the 75th percentile of real Chrome users.
>
> 1. Find the LCP element in the Speed module and make it smaller, earlier or both.

> **Check: Real-user Interaction to Next Paint.** INP is how long the page takes to visibly react to taps and clicks, measured on real Chrome users over the last 28 days. Google's threshold for "good" is 200 ms.
>
> 1. Cut long JavaScript tasks and heavy third-party scripts; see the INP finding above.

> **Check: Real-user Cumulative Layout Shift.** CLS on real visitors' devices over the last 28 days. Google's threshold for "good" is 0.1; layout jumps hit hardest on slow phones with late-loading ads and fonts.
>
> 1. Reserve space for images, embeds and ads; see the CLS finding above.

For the whole site, open Search Console → Core Web Vitals and look at the mobile report first. Note which URL groups are Poor or Need improvement and which metric is responsible.

> **Free tool:** [Core Web Vitals report: 40 weeks of CrUX history](https://getreport.app/tools/cwv-history): Free Core Web Vitals report with up to 40 weeks of history: LCP, INP and CLS week by week from the Chrome UX Report, to spot the release that broke it.

A ranking drop you suspect is related to speed has a date, and so does a Core Web Vitals regression. The Core Web Vitals report tool plots up to 40 weekly CrUX data points for your origin or a popular page against the thresholds. If the line crossed into "poor" weeks before the ranking change, the two may be connected; if it didn't, look elsewhere. [Core Web Vitals history: reading 40 weeks of CrUX](https://getreport.app/guides/core-web-vitals-history-40-weeks) shows how to match a change to a release.

## What to expect after a fix

The lab value moves at once, so rerun the test the same day to confirm the change worked. The field value follows over about four weeks, as older visits roll out of the 28-day window. Rankings may not move at all: if you were already competitive on relevance, a pass helps at the margin. Visitors still get a faster, steadier page, and that is rarely wasted.

## Common mistakes

- **Treating the Lighthouse score as the ranking number.** Google uses field data from real visitors.
- **Blaming every ranking drop on Core Web Vitals.** Check the history chart first; a core update, lost links or a competitor's better page are more common causes.
- **Fixing only the home page.** Search Console groups URLs; product, article and category templates carry more search traffic.
- **Optimising desktop only.** Mobile is assessed separately and fails more often.
- **Chasing 100 for SEO.** Google's own documentation says a perfect score just for SEO reasons may not be the best use of your time.

## Questions people ask

### Do Core Web Vitals affect SEO?

Yes, a little. Google's documentation says Core Web Vitals are used by its ranking systems, but also that it shows the most relevant content even when page experience is sub-par, and that good scores don't guarantee top rankings. Treat them as a tie-breaker between pages of similar relevance. The larger effect is on visitors: slow, jumpy pages lose people before they convert, even where rankings don't move.

### Are Core Web Vitals a ranking factor on desktop too?

Yes. Page experience rolled out for mobile results between June and August 2021 and for desktop results between February and March 2022. Google measures phone and desktop visits separately, and Search Console reports them separately, so a page can pass on desktop and fail on mobile. Check the mobile numbers first, because slower phones and networks make them fail more often.

### How much do Core Web Vitals matter compared with content?

Much less than content. Google says it always seeks to show the most relevant content, even when page experience is sub-par, and that page experience can contribute to success where lots of helpful content is available. Google publishes no weights. In practice, fix content, relevance and indexing first, then bring Core Web Vitals into the good range on your main templates.

### Can a poor Core Web Vitals score cause a ranking drop?

It can contribute, but it's rarely the only cause. Core Web Vitals are one of many signals, and a page that is the best answer can still rank with poor scores. Before blaming speed, compare the dates: plot your Core Web Vitals history and check whether a metric turned poor before the drop. Core updates, lost links and stronger competing pages are more common explanations.

### Does Google use PageSpeed Insights lab scores to rank pages?

No. The 0–100 performance score in PageSpeed Insights and Lighthouse comes from one simulated visit and is not what Google ranks with. Google reads field data from real Chrome visitors in the Chrome UX Report, at the 75th percentile over 28 days. PageSpeed Insights shows that field data in its own section above the lab score; that section is the one that matters for search.

### What if my site has no Core Web Vitals field data?

Then there is nothing for Google to read yet: the Chrome UX Report only includes pages and origins with enough Chrome visitors. Google has not documented a ranking penalty for missing data. Search Console falls back to origin-level groups where it can. Use a lab test to find obvious problems, such as a heavy hero image or layout shifts, and fix them for your visitors.

### How long after fixing Core Web Vitals will rankings change?

Allow at least four weeks for the data, and don't expect a guaranteed ranking change. The field data covers a rolling 28-day window, so a fix shows in full after about a month, and Search Console's validation runs for the same period. Any ranking effect comes after that and depends on how close the competition is on relevance.