How does Google really assess the Core Web Vitals of a page in its search results?

Why does Google group URLs instead of evaluating each page individually?

The grouping by page type solves a major technical issue: not all URLs generate enough real-world data for a statistically reliable assessment. The Chrome UX Report is based on real user data from Chrome, and a seldom-visited page does not offer a sufficient sample size.

Google therefore applies a clustering logic: pages that share a similar technical structure (same template, same type of content) are grouped together. The LCP, FID, and CLS metrics are averaged at the group level. An orphan page in traffic inherits the performance of its more visited counterparts.

What does this really change for ranking?

Let's imagine two scenarios. First case: your product sheet X generates 10 views/month but belongs to the group "e-commerce product sheets" that displays excellent metrics thanks to the bestsellers. This page X benefits from a positive signal, even with minimal traffic.

Second case: you meticulously optimize a strategic landing page, but the rest of the group (100 similar pages) shows catastrophic Core Web Vitals. Your optimized page will be penalized by the average of the cluster. It’s brutal, but logical: Google assesses the systemic ability of the site to deliver a good experience, not isolated successes.

What weight do high-traffic URLs have in this mechanism?

Mueller notes that highly visible URLs have a greater impact on the group's evaluation. In other words, the calculation is not a simple arithmetic average. A homepage receiving 50% of the group's traffic will weigh much more than a niche page at 0.1% visibility.

This creates a powerful leverage effect: optimizing the star pages of the group improves the overall score of the entire cluster. Conversely, a degraded key page contaminates the whole. This weighting by actual traffic introduces a hierarchy of priorities: focus first on the URLs that attract visitors; the rest will follow mechanically.

• Core Web Vitals are not evaluated URL by URL, but by groups of structurally similar pages
• The Chrome UX Report aggregates real-world data at the cluster level to compensate for the lack of traffic on certain pages
• High-traffic pages weigh more heavily in the group's metric calculations, creating a domino effect
• An orphan page inherits the performance of the group it belongs to, for better or for worse
• Search Console materializes this grouping in its reports, allowing identification of problematic clusters

Is this grouping mechanism consistent with real-world observations?

Yes, and it explains some of the anomalies observed for months. How often have you seen a technically perfect page stagnate while a mediocre page from the same site ranks better? Grouping introduces a form of mutualization: you no longer play alone, but as a team.

Where it gets tricky is in the definition of groups. Google talks about "page types", but the exact criteria for clustering remain vague. Same template? Similar URL pattern? Common schema tags? [To be verified] — no official documentation details the segmentation algorithm. We navigate by instinct, cross-referencing Search Console and the CrUX Report to deduce group boundaries.

What are the limits of this cluster-based approach?

The main issue is the contamination effect. An e-commerce site with 10,000 product sheets and 50 optimized bestsellers can have its entire catalog penalized if the remaining 9,950 pages are technical disasters. You optimize 0.5% of the group; the remaining 99.5% pull everything down.

Another limit: hybrid pages. A landing page that is half editorial, half product—what group does it belong to? If Google places it in the wrong cluster, it inherits metrics that do not reflect its technical reality. The result is inconsistencies between actual performance and Search Console evaluation. [To be verified] on atypical architectures — the grouping logic shows its flaws as soon as we step off the beaten path.

Should you worry about traffic weighting?

It depends on your visibility distribution. If 80% of traffic concentrates on 20% of pages (classic Pareto law), and those 20% are optimal, you're covered. The group will display good metrics even if the rest lag behind.

But if your traffic is diluted over hundreds of moderately visited pages, none will weigh enough to elevate the group. You enter a gray area where every page counts a little, but none really decides. In this case, optimization must be systemic: it’s impossible to just pamper a few stars. The entire infrastructure must hold up.

How to identify groups of URLs in Search Console and prioritize tasks?

Go to Search Console > Experience > Core Web Vitals. Click on "Poor URLs" or "URLs to Improve". Google displays examples, but more importantly, it indicates the number of URLs affected by group. A group of 2,000 pages in red is a structural task. A group of 5 pages is a localized anomaly.

Cross-reference with the PageSpeed Insights API or the CrUX Report to obtain detailed metrics by sample URL. Identify the star pages of the group (analytics, organic traffic GSC) and audit them as a priority. If they are poor, they are the ones dragging down the entire cluster. If they are clean but the group remains red, dig into the long tail: a systemic issue affects the entire template.

What optimizations should be deployed to improve an entire group?

Forget about page-by-page optimizations and aim for the template. A group often shares the same HTML structure, scripts, and server. Fix at the level of the reusable component: lazy loading of images, deferring third-party JS, reducing the DOM, optimizing server TTFB.

Focus first on the high-traffic URLs of the group. A concrete example: your homepage and your 10 main categories attract 60% of visits from the "navigation pages" cluster. Optimize these 11 pages as a priority; they will pull the group's average up through visibility weighting. The rest will follow mechanically in the overall evaluation.

What mistakes to avoid in this grouping logic?

The first mistake: over-optimizing an isolated page while ignoring the rest of the group. You can achieve a 1s LCP on a landing page; if the other 500 pages in the cluster plateau at 4s, your page inherits a poor score. The ROI of isolated optimization is close to zero.

The second mistake: neglecting orphan pages with low traffic but numerous. Even with a low individual weight, 5,000 poor pages end up weighing heavily in the average. If you can’t optimize them all, consider a strategic noindex: remove them from the indexable perimeter to cleanse the remaining group. It’s harsh but sometimes necessary.

• Audit Search Console to map groups of URLs and their CWV status
• Identify high-traffic pages in each group (analytics + GSC) and prioritize them
• Optimize at the shared template level, not page by page
• Measure the impact with the CrUX Report after deployment (28-day delay to see effects)
• Consider noindexing or removing pages that are impossible to optimize and of little strategic value
• Monitor the evolution of groups in Search Console monthly