Is Google really testing the AMP version for Core Web Vitals even if the mobile version is indexed?

Which version is Google really testing for Core Web Vitals?

Mueller's statement clarifies an ambiguity that many SEOs encounter: indexing and performance evaluation do not necessarily happen on the same version. Google indexes content from the standard mobile version (as part of mobile-first indexing), but tests Core Web Vitals on the version that the user actually sees.

In practical terms? If your site offers an AMP version and your users are redirected to that version from the SERPs, it is the AMP version that will be evaluated for LCP, FID, CLS, and the overall page experience score. Even if the indexed content comes from the standard mobile version. This separation between indexing and performance evaluation creates a technical complexity that many underestimate.

Why is there a distinction between indexed content and the tested version?

Google aims to evaluate the real user experience, not a theoretical version that nobody sees. If you serve AMP to mobile users, it is that experience that counts for rankings based on performance. Indexing content remains on the standard mobile version because that is generally where the most complete and up-to-date content is found.

This logic reflects Google's philosophy: ranking should reflect what the user will actually experience. If you hide a slow version behind a fast AMP version, it is AMP that will be judged. Conversely, neglecting AMP while it is the served version can torpedo your Core Web Vitals, even if your standard mobile version is finely optimized.

How does Google identify which version to test?

Google tracks the user journey from the SERPs. If an AMP link is presented (with the lightning icon) and the user clicks on it, it is the AMP version that will be considered as the viewed version. Data from the Chrome User Experience Report (CrUX) also reflects this reality: it aggregates metrics from real users, regardless of which version they are viewing.

For sites that offer both a mobile and AMP version, this means that both versions can theoretically be tested, depending on the user's entry point. But if AMP dominates your entry points from Google, it is primarily this version that will influence your performance scores in Search Console and impact your ranking.

• The version tested for Core Web Vitals is the one that users actually see, not necessarily the one indexed for content.
• If AMP is served to users, it is this version that impacts the page experience score, even if indexing occurs on the standard mobile version.
• CrUX data reflects the actual user experience, so the version actually viewed (AMP or mobile).
• Maintaining two versions (mobile and AMP) means monitoring and optimizing both for Core Web Vitals if both are served to users.
• Disabling AMP without a migration strategy can negatively impact your performance metrics if AMP was the dominant version seen by users.

Is this statement consistent with real-world observations?

Yes, and it confirms what many SEOs have observed when analyzing Search Console and PageSpeed Insights data. Sites with AMP often see significant discrepancies between the performance of their mobile and AMP versions in Core Web Vitals reports. This statement explains why: Google tests the served version, not the indexed version.

That said, the nuance lies in the proportion of users who actually land on AMP versus the standard mobile version. If AMP is only served to a minority of users (for example, via Google Discover only), the impact on overall ranking will be limited. But if AMP is the dominant version from mobile SERPs, neglecting its performance is a major strategic mistake. [To verify]: Google has never explicitly stated how it weighs CrUX data when a site serves two versions at varying proportions.

What ambiguities still exist in this statement?

Mueller does not specify how Google handles cases where the same site serves AMP to some users and the standard mobile version to others. Is CrUX data aggregated? Separated by version? Weighted according to traffic volume? It’s unclear. This gray area creates uncertainty for sites transitioning between AMP and optimized mobile versions.

Another gray area: what happens if the AMP version is technically served but rarely viewed (for example, if users prefer clicking on the non-AMP canonical link when both are offered)? Does Google only test the viewed version, or does it apply a heuristic based on the technical availability of AMP? The statement suggests the former, but without official data, it’s impossible to be certain. [To verify]

In what cases can this rule be problematic?

The main pitfall concerns sites that deployed AMP a few years ago and have left it unattended. If this version is still technically served but hasn’t kept up with technical developments (new ad formats, recent CLS optimizations, improved lazy loading), it can become a drag on your Core Web Vitals, even if your mobile version is top-notch.

What should you prioritize auditing on your site?

First step: identify which version is actually served to users from the mobile SERPs. Conduct representative searches for your target queries on mobile and check if Google is showing the AMP icon. Check Search Console to see if any AMP pages appear in your Core Web Vitals reports. If AMP is present, you need to treat it as a strategic version, not just a technical legacy.

Next, compare the performance of both versions (mobile and AMP) in PageSpeed Insights and the Core Web Vitals report in Search Console. If AMP is served but shows lower scores than the mobile version, you have a problem. The reverse is also true: a slow mobile version will not penalize you if AMP is what Google is testing, but it reveals a technical debt that will need to be addressed if you ever decide to turn off AMP.

How can you optimize the version that is actually being tested?

If AMP is the dominant version, focus your optimization efforts on that version: reduce the weight of AMP components, optimize loading of fonts and images, monitor CLS caused by AMP ads. Many sites neglect these optimizations thinking that AMP is "fast by default," but advertising components and third-party content can ruin your scores.

If you decide to abandon AMP, plan for a gradual migration phase: disable AMP on a test segment of pages, monitor the impact on Core Web Vitals in Search Console, and then generalize if the results are positive. Do not abruptly remove AMP without ensuring that the mobile version can take on the performance load. And most importantly, ensure that redirects are clean to prevent Google from continuing to test a ghost AMP version.

What mistakes should you absolutely avoid?

Classic error: optimizing only the mobile version while ignoring AMP, while it is AMP that is served and tested. The result: your efforts do not impact your actual performance scores. Another trap: disabling AMP without setting up proper 301 redirects, which may create 404 errors and temporarily disrupt indexing.

Finally, do not fall into the "two perfect versions" syndrome. Maintaining two optimized versions in parallel is costly in time and technical resources. If AMP does not bring you measurable gains (crawl speed, improved click-through rates, etc.), it may be more cost-effective to focus on a single ultra-optimized mobile version and redirect all traffic to it. These technical and strategic trade-offs can be complex to navigate alone. If you're uncertain about the best approach for your site, consulting a specialized SEO agency can help you accurately assess the impact of each scenario and manage the transition without risking traffic loss.

• Check in Search Console and on mobile SERPs if AMP is indeed served to your users.
• Compare the Core Web Vitals of your mobile and AMP versions in PageSpeed Insights and CrUX.
• If AMP is dominant, prioritize optimizing that version (component weight, ad CLS, lazy loading).
• If you disable AMP, test first on a segment of pages and monitor the impact before generalizing.
• Implement clean 301 redirects if you remove AMP to avoid 404 errors and signal loss.
• Avoid maintaining two versions in parallel if AMP does not provide measurable benefits in traffic or conversion.