Does Google really track Core Web Vitals for AMP and non-AMP pages separately?

Why does Google separate CWV data between AMP and non-AMP?

Google’s logic is based on a simple principle: Core Web Vitals reflect real user experience, and this experience varies drastically depending on the URL visited. An AMP page, by design, loads differently than a standard HTML version — Google caching, restricted JS, inline CSS.

Google uses the Chrome User Experience Report (CrUX) to collect these metrics. When a Chrome user visits a URL, the data (LCP, FID, CLS) is tied to that specific URL. If your site offers example.com/article AND example.com/article/amp/, these are two different URLs with two distinct CrUX histories.

This approach radically changes the game for sites maintaining two versions in parallel. You can no longer count on AMP performance to 'rescue' the metrics of your standard pages — and vice versa, a disastrous non-AMP version does not directly affect your AMP URLs.

How does Search Console display these distinct data?

In the Core Web Vitals report of Search Console, each URL is evaluated individually. If 80% of your organic traffic lands on ultra-fast AMP pages but 20% hits slow non-AMP versions, you'll see two sets of data.

The catch? Search Console aggregates by groups of similar URLs. If you have /article (non-AMP) AND /article/amp/, they may appear in two separate lines of the report. Some SEO practitioners still think they see a 'global average' — that’s false. You need to analyze each version separately.

Practically, this means your monitoring strategy must segment AMP vs non-AMP from the start. It's impossible to diagnose properly without this distinction.

Which version does Google use for ranking?

If Google indexes and displays your AMP page in search results, it's the CWV of the AMP URL that counts for that result. If the non-AMP version appears, it's its metrics that count.

The major change post-Page Experience Update: Google no longer automatically favors AMP in top stories. It evaluates each URL on its own merits. A non-AMP page with excellent CWV can surpass a mediocre AMP.

• Google tracks two distinct CrUX datasets for AMP and non-AMP versions of the same page
• Search Console displays these data separately, without a global average
• The ranking depends on the URL actually indexed and displayed in the SERPs
• Direct traffic impacts non-AMP metrics, Search traffic can support both versions
• One version can be 'Good' while the other is 'Needs Improvement' in the same report

Is this statement consistent with field observations?

Absolutely. Practitioners who have migrated from AMP to exclusively non-AMP have experienced dramatic shifts in their CWV reports — not a gradual transition, but a complete reset. Historical AMP data becomes useless for predicting post-migration performance.

What still surprises some SEOs: even when Google displays the AMP version in cache (via the old top stories system), the CrUX metrics actually come from the AMP URL itself. There is no 'magical transfer' between the two versions. Each lives its own life in CrUX.

What implications does this separation have on AMP strategy?

Let’s be honest: since Google dropped the AMP badge and dedicated carousel, maintaining two versions often becomes a burden. If your non-AMP pages are fast, AMP no longer provides a direct SEO benefit — just doubled technical complexity.

The problem I observe: sites that invested in AMP 3-4 years ago continue to maintain both versions out of inertia. The result? Two attack surfaces for CWV issues, two sets of templates to optimize, two series of potential bugs. And that's where it gets tricky.

If your AMP traffic accounts for less than 10% of the total and your standard pages are already performing well, you are likely wasting resources. [To be checked]: Google has never published clear data on the click-through rates for AMP vs non-AMP in current results — we are navigating in the dark.

In what cases does this rule become problematic?

The classic case: a news site with strong direct traffic on desktop (non-AMP) and predominantly mobile Search traffic (AMP). You get two completely different pictures of your performance, neither of which reflects the 'true' overall user experience.

Another trap: poorly configured cross-canonicals. If your AMP page points to the non-AMP version in canonical but Google continues to index the AMP page, you could have an indexed version with excellent CWV... but which is never displayed to users. The theoretical SEO benefit does not translate into reality.

How to properly audit your CWV data with two versions?

First step: precisely identify which version Google indexes and displays in the SERPs for your strategic pages. A simple 'site:' is not enough — use the URL Inspection tool in Search Console to see the canonical URL recognized by Google.

Second action: segment your CWV reports in Search Console by URL pattern. Create filters for /amp/, /amp.html, or whatever schema you use. Analyze the two groups separately, as if they were two distinct sites.

Third crucial point: check your Google Analytics or equivalent. If 90% of your organic mobile traffic lands on AMP URLs but your development focuses on standard pages, you are optimizing the wrong target. Align your priorities with traffic reality.

Should you abandon AMP or keep it?

The answer depends on three factors: current AMP traffic volume, performance differential between the two versions, and maintenance cost. If your non-AMP pages are already reaching 'Good' in CWV and AMP only accounts for 5% of traffic, the decision is easy.

But if you are a news site with 40% of mobile traffic going through AMP and your standard pages are capped at 'Needs Improvement', abandoning AMP could drastically degrade your overall metrics. In this case, it’s better to first optimize non-AMP before migrating.

Timing matters: plan a gradual migration by redirecting 10-20% of AMP traffic to non-AMP via A/B testing. Measure the real CWV impact before flipping to 100%. A sudden migration can cause a temporary drop if your standard pages are not ready.

What errors to avoid in monitoring?

Error number one: mixing AMP and non-AMP metrics in a single dashboard without distinction. You get an 'average' that corresponds to no real user experience. Create two separate views in your reporting tools.

Second trap: ignoring CrUX data in favor of synthetic tests (Lighthouse, PageSpeed Insights in lab mode). These tools test one URL at a time, under ideal conditions that do not reflect real-world scenarios. CrUX captures the true experience — 3G network, low-end devices, active Chrome extensions.

Third classic mistake: deploying optimizations on the non-AMP version and expecting Search Console to reflect changes in a few days. CrUX requires a minimum of 28 days of real user data to update a group of URLs. Patience and long-term monitoring are essential.

• Identify which version (AMP or non-AMP) Google actually indexes for each segment of pages
• Segment your Search Console reports with distinct URL filters for AMP and non-AMP
• Compare actual traffic volume between the two versions via Analytics before any strategic decision
• If you maintain both, deploy CWV optimizations on BOTH versions in parallel
• If you migrate, progressively test (10-20% of traffic) before a full switch
• Use CrUX (real data) as a reference, not just Lighthouse (synthetic)