How does Google measure Core Web Vitals on your AMP and non-AMP pages?

Why does Google distinguish between CWV data for AMP and non-AMP?

Google collects Core Web Vitals based on real user experiences through the Chrome User Experience Report (CrUX). When a site offers two versions — AMP and non-AMP — users can reach these pages through different paths.

Visitors coming from Google Search often access the AMP version (especially through Top Stories carousels or optimized mobile results). Visitors arriving directly (bookmarks, external links, social media) generally land on the non-AMP canonical version. Google thus records two distinct sets of metrics for these two URLs.

Which version counts for ranking in search results?

Google applies a simple but often misunderstood logic: the ranking relies on the CWV data from the version that the user will see in the SERPs. If your AMP page appears in the results, Google evaluates its LCP, FID, CLS metrics.

Conversely, if it is the non-AMP version that appears, its data will determine the page experience signal. This distinction is critical: you may have a canonical version with excellent CWV, but if the AMP displayed in Search is slow, it is this latter score that penalizes your ranking.

How does Google decide which version to display in SERPs?

The decision depends on several factors: the type of result (Top Stories favors AMP), the user context (mobile vs desktop), and the technical annotations (rel=amphtml and rel=canonical tags). Google sometimes favors AMP for reasons of loading speed or format (carousels).

But be careful — and this is where it gets tricky — Google doesn’t always clearly communicate which criterion prevails in each case. A site might see its AMP served for certain queries and its standard version for others, creating a signal fragmentation that is difficult to manage.

• Google collects CWV data separately for AMP and non-AMP via CrUX
• Only the metrics of the version displayed in Search impact the ranking
• The version served depends on the type of result, user context, and technical annotations
• A site may see different versions served depending on queries, fragmenting CWV signals
• Direct traffic metrics (often non-AMP) do not influence ranking if AMP is displayed in the SERPs

Is this statement consistent with real-world observations?

Yes, this logic aligns with the patterns observed on dual-stack AMP/non-AMP sites. CrUX data indeed shows two distinct origins when versions are hosted on different URLs (for example example.com vs example.com/amp/). The Search Console also displays these metrics separately.

However — and this is a point that Mueller does not address — this separation poses an attribution problem. When Google oscillates between serving AMP or non-AMP based on queries, you cannot manage a unified CWV strategy. You must optimize two versions while not always knowing which will be evaluated for which query. [To verify]: the exact proportion of cases where Google switches between the two versions on the same site remains unclear.

What nuances should be added to this statement?

Mueller simplifies a mechanism that is actually more granular. Google collects CWV data at the origin (domain) level and then aggregates it by page. However, the thresholds of statistical significance in CrUX imply that a little-visited AMP page may not have its own data — Google then uses the metrics from the complete origin.

Practically? If your AMP receives little direct organic traffic, Google may apply the global metrics of your domain, diluting the specific impact of this version. Furthermore, the distinction between AMP and non-AMP becomes obsolete with the gradual decline of AMP: Google has removed the lightning icon, reduced privileges in Top Stories, and sites are massively migrating to optimized non-AMP solutions.

In what cases does this rule not apply?

If your site uses AMP paired mode (AMP and non-AMP versions coexist on distinct URLs), the rule applies fully. But if you are using AMP-only (a single version for all traffic), the distinction disappears: there is only one set of metrics.

Another edge case: sites that have abandoned AMP but still retain indexed AMP URLs. Google may continue to serve these old pages in certain results, creating an invisible technical debt. Without a proper 301 redirect to the canonical versions, these AMP zombies harm your CWV without you noticing in your usual dashboards.

What practical steps should you take to manage CWV on AMP and non-AMP?

The first step: identify which version Google is actually displaying in the SERPs for your priority queries. Use Search Console (Performance > Pages) to cross-reference indexed URLs with CWV data (Experience > Core Web Vitals). If you see a mix of AMP and non-AMP, you need to optimize both.

For each version, audit the CrUX metrics separately: LCP (largest visible element loading), FID (first interaction responsiveness), CLS (visual stability). The solutions differ: on AMP, the margin for optimization is limited by the framework (no custom JS), whereas on non-AMP you control the entire stack — lazy loading, preload, code splitting.

What mistakes to avoid in a dual-stack environment?

Classic mistake: only optimizing the non-AMP version thinking it’s the canonical version that matters. If Google serves your AMP in Search, your efforts are wasted. Another trap: not monitoring Google’s behavior changes. The engine may decide to switch from AMP to non-AMP (or vice versa) without warning, abruptly modifying the metrics evaluated.

Third mistake: keeping indexed AMP URLs after a migration. These orphaned pages continue to receive sporadic traffic, accumulating degraded CWV data that Google can use for ranking. Implement proper 301 redirects and explicitly disallow indexing of the old AMP URLs.

How to verify that your setup is optimal?

Use PageSpeed Insights with the CrUX API to compare field data metrics (real users) between your AMP and non-AMP versions. If the gap is significant, identify which version Google predominantly serves via the Search Console (Performance report, filter by page).

Manually test your priority queries in mobile private browsing: does Google display the AMP or the standard version? If the answer varies by query, you are in a complex hybrid scenario. In this case, prioritize optimizing the version most frequently served, but do not neglect the other — too great a gap can penalize you on query segments.

• Audit in Google Search Console which URLs (AMP vs non-AMP) are indexed and serving organic traffic
• Compare CrUX data (PageSpeed Insights or CrUX API) for each version separately
• Manually test your priority queries in mobile private browsing to identify which version Google displays
• If dual-stack, optimize both versions in parallel — do not put all your eggs in the canonical version’s basket
• After migrating from AMP to non-AMP, implement 301 redirects and disallow indexing of old AMP URLs
• Monitor monthly changes in Google’s behavior: the served version can switch without warning