Official statement
Other statements from this video 14 ▾
- □ Une redirection 301 suffit-elle vraiment à imposer la canonique à Google ?
- □ Les liens sur forums et sites UGC ont-ils encore une valeur SEO ?
- □ Les paramètres d'URL multiples sont-ils vraiment un risque de contenu mince ?
- □ Faut-il vraiment réécrire toutes ses fiches produits pour bien ranker ?
- □ Les tests A/B en JavaScript peuvent-ils déclencher une pénalité pour cloaking ?
- □ Pourquoi le nombre de pages dans les rapports Core Web Vitals de Search Console fluctue-t-il sans raison apparente ?
- □ Pourquoi faut-il attendre 28 jours pour voir l'impact SEO de vos optimisations Core Web Vitals ?
- □ Faut-il vraiment ignorer les données de laboratoire pour optimiser ses Core Web Vitals ?
- □ Faut-il vraiment éviter de modifier fréquemment son site pour ne pas perdre son classement ?
- □ Google réécrit-il vos balises title et meta description à chaque requête ?
- □ Faut-il encore rediriger HTTP vers HTTPS si ce n'est pas déjà fait ?
- □ Pourquoi Google crawle-t-il vos images sans extension deux fois avant de les indexer ?
- □ Un site d'une seule page peut-il vraiment se classer dans Google ?
- □ Pourquoi la canonicalisation peut-elle détruire votre visibilité sur les requêtes de longue traîne ?
Google calculates Core Web Vitals solely based on field data corresponding to the pages that are actually served in the search results. If your AMP pages are displayed in the mobile SERPs, it is these versions that determine your CWV scores, not your standard web pages. This distinction radically changes the optimization strategy: optimizing the wrong version does nothing for your ranking.
What you need to understand
Why Does Google Talk About 'Field Data'? <\/h3>
Field data reflects the actual user experience, measured through the Chrome User Experience Report (CrUX)<\/strong>. Unlike lab tests (Lighthouse, PageSpeed Insights in 'lab' mode), these metrics capture what your visitors actually experience: unstable 3G connections, low-end devices, varied browsing contexts.<\/p> The crucial point here: Google does not rely on a theoretical average. It examines which version of your page<\/strong> users actually loaded from the search results. If an AMP page is displayed, the CWV are calculated based on that AMP version, period.<\/p> AMP (Accelerated Mobile Pages)<\/strong> are designed to be ultra-fast: clean HTML, limited JavaScript, resources preloaded by Google's cache. Their CWV scores are generally better than those of standard mobile pages. But if you serve standard mobile web in the SERPs, it's that version—often heavier and richer in scripts—that will be evaluated.<\/p> Practically? You can have an AMP page with excellent CWV, but if Google displays your mobile web version to users, your CWV scores rely on that version<\/strong>. The opposite is also true: a slow mobile page will not penalize your CWV if only the AMP version is indexed and served.<\/p> First step: check in Search Console<\/strong> which URLs are indexed. If you have implemented AMP with the Then, check the Core Web Vitals report<\/strong> in Search Console. The listed URLs correspond to the pages actually assessed. If you see AMP URLs, those are the versions that matter. If they are your standard canonical URLs, the same applies. No mystery—but you need to fact-check<\/strong>, not assume.<\/p>What Difference Does It Make Between AMP and Standard Mobile Web? <\/h3>
How Can I Know Which Version Google Uses for My CWV? <\/h3>
rel="amphtml"<\/code> tag, Google may choose to serve either version depending on the context. Historically, AMP was preferred in the 'Top Stories' carousels, but since the end of that exclusivity, the choice depends on multiple signals.<\/p>
SEO Expert opinion
Is This Statement Consistent with Observed Practices on the Ground? <\/h3>
Absolutely. The audits I've been conducting for years confirm this mechanism. I've seen sites with excellent Lighthouse scores in 'lab' demonstrate catastrophic CWV in production<\/strong> because the real conditions (network latency, limited mobile CPU) have nothing to do with a test on fiber desktop. Google is not lying here: only the measured user experience matters.<\/p> The classic trap? Optimizing your desktop or mobile page under ideal conditions, only to find that the neglected AMP version is dragging down your CWV scores<\/strong> because it is still being served to part of the traffic. Or the opposite: refining AMP when Google has switched to the canonical mobile web. Let's be honest: many SEOs do not check which version is actually being evaluated.<\/p> First nuance: CrUX has a minimum traffic threshold<\/strong>. If your page does not have enough Chrome visitors over 28 rolling days, it does not appear in CrUX, so there are no CWV data at the URL level. Google then reverts to the origin level (entire domain), which dilutes the real performance of a specific page. [To be verified]<\/strong> for sites with low or highly segmented traffic.<\/p> Second point: the gradual transition to 'signed exchange' (SXG)<\/strong> for AMP changes the game. With SXG, the AMP page can be served from your domain while benefiting from Google's preloading. CWV metrics then reflect a mix between cache and origin, depending on the browser and context. This is not a general rule—not everyone has migrated to SXG<\/strong>—but it adds a layer of complexity.<\/p> If you have abandoned AMP or never implemented it, this distinction has no impact: you only have one mobile version, hence a single source of CWV data. No double tracking to manage. The problem mainly arises for hybrid sites<\/strong> that maintain AMP and mobile web in parallel, without a clear strategy on which version to prioritize.<\/p> Another edge case: sites with client-side rendering (SPA, heavy JavaScript)<\/strong>. Even if Google displays your canonical URL in the SERPs, the user experience measured by CrUX can be disastrous if FCP (First Contentful Paint) or LCP (Largest Contentful Paint) is delayed by poorly optimized frameworks. Here, Mueller's statement remains valid, but it masks a deeper architectural problem. [To be verified]<\/strong>: does Google penalize heavy SPAs more via CWV, or does it apply the same treatment? Public data is lacking to make a definitive call.<\/p>What Nuances Should Be Added to This Claim? <\/h3>
In Which Cases Does This Rule Not Apply or Cause Issues? <\/h3>
Practical impact and recommendations
What Concrete Steps Should Be Taken To Align CWV With Served Version? <\/h3>
First action: audit Search Console<\/strong> to identify which URLs are listed in the Core Web Vitals report. If you see a mix of AMP and canonical URLs, you have a consistency problem. Google is evidently serving both versions based on context, which fragments your optimization efforts.<\/p> Next, test both versions with PageSpeed Insights in 'field data' mode<\/strong>. Don’t rely solely on 'lab' scores (Lighthouse): they do not reflect real conditions. If your CrUX data shows significant discrepancies between AMP and mobile web, that’s a signal to prioritize one or disable the other. Keeping two mediocre versions does nothing.<\/p> Classic mistake: leaving an outdated AMP implementation hanging<\/strong>. Many sites launched AMP between 2016-2018 to leverage the Top Stories carousel, then abandoned it editorially without removing the Another pitfall: optimizing only the mobile web while assuming that AMP is 'automatically fast'. Wrong. A poorly coded AMP page (unoptimized images, too many Use Google's AMP Test tool<\/strong> to validate your AMP pages: markup errors, outdated components, blocked resources. Then, compare CrUX data (via PageSpeed Insights or BigQuery) between your AMP and canonical URLs. If the performance gap is marginal, disabling AMP simplifies your tech stack without notable SEO loss.<\/p> Also verify your canonical and amphtml tags<\/strong>: they should point to each other consistently. A pointing error may confuse Google regarding which version to index and serve. Finally, monitor the 'Page Experience' reports<\/strong> in Search Console: if AMP URLs appear there while you thought you had disabled them, it indicates that residual traces remain (sitemaps, internal links, lingering tags).<\/p>What Mistakes Should Be Avoided in Managing AMP vs Mobile Web? <\/h3>
rel="amphtml"<\/code> tags. Result: zombie AMP pages, unmanaged, with catastrophic CWV continue to be served sporadically.<\/p>amp-script<\/code> components, heavy custom fonts) can have deplorable LCP<\/strong>. The AMP framework imposes limits, but guarantees nothing if you do not follow best practices.<\/p>How Can I Check That My Site is Compliant and Well Configured? <\/h3>
❓ Frequently Asked Questions
Google utilise-t-il des données de laboratoire pour les Core Web Vitals dans le classement ?
Si j'ai des pages AMP et mobile web, laquelle compte pour mes CWV ?
Puis-je avoir de bons scores CWV en lab mais mauvais en field ?
Dois-je encore investir dans AMP pour améliorer mes Core Web Vitals ?
Comment savoir si mes données CrUX sont au niveau URL ou origine ?
🎥 From the same video 14
Other SEO insights extracted from this same Google Search Central video · published on 23/04/2021
🎥 Watch the full video on YouTube →Related statements
Get real-time analysis of the latest Google SEO declarations
Be the first to know every time a new official Google statement drops — with full expert analysis.
💬 Comments (0)
Be the first to comment.