How does Google group your pages to measure Core Web Vitals?

Why doesn’t Google have CWV data for each individual page?

The Chrome User Experience Report (CrUX) collects real performance data from Chrome browsers, not from Googlebot. This collection depends on the volume of actual visits: a minimally visited page does not generate enough data to produce a reliable and representative metric.

Thus, Google applies an adaptive grouping mechanism. For low-traffic sites, metrics are aggregated at the domain level. For sites receiving more traffic, Google creates groups of similar pages — for example, all product pages, all category pages — and calculates Core Web Vitals at the scale of these clusters.

How does this affect the interpretation of metrics in the Search Console?

The reports displayed in the Search Console present aggregated averages, not URL-by-URL measurements. An individual page may perform well even while being lumped into a group marked as 'Poor' due to structural issues affecting other pages of the same template.

Conversely, a problematic page may go unnoticed if the overall group shows good performance. This logic necessitates reasoning by type of page rather than by isolated URL when auditing and fixing CWV issues.

Why do noindex pages appear in CrUX?

Chrome collects performance data regardless of indexability. The browser does not parse meta robots tags, does not check robots.txt, and does not verify X-Robots-Tag headers. It simply measures user experience across all pages visited by real users.

A direct consequence: pages blocked from indexing, poorly secured staging URLs, or test pages in production can pollute your CrUX metrics if they receive traffic. Google aggregates this data into the corresponding groups, potentially skewing the analysis for SEOs who expect to see only indexable pages.

• CrUX measures real user experience, not a page's ability to be indexed
• Metrics are grouped by page similarity or at the domain level depending on the volume of data
• A noindex page can influence your Core Web Vitals if it receives organic, direct, or referral traffic
• Search Console reports display group averages, rarely page-by-page data
• The granularity of data depends on traffic: the more visited the site is, the finer the groups can become

Is this grouping mechanism consistent with real-world observations?

Yes, absolutely. SEO audits have confirmed for years that the CWV reports from the Search Console present aggregated data by template or page type. An e-commerce site often sees its product pages grouped together, its category pages in another cluster, and its homepage isolated if it receives significant traffic.

What still surprises many practitioners is the latency between fixing and updating metrics. Fixing a Cumulative Layout Shift issue on one page doesn’t immediately change anything in the Search Console: we must wait for the group to accumulate enough new real measurements, which can take several weeks. [To be verified]: Google has never specified the minimum data threshold required to create a distinct group.

What are the grey areas and limitations of this statement?

Mueller remains deliberately vague on the grouping criteria. We know that Google uses 'similar pages', but no official documentation details the criteria precisely: common HTML structure? URLs sharing a pattern? Identical backend template? This opacity makes blind optimization difficult for sites with complex architecture.

Another critical point: the presence of noindex pages in CrUX creates a methodological paradox. Google recommends not indexing certain pages to avoid duplicate content or low-value pages, but these same pages can degrade the Core Web Vitals of the group they belong to. The result: a site can be penalized on a ranking criterion because of pages explicitly excluded from ranking.

When does this grouping system pose problems?

Sites with hybrid architectures are most affected. Imagine a media site that mixes lightweight AMP articles, long-format resource-heavy reports, and event pages with heavy third-party scripts. If Google groups everything into a cluster 'editorial content', the metrics become unusable to diagnose precisely where to act.

International sites with language versions on the same domain also encounter grouping ambiguities. Does CrUX aggregate by language, by user geolocation, or globally? No official confirmation. The same applies to sites with separate URLs for mobile and desktop versions: are the data separated or merged?

What should you prioritize in an audit to understand your CWV groupings?

Start by exporting CrUX data via BigQuery or the CrUX API. Unlike the Search Console, these sources offer URL-by-URL granularity for pages with sufficient traffic. Cross-reference this data with your Analytics tagging plan to identify which templates or site sections are dragging down the metrics.

Next, list all noindex or blocked pages that receive significant real traffic — old URLs soft-404 redirected, preview pages accessible without authentication, poorly isolated testing environments. If these pages correspond to a template also used in indexable production, they pollute your CWV groups.

How to optimize when metrics are grouped rather than individual?

Think by type of page, not by URL. Identify common templates — product page, category page, blog post, landing page — and optimize the source code at the template level. A 200 ms gain on the Largest Contentful Paint of a product page template benefits the entire group, not just one isolated page.

Prioritize templates that generate the most qualified organic traffic. A template used by 10,000 pages but with a total of 50 monthly visits does not impact Core Web Vitals as much as a template used by 100 pages receiving 50,000 visits. Focus your efforts where the volume of real data is sufficient to influence the grouping.

What mistakes should you avoid in tracking and correcting Core Web Vitals?

Never rely solely on Lighthouse or PageSpeed Insights to validate your optimizations. These tools measure in a lab environment, with standardized network and hardware conditions. The Core Web Vitals that count for ranking come from CrUX, thus from real users with variable connections, heterogeneous devices, and unpredictable browsing behaviors.

Also, avoid fixing page by page without a comprehensive view. If you manually optimize 20 critical URLs but the common template used by 500 other pages remains faulty, the grouping will continue to show poor metrics. The effort must be structural: template redesign, lazy loading at the CMS level, global server optimization, CDN for static resources.

• Export CrUX data via BigQuery or the API to identify problematic URLs and groups
• List all noindex pages receiving traffic and check if they pollute their group's metrics
• Prioritize optimizations by template and real traffic volume, not by subjective editorial importance
• Cross-reference CrUX data with Analytics to understand which user journeys degrade metrics
• Test corrections in production with Real User Monitoring (RUM) tools before validating their effectiveness
• Monitor group evolution in the Search Console for at least 28 days to confirm the impact of optimizations