Does the number of pages in Search Console's Core Web Vitals reports fluctuate for no apparent reason?

Why does Google sample Core Web Vitals data in Search Console?

Search Console cannot audit in real-time every loading of every page of every website. Google collects data through the Chrome User Experience Report (CrUX), which aggregates field metrics from real Chrome users. This collection produces massive data volumes.

For infrastructure and statistical relevance reasons, Google selects a representative sample of pages and user sessions. This sample varies based on several factors: site traffic, crawl frequency, template diversity, and traffic seasonality. As a result, the number of audited pages displayed in Search Console may increase or decrease without any actual performance changes.

Does this fluctuation mean my data is inaccurate?

No. Statistical sampling remains reliable when properly sized. Google states that the presented samples are "significant," meaning they are large enough to be representative of the site's overall behavior.

However, be cautious: a small site with low traffic may see significant sampling variations proportionally. If your site receives 500 monthly visits, the sample may range from 50 to 150 pages from one month to the next, giving the impression of improvement or degradation when nothing has actually happened. Larger sites are less affected by these side effects.

What should you concretely monitor in these reports?

Google's message is clear: focus on the nature of errors, not on the volume of audited pages. If 200 pages show an LCP above 4 seconds, it doesn't matter if the total sample is 500 or 700 pages — the problem is identified and needs fixing.

Variations in the total number of pages are not an actionable KPI. What matters is the evolution of the percentage of failing pages on each metric (LCP, FID, CLS) and the persistence of these errors over time. If 40% of your pages remain red on LCP for three months, it's a strong signal — even if the absolute number of audited pages varies.

• Do not rely on the total number of pages displayed in the report to assess progress.
• Focus on specific URLs that are failing and performance patterns (types of pages, templates).
• Check the consistency between Search Console and PageSpeed Insights or other CrUX tools to confirm trends.
• Understand that the sample may include low-traffic pages: prioritize fixes on high-traffic pages.
• Wait several weeks before judging the impact of an optimization — variable sampling may mask or delay real improvements.

Is this statement consistent with field observations?

Yes, and it's a relief that Google is making this official. Unexplained fluctuations in the Core Web Vitals reports of Search Console have been documented since the launch of these metrics. Many SEOs have observed increases or decreases in the number of audited pages with no technical changes or traffic variations.

Let's be honest: this variability poses a problem. A client who sees the number of "bad pages" jump from 150 to 250 in a week panics, even if no real degradation has occurred. Google should have communicated this sampling mechanism earlier to avoid misinterpretations and unnecessary optimizations.

What limitations does this approach impose on SEO audits?

Variable sampling makes it difficult to finely track improvements. You may fix an LCP issue on a specific template, but the following month’s sample may not include enough pages of that template to validate the effect. You may then have to wait several update cycles — potentially 6 to 8 weeks — to confirm a trend.

Furthermore, [To check] Google does not specify the exact criteria for sample selection. Is it pure random sampling? Weighted by traffic? By template diversity? This opacity prevents anticipating which segments of the site will be audited. For an e-commerce site with 50,000 products, the sample may overrepresent certain categories one month and underrepresent others the following month.

When should you be cautious about these reports?

Low-traffic sites: if your site receives fewer than 1,000 monthly visits from Chrome, the CrUX sample may be too small or unstable to be useful. You’ll see brutal variations that reflect nothing concrete.

Recently migrated or relaunched sites: after a redesign, the sample may take weeks to stabilize. Do not draw hasty conclusions about post-migration performance until at least a full month of CrUX data has been collected. And that’s where it gets tricky: how often does a client demand a report "15 days after going live"?

How to correctly interpret volume fluctuations in Search Console?

Do not react to a one-off variation in the number of audited pages. If the report jumps from 400 to 600 pages in a week without any technical change, it’s probably just the sampling varying. Instead, focus on the proportion of failing pages in each metric.

Document each major technical change with a precise date. This will allow you to correlate performance changes with concrete actions, taking into account the CrUX refresh delay (about 28 days of rolling data). If you optimize images on March 1st, do not assess the impact until the beginning of April.

Which metrics to track to evaluate real improvements?

Focus on the percentage of green, orange, and red pages for each Core Web Vital, not on the absolute values of audited pages. A decline from 60% to 40% of red pages on LCP is a strong signal, even if the total number of pages goes from 500 to 450.

Utilize complementary tools to Search Console: PageSpeed Insights for spot testing, BigQuery to leverage raw CrUX data (if you have the skills), or third-party RUM solutions for real-time tracking. These tools are not affected by Search Console’s variable sampling.

How to manage a Core Web Vitals optimization project in this context?

Prioritize fixes by business impact, not by the volume of reported pages. If 10 strategic pages (SEA landing pages, main category pages) are in red, address them first even if 200 other minor pages are also flagged.

Establish a monthly review with screenshots of the Search Console reports and contextual notes (deployments, traffic spikes, events). This log will help you distinguish real progress from the background noise related to sampling. And be transparent with your clients or management about this sampling mechanism — explaining that "the number of pages can vary without real change" helps avoid misunderstandings.

• Monitor the percentage of failing pages, not the absolute number of audited pages.
• Wait at least 4 to 6 weeks after an optimization before measuring the impact in Search Console.
• Cross-reference Search Console data with PageSpeed Insights, BigQuery CrUX, or third-party RUM tools.
• Document each technical change with a precise date and description to facilitate retrospective analysis.
• Prioritize fixes on high-traffic and high-business-impact pages, not across the entire sample.
• Internally communicate about the variability of sampling to avoid unfounded panic reactions.
  Core Web Vitals are a real ranking lever, but monitoring them via Search Console requires method and perspective. Variable sampling means prioritizing long-term trends over weekly variations. If this data reading and prioritization of technical projects seem complex to orchestrate internally, working with a specialized SEO agency can save you time and secure your investments. Field expertise allows for quick differentiation between signal and noise — and to avoid costly optimizations on false problems.