How does Google actually segment your Core Web Vitals by groups of pages?

Why doesn't Google measure each page individually?

Google uses data from the Chrome User Experience Report (CrUX), which aggregates real user metrics from Chrome. The volume of data needed to reliably evaluate each URL would be enormous and statistically insignificant for low-traffic pages.

The solution? A template similarity grouping system. Google analyzes the HTML structure, loading behavior, and groups similar pages together. A typical e-commerce product page shares its metrics with all other product pages of the same template — not with the homepage or category pages.

How does Google determine the group to which a URL belongs?

The algorithm identifies the most appropriate group based on the URL pattern, its DOM structure, and its rendering behavior. It’s not your choice — it's Google’s automatic analysis.

Practically? If you have 10,000 product pages built on the same template, they will likely form a single group. The CWV metrics displayed in Search Console for a specific page reflect the average of the entire group, not that isolated page.

What happens with AMP versions?

This is where it gets complicated. If your AMP pages use a distinct template — which is often the case — they form their own measurement cluster. The CWV metrics of your AMPs do not influence those of your standard pages, and vice versa.

This separation can create paradoxical situations: AMP pages with excellent scores but canonical versions lagging behind. Or the reverse. Google evaluates each version based on its own group, meaning a poorly calibrated AMP strategy does not save slow desktop pages.

• CWVs are measured by groups of similar pages, not individually
• Google automatically determines group membership based on the template and structure
• CrUX data aggregates real user metrics from Chrome for each cluster
• AMP pages and standard pages form distinct groups if their templates differ
• An isolated low-traffic page inherits metrics from its group, not its own performance

Is this statement consistent with what we observe in the field?

Absolutely. SEO professionals have noted for years that the CWV metrics displayed in Search Console do not exactly match the one-off tests on PageSpeed Insights or Lighthouse. The reason? These tools test an isolated URL, while Search Console displays data from the CrUX group.

We also see cases where a handful of slow pages within a template can degrade the metrics of thousands of similar URLs. If 5% of your product pages load slowly due to specific widgets, the whole group suffers — even the fast pages.

What gray areas remain in Google's explanation?

Google remains deliberately vague on the exact grouping criteria. [To be verified]: What is the tolerance for DOM variation before a page is excluded from the group? Do URL parameters influence segmentation? No precise official answers.

Another blind spot: the relative weight of pages in a group. If a product page accounts for 70% of a cluster's traffic and another for 0.01%, do they have the same impact on the average? Probably not, but Google does not document the weighting. [To be verified]

In what cases does this grouping system cause issues?

For sites with hybrid templates — pages that share a common base but have significant variations in content or widgets. A typical example: product pages where some include heavy videos while others do not. Google may group them together despite radically different performance.

Another tricky case: sites with little Chrome traffic. If your audience primarily uses Safari or Firefox, CrUX data will be skeletal or nonexistent. Google then has to rely on broader groups or estimates — which dilutes the relevance of the metrics.

What should you do concretely to optimize your Core Web Vitals?

The first step: identify your page groups in Search Console. Go to the "Core Web Vitals" tab, filter by device type, and see which URLs are grouped together. You’ll quickly see which templates are problematic.

Then, prioritize the groups based on their traffic volume and business importance. A group of 10,000 product pages accounting for 80% of revenue deserves more attention than a cluster of low-converting ancillary pages. Optimize the entire template, not isolated pages.

What critical mistakes should you avoid?

Do not test your CWVs solely with Lighthouse or PageSpeed Insights. These tools provide a synthetic lab measurement, not the real-world CrUX data that counts for ranking. Use them for diagnosis, but always validate with Search Console data or the CrUX API.

Another trap: believing that an AMP migration solves everything. If your AMP pages form a distinct group with good metrics but your canonical pages remain slow, Google may favor the standard pages in certain contexts — and you lose the advantage. Consistency between versions is essential.

How to check that your optimizations are actually working?

Monitor the evolution of the CrUX metrics over a rolling 28-day window in Search Console. CWVs do not update instantaneously — it takes several weeks for an improvement to be reflected in the aggregated group data.

Also, use the public CrUX API to directly query the data of your URL groups. This way, you can monitor the evolution without solely relying on the Search Console interface, which does not provide detailed historical exports.

• Map your page groups in Search Console and identify priority templates
• Optimize the entire template, not isolated pages — CWVs are measured at the group level
• Validate your improvements with actual CrUX data, not just Lighthouse
• If you are using AMP, ensure that AMP and standard versions have consistent performance
• Monitor evolution over a minimum of 28 days — CWVs do not update instantaneously
• Use the CrUX API for granular monitoring and historical data exports