Why do the figures in Search Console never match between graphs and tables?

Where do these data discrepancies in Search Console come from?

When you filter a performance report by queries or by pages, you may have noticed that the total shown in the graph never exactly matches the sum of the lines in the table. This difference is not a bug — it’s a feature documented by Google.

The first mechanism at play: automatic anonymization. Google removes from reports any query deemed potentially identifiable to an individual user. If a search is too rare, too specific, or associated with sensitive content, it simply disappears from the table. It remains counted in the overall graph but becomes invisible at the granular level.

The second mechanism: a technical limitation on the number of exportable rows. Search Console can only display a finite number of queries in the table — typically 1,000 lines in the interface, up to 50,000 through the API. Beyond that, the least performing queries (in terms of clicks or impressions) simply don’t show, even if they contribute to the total displayed in the graph.

What is the actual extent of these data losses?

This is where it gets complicated. Google does not publish any figures on the percentage of anonymized or truncated traffic. Depending on the sites, the gap can range between 5% and 30% of total traffic — sometimes more for sites with a very broad long tail.

The most affected sites? Those that generate a massive volume of unique or very low-volume queries (editorial blogs, e-commerce with thousands of niche references, local news sites). Conversely, a site with a strategy heavily focused on a few main keywords will see a much smaller gap.

Does this limitation also affect the Search Console API?

Yes, but in a different way. The API allows extraction of up to 50,000 rows per query (compared to 1,000 in the interface), which mechanically reduces the loss related to truncation. However, the anonymization remains the same: queries filtered for privacy also disappear from the API.

Specifically, if you extract your data via the API, you reduce the gap related to the technical limit but not the one related to privacy. For a site with 200,000 unique monthly queries, you will remain in the dark about a significant portion of the traffic, regardless of the situation.

• Privacy anonymization: Google masks rare or sensitive queries in detailed tables
• Technical limitation: 1,000 rows max in the interface, 50,000 via API — beyond that, long-tail queries vanish
• Variable gap: between 5% and 30% of total traffic may be invisible depending on site structure
• No official figure: Google does not communicate the anonymization rate per site
• Stronger impact on the long tail: editorial or niche e-commerce sites are most affected

Is Google's explanation consistent with field observations?

Let’s be honest: this statement formalizes a frustration that all experienced SEOs have been experiencing for years. The gaps between graphs and tables are not new, but Google finally publicly admits that they are intentional and structural — not accidental.

That said, one point remains unclear: Google never specifies the exact criteria for anonymization. When is a query deemed "too sensitive" or "too rare"? No numerical data. This is frustrating for a practitioner who must justify a 20% gap between their GSC exports and their Google Analytics traffic. [To be verified]: it is impossible to reliably reproduce the threshold for anonymization — each site seems to be treated differently.

What nuances should be added to this statement?

The first nuance: this limitation only concerns reports filtered by queries or pages. If you consult the overall graph without filtering, you see the total traffic. The problem arises as soon as you try to cross-reference the data or segment finely.

The second nuance: the gap varies greatly depending on your traffic structure. A site with 80% of its traffic on 50 main queries will see a minimal gap. A media site with 500,000 monthly queries, of which 90% each generate less than 5 clicks? The gap can explode. This is a structural problem for long-tail analysis.

The third nuance — and this is where it gets tricky: Google provides no means to reconcile missing data. Unlike Google Analytics 4 where you can at least see a line for "(other)", the Search Console makes data disappear without a trace. You know something is missing, but you cannot quantify precisely what.

In what cases does this explanation fail to account for discrepancies?

Be careful: not all discrepancies are due to anonymization or truncation. If you observe massive differences (>40%) between GSC and GA4 on Google traffic, other causes are likely at play: tracking issues, misconfigured redirects, unfiltered bot traffic in GA4, or counting discrepancies between sessions vs clicks.

Moreover, this statement does not cover the discrepancies between GSC and other tools (SEMrush, Ahrefs, etc.). These tools estimate traffic — they do not measure it. Their margin of error is structurally higher and independent of Google’s anonymization mechanisms.

How to correctly interpret your Search Console data despite these discrepancies?

First rule: never compare the total of the graph with the sum of the table. It’s a waste of time — the two figures will never match by design. Instead, use the graph for macro trends (overall rise/fall, seasonality) and the table to identify your top performers and detect optimization opportunities on visible queries.

Second rule: if you need a comprehensive view, cross-reference GSC with Google Analytics 4. GA4 captures all actual organic traffic (except for strict anonymization of query strings in referrers), giving you a more complete picture. The residual gap between GSC and GA4 indirectly indicates the volume of anonymized or truncated data made by Google.

Third rule: if you work on long-tail sites, invest in extraction via API rather than manual interface. Moving from 1,000 to 50,000 rows mechanically reduces the data loss associated with technical truncation. While it doesn’t solve anonymization, it limits the damage.

What mistakes should be avoided in analyzing your reports?

Classic error: exporting the first 1,000 lines of the performance report and calculating an average CTR by dividing clicks/impressions from the table. This CTR will be biased upwards because truncated queries (often low-performing) are not counted. Always use the CTR displayed in the overall graph, which includes the total traffic.

Another pitfall: believing that the gap is stable over time. If your SEO strategy evolves towards more niche content (e.g., shifting from a general blog to dozens of microtopics), the share of anonymized or truncated traffic will mechanically increase. Your GSC exports will become less and less representative of actual traffic, without it meaning a degradation in performance.

What should you do concretely to limit the impact of these data losses?

If you manage an e-commerce or editorial site with thousands of pages, implement an automated reconciliation system between GSC (via API) and GA4 (via BigQuery if high volume). This allows you to quantify the residual gap and alert you if it exceeds an abnormal threshold (a potential sign of a technical problem).

For client SEO audits, always include a methodological note explaining this gap. This avoids misunderstandings when the client compares your GSC figures with their GA4 and notices a 15% difference. Document the gap from the start to avoid unnecessary questioning.

• Use the GSC graph for overall trends, the table for top performers only
• Always cross-reference GSC with Google Analytics 4 for a comprehensive view of organic traffic
• Prefer extraction via API (50,000 rows) over manual interface (1,000 rows)
• Never calculate average metrics (CTR, position) based solely on the table — use the overall metrics from the graph
• Document the expected gap in your client reports to avoid misunderstandings
• Monitor the evolution of the gap over time: a sudden increase may signal a tracking or configuration issue