Official statement
Other statements from this video 42 ▾
- 42:49 Can hreflang really be used across multiple distinct domains?
- 48:45 Can hreflang really be used across multiple distinct domains?
- 58:47 Should you really avoid duplicating your content across two distinct sites?
- 58:47 Should you really avoid creating multiple sites for the same content?
- 91:16 Is it really necessary to index the internal search pages on your site?
- 91:16 Should you block internal search pages to prevent indexing of infinite space?
- 125:44 Do Core Web Vitals Really Influence Google's Crawl Budget?
- 125:44 Can reducing page size really enhance your crawl budget?
- 152:31 Does the internal links report in Search Console truly reflect the state of your link structure?
- 152:31 Why does the Search Console's internal links report show only a sample?
- 172:13 Should you really be concerned about redirect chains for Google's crawl?
- 172:13 How many redirects does Google really follow before it splits the crawl?
- 201:37 How does Google actually segment your Core Web Vitals by groups of pages?
- 201:37 How does Google actually segment your Core Web Vitals by page groups?
- 248:11 Is it true that AMP or canonical really captures the SEO signals?
- 257:21 Does the Chrome UX Report really count your cached AMP pages?
- 272:10 Is it necessary to redirect your AMP URLs during a change?
- 272:10 Should you really redirect your old AMP URLs to the new ones?
- 294:42 Is AMP really neutral for Google rankings, or does it hide an invisible visibility lever?
- 296:42 Is AMP really a Google ranking factor or just a ticket to access certain features?
- 342:21 Why does copied content sometimes outrank the original despite the DMCA?
- 342:21 Is the DMCA really effective in protecting your duplicated content on Google?
- 359:44 Why does copied content outrank your original material on Google?
- 409:35 Why do your featured snippets disappear seemingly without a technical reason?
- 409:35 Do featured snippets and rich results really fluctuate randomly?
- 455:08 Is it true that mobile hidden content is really indexed by Google?
- 455:08 Is it true that Google really indexes hidden content in responsive CSS?
- 563:51 Can structured data really force the display of a knowledge panel?
- 563:51 Is there any structured markup that guarantees the appearance of a Knowledge Panel?
- 583:50 Why do most websites never get sitelinks in Google?
- 583:50 Can you really force sitelinks to appear in Google?
- 649:39 Do 301 redirects really transfer 100% of SEO juice without any loss?
- 649:39 Do 301 redirects really transfer 100% of PageRank and SEO signals?
- 722:53 Should you really delete or redirect expired content instead of keeping it indexable?
- 722:53 Should you really remove expired pages or can you leave them labeled 'expired'?
- 859:32 Are keywords in the URL a ranking factor or just a temporary crutch?
- 859:32 Do words in the URL really influence Google rankings?
- 908:40 Should you really add structured data to embedded YouTube videos?
- 909:01 Should you really add video structured data when you're already embedding YouTube?
- 932:46 Why is Google ignoring desktop Core Web Vitals in its ranking algorithm?
- 952:49 Do the API and Search Console interface really display the same data?
- 963:49 Can you use different templates for each language version without harming international SEO?
Google has confirmed that the page experience signal (including Core Web Vitals) initially applies only to mobile, not to desktop. The reason is that technical constraints are more significant on mobile (limited processors, slow connections). For SEOs, this means prioritizing mobile optimization, but without neglecting desktop — especially if the audience is predominantly on computers.
What you need to understand
Why did Google initially limit this signal to mobile?
John Mueller's statement points to a technical observation: hardware limitations are more pronounced on mobile. Smartphones, even recent ones, are still less powerful than desktop computers. 3G/4G connections in mobility exhibit latency and fluctuating bandwidth. Therefore, Google chose to focus the ranking factor where the user experience faces the most constraints. This priority also reflects a usage reality. The mobile-first indexing has become the norm: Google crawls and indexes the mobile version of a site primarily. Aligning the ranking signal with this index was logical. However, the term "initially" in the statement leaves the door open: nothing prevents Google from extending this signal to desktop in the future. Mueller's wording is precise: the ranking factor related to page experience (which encompasses CWV, HTTPS, lack of interstitials, mobile-friendly) applies to mobile. This does not mean that Google completely ignores desktop performance. Speed and usability metrics influence user behavior — bounce rate, time on site, engagement. These indirect signals impact ranking, whether desktop or mobile. Let’s be honest: a slow desktop site will lose visitors, and Google will eventually capture this disinterest through usage data. It is simply not formalized as an official ranking criterion… for now. The word "initially" introduces a willing ambiguity. Google has never committed to a timeline for extending the signal to desktop. Since this statement, no official announcement has confirmed or denied a desktop deployment. This caution reflects Google's usual strategy: test a signal in a limited scope (mobile), observe behaviors, adjust thresholds, and then possibly expand. For SEO practitioners, this enforces a continuous vigilance: monitoring desktop Core Web Vitals remains strategic, even if the immediate ROI in SEO is not guaranteed.Are Core Web Vitals completely absent from desktop ranking?
What does "initially" really mean in this statement?
SEO Expert opinion
Is this statement consistent with real-world observations?
On paper, yes. A/B tests and correlation analyses show that Core Web Vitals have a measurable impact on mobile ranking, especially for competitive queries where other signals (content, backlinks) are on par. On desktop, the direct impact is much harder to isolate. Gains observed after optimizing desktop CWVs often relate to improved conversion rates or time spent, not a rise in positions. The problem is that Google communicates little about the thresholds and the actual weighting of this signal. [To be verified]: no official data indicates whether mobile CWVs weigh 1%, 5%, or 10% in the algorithm. This opacity makes it difficult for clients to prioritize their budgets. An honest expert admits that the impact remains marginal compared to poor content or a weak link profile. For a B2B e-commerce site where 70% of traffic and 85% of revenue come from desktop, optimizing only for mobile is a business misstep. Sure, Google indexes via mobile-first, but if the desktop experience is disastrous (LCP at 6 seconds, CLS causing buttons to jump), users will flee. Behavioral signals deteriorate, and ranking eventually follows — even without an official desktop CWV signal. Another edge case: sites with a radically different technical architecture between mobile and desktop (AMP on mobile, full version on desktop). Optimizing mobile CWVs on an AMP shell does nothing if the desktop version is slow. Google can display the mobile version in the desktop SERPs (mobile-first dictates it), but the user who clicks and switches to desktop experiences degraded performance. The bounce rate skyrockets, and the site loses ground. No. Let’s be clear: ignoring desktop is a strategic mistake. The absence of an official ranking signal does not mean there’s no impact. Desktop CWV metrics appear in Google Search Console and PageSpeed Insights. Google collects them, analyzes them, and could activate them as a ranking signal overnight — without detailed notice. Moreover, desktop performance directly influences conversion, ad engagement (if monetizing with display ads), and customer satisfaction. A slow site loses money, ranking or no ranking. For an SEO practitioner focused on overall performance, optimizing desktop CWVs remains worthwhile. It’s just less urgent than mobile if resources are limited.In what cases does this mobile-only rule become problematic?
Should we ignore desktop Core Web Vitals anyway?
Practical impact and recommendations
What should be prioritized in order?
First priority: ensure correct Core Web Vitals on mobile. LCP under 2.5 seconds, FID under 100 ms (or INP under 200 ms starting in 2024), CLS under 0.1. Use Google Search Console to identify problematic URLs in real-world conditions (field data, not lab). First, correct the high-traffic or high-business-potential pages. Second priority: ensure that the mobile version does not sacrifice experience for the sake of artificial metrics. An ultra-fast AMP site but empty of content or features loses users. The balance between performance and functional richness is delicate. Test in real conditions (real devices, 3G connections) to validate that the experience remains smooth. Third priority: don't neglect desktop if your audience is predominantly on computers. Optimize the same metrics, especially if Search Console raises desktop alerts. Even without direct ranking signals, a slow desktop site kills conversion and degrades behavioral signals. Google eventually captures this dissatisfaction. Classic mistake: optimizing only the homepage. CWVs are evaluated URL by URL. A disastrous LCP on product pages or blog pages drags down the ranking of those pages, even if the homepage is flawless. Prioritize URLs that generate organic traffic or conversions. Another trap: relying only on lab data (Lighthouse, PageSpeed Insights). The official Core Web Vitals for ranking come from the Chrome User Experience Report (CrUX), based on real users. A perfect lab score can mask a disastrous CLS in real-world conditions (ads loading late, fonts changing size). Always cross-check lab and field data. Finally, don’t sacrifice functionality to shave off 0.2 seconds of LCP. A carousel that boosts conversion but slows LCP might be worth it if the business impact offsets the marginal SEO loss. CWV optimization is not an end in itself — it’s one lever among others. Use Google Search Console (Core Web Vitals report) as the source of truth. Data takes 28 days to refresh, so patience is required after a deployment. Supplement with PageSpeed Insights (last 28 days CrUX data + lab analysis) and a RUM (Real User Monitoring) tool to track in real-time. For pre-deployment testing, simulate realistic mobile conditions: 3G/4G throttling, mid-range devices (not only iPhone 14 Pro). Tools like WebPageTest allow you to script complete user journeys and measure CLS, LCP, INP in real scenarios (scrolling, clicking, navigating). This is where you detect regressions before they impact real metrics.What mistakes should be avoided when optimizing CWV?
How to measure and validate improvements?
❓ Frequently Asked Questions
Les Core Web Vitals desktop n'ont-ils aucun impact SEO ?
Faut-il optimiser le mobile en priorité même si mon trafic est majoritairement desktop ?
Google va-t-il activer les Core Web Vitals comme signal de ranking desktop ?
Quelles métriques CWV sont les plus importantes pour le mobile ?
Les données lab (Lighthouse) suffisent-elles pour valider mes optimisations CWV ?
🎥 From the same video 42
Other SEO insights extracted from this same Google Search Central video · duration 996h50 · published on 12/03/2021
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.