Why does the mobile usability report only cover a sample of your pages?

What exactly does Google mean by 'sample'?

When John Mueller speaks of a sample of pages, he confirms that Google does not test every indexed URL to generate the mobile usability report. The algorithm selects a representative subset — but no one knows the actual coverage rate.

This choice is likely based on crawl and analysis resource constraints. Testing mobile usability on millions of pages for each site would consume colossal bandwidth. Therefore, Google prefers to sample and extrapolate.

Why is this approach problematic for large sites?

For a site with 10,000 URLs, a sample of 500 pages may seem reasonable. But if an error affects 200 very specific pages — for example, a product category using a particular template — there is no guarantee that Google will include them in its sample.

The result: you may have critical mobile usability errors that never appear in Search Console. You thought you were clean, but part of your site fails to meet mobile-friendly criteria without you knowing it.

How does Google select the tested pages?

Google does not publish any details on the selection criteria for the sample. It can be assumed that it prioritizes high-traffic pages, recently crawled URLs, or dominant templates. But this is speculation.

This lack of transparency makes any optimization strategy risky if you rely solely on the report. You optimize what Google shows you — not necessarily what truly matters to your users.

• The mobile report covers only a subset of your indexed pages, never the entirety.
• For large sites, errors may exist on non-sampled pages and remain invisible.
• Google does not communicate the selection criteria for the sample — impossible to predict which URLs will be tested.
• The sampling approach reduces analysis costs on Google's side, but limits the reliability of the report for practitioners.
• A 'validated' site in Search Console may still have undetected mobile usability issues.

Is this statement consistent with field observations?

Absolutely. For years, we have observed that the mobile report in Search Console does not capture all manually identifiable errors. Clients with thousands of pages have seen issues with intrusive interstitials or unreadable text appear on URLs that Google has never flagged.

What is surprising is that Google still does not specify the sample size or its renewal method. Is it a static or dynamic sample? How long does it take for a page to enter the tested scope? No official answers. [To be verified]

What nuances should be added to this limitation?

Sampling is not inherently bad — it is a valid statistical method. But it performs poorly when usability errors are concentrated in specific subsets (for example, a product sheet template failing across 300 URLs).

Furthermore, even if Google tests a sample, there is no indication that it applies this limit to mobile-first indexing itself. All of your pages are still evaluated for ranking — only the report consolidates data from a subset. A crucial nuance.

When does this approach become really problematic?

On sites with high template heterogeneity: multi-brand e-commerce, content aggregators, sites with sections developed by different teams. Each template may have its own vulnerabilities, and the sample risks capturing only a fraction.

Another critical case: sites with partial updates. You fix an error on 1,000 pages, but if Google only samples 50 of them, the report may take weeks to reflect the improvement — or worse, it will continue displaying the previous error.

What concrete steps should be taken to address this gap?

Implement regular manual tests on a representative sample of your pages. Use Google's Mobile-Friendly Test URL by URL, or better yet, third-party tools like Screaming Frog with mobile emulation to crawl all of your site.

Automate these checks: a script that tests 100 random URLs per week will give you much better coverage than what Google reports in Search Console. Focus on high-volume templates and strategic pages.

What mistakes should be avoided in light of this limitation?

Never settle for correcting only the URLs flagged in Search Console. If an error appears on 5 pages, it likely affects 50 — or even 500 if it's a template flaw. Trace it back to the source and fix the pattern, not just the symptoms.

Also, avoid over-interpreting variations in the report. An error that disappears does not necessarily mean you fixed it — Google may have simply re-sampled to other pages. Conversely, a new error may have been present for months without ever having been detected.

How can you verify that your site is truly compliant?

Audit your Core Web Vitals on mobile with tools like PageSpeed Insights across a wide range of URLs. Test the actual mobile display on different devices (not just Chrome emulation). Ensure that your interstitials, pop-ups, and buttons comply with the guidelines.

Set up continuous monitoring with alerts on critical metrics. If your CLS or LCP degrades on mobile, you'll know before Google samples it — or not.

• Regularly crawl all of your URLs in mobile mode with Screaming Frog or equivalent
• Manually test a representative sample of pages each week with the Mobile-Friendly Test
• Monitor your mobile Core Web Vitals across a wide panel of URLs, not just those reported by Google
• Systematically fix errors at the template level, not just the individual URLs flagged
• Automate mobile regression tests after each deployment or content update
• Never consider the absence of errors in Search Console as an exhaustive validation of your mobile compliance