Search Console Anonymized Queries: Why Totals Differ

Search Console anonymized queries are searches Google deliberately leaves out of the query-level data to protect the privacy of the people who typed them. Their clicks and impressions still count in your property totals, which is why the number above the chart and the sum of the rows in the query table almost never match. Nothing is broken, and no filter of yours is at fault.

The practical problem is that most reporting treats the query table as if it were the whole population. It is a sample with a privacy-shaped hole in it, and the hole is not random: it is biased toward rare, specific searches. This post explains what gets removed, why the gap moves around, how to measure it for your own site, and how to write reports that stay honest about it.

What Google Actually Removes From Query Data

Google's documentation says that some queries are anonymized to protect the privacy of the user issuing them. The stated idea is that a query which very few people have searched could, in principle, identify a person, for example a search containing a name, an address, a medical detail or a pasted account number. Those queries are not shown in the query dimension. Google has described them as queries not issued by more than a few dozen users over a period of months, but it does not publish an exact threshold, and you should not build a model that depends on a specific number.

Two details matter. First, the removal applies to the query text only. The click or impression that the query produced is still counted against the site, the page and the country, so totals that do not involve the query dimension stay complete. Second, the removal is applied before you ever see the data. You cannot request the hidden queries with a different filter, a different date range or a different API call, because they are not retrievable through Search Console at all.

This is also separate from the other reasons a Search Console number can look short. Row limits on the interface, the cap on rows returned per day by the API, and data that simply has not finished processing are all different mechanisms. Keeping them apart is the first step in diagnosing a mismatch, because each has a different fix.

Why the Totals and the Table Disagree

Open the Performance report for a site, look at the total clicks above the chart, and then add up the clicks in the Queries tab. The second figure is lower. The difference is the clicks from anonymized queries, plus any rows cut off by the display limit. If you export the table and sum it, you are summing only the queries Google chose to disclose.

The behaviour changes depending on what you do in the report, and this is where people get confused. With no query filter applied, the chart and the headline totals include everything, anonymized or not. The moment you add any filter on the query dimension, including a simple contains filter or a regular expression, Google has to evaluate each query against your condition, and anonymized queries cannot be evaluated, so they drop out of the totals entirely. The headline number shrinks, and that shrinkage is partly the filter and partly the missing privacy-filtered data, which is easy to mistake for a real drop.

The same thing happens when you compare pages. Filter to one URL, and the totals for that URL include all its clicks, but the query table underneath lists only disclosed queries. A page can show 400 clicks in the header and a query table that adds up to a fraction of that. On a page that earns traffic from a long tail of unusual phrasings, the table can account for well under half of the clicks. Treat that as a normal property of the data, not a fault to report.

How Big the Gap Usually Is

Nobody outside Google can give you a universal figure, and any blog post that quotes one as a fact is guessing. What you can say is what drives the size. The gap grows with the share of your traffic that comes from long, specific, low-repeat searches. A site whose traffic is dominated by a few hundred head terms repeated by thousands of people will see little anonymization. A site in a detailed technical niche, a marketplace with huge catalogues, a support or forum site, or any property where people search with error messages, part numbers and full questions will see much more.

It also grows with how conversational search has become. Long natural-language questions are unlikely to be typed identically by many people, so they fall below the disclosure threshold more often than short keywords do. A site that has recently started earning visibility for long-form answers may see its disclosed share fall even while total traffic rises, which can look alarming in a query-level dashboard and is actually a sign of where the growth is coming from.

The only reliable way to know your number is to measure it, and it takes two minutes. Take the total clicks for a fixed period with no dimension filter. Take the sum of clicks across the exported query rows for the same period, making sure you pulled every row available. The difference divided by the total is your undisclosed share for that window. Record it, because it is a property of your site that shifts slowly, and a sudden jump is itself a finding worth investigating.

A Worked Example With Illustrative Numbers

The numbers below are made up to show the arithmetic, not a benchmark. Imagine a documentation site that, for a 28-day window, shows 50,000 total clicks in the Performance report with no filters. The query export, summed, lists 31,000 clicks. The undisclosed share is 19,000 divided by 50,000, or 38 percent. That is the portion of traffic for which you can know the page, country and device but not the words.

Now an analyst filters for queries containing the word pricing and sees 2,400 clicks. A manager reads this as the site getting 2,400 clicks from pricing searches. The truer statement is that at least 2,400 disclosed clicks matched, and that an unknown additional number from anonymized queries could also have contained the word. If the undisclosed share is 38 percent and you assumed the same mix, the pricing figure could be materially higher, but assuming the same mix is exactly the assumption you cannot verify, because anonymized queries are skewed toward rarer phrasings.

The lesson from the example is about wording. Say at least, say disclosed, and say what share of total clicks the table covers. Those three habits turn a figure that invites an argument into one that survives scrutiny.

Where Else the Hidden Data Shows Up

The same issue appears wherever the query dimension does. In the API, the query rows you request are the disclosed ones, and summing them will not match a request for totals with no dimension. In the bulk export to BigQuery, Google keeps anonymized rows instead of discarding them: the query field is empty and a flag marks the row as anonymized, so the clicks and impressions stay attached to the page and country. If you work with that export, this lets you calculate the undisclosed share exactly and by page, rather than estimating it from the interface.

Third-party tools that pull query data through the API inherit the same gap. A rank or keyword dashboard that sums its query rows will undercount clicks versus Search Console's own totals, and two tools that both claim to show Search Console data can disagree with each other if one of them stores rows differently or drops rows beyond a limit. When a stakeholder asks why the dashboard does not match the report, the first questions are whether a query filter is applied and whether the sum includes the empty query row.

Impressions behave the same way, but position is trickier. Average position is calculated from the rows involved in the current view, so the position you see for a query-filtered view reflects only disclosed queries, and the number can shift when you change the view even though nothing about your rankings changed. Comparing average position across differently filtered views is a common source of false conclusions.

Reporting Around the Gap

The aim is not to recover the hidden queries, which is impossible, but to stop the gap from distorting decisions. A few working rules keep reports defensible.

Anchor every query-level statement to a total. Show the headline clicks for the same period and state what share the query table represents. A single line under the chart, such as disclosed queries account for a stated share of clicks, prevents most misreadings.

Report trends on totals and on pages, and use queries for diagnosis rather than measurement. Page-level and site-level data are complete. Query data is the place to find themes, compare phrasings and spot opportunities, and it is reliable for that purpose even when it is incomplete, because the disclosed queries are still real searches.

• Use no-filter totals as the source of truth for traffic trends, and never subtract or divide query-filtered totals against unfiltered ones.
• Group queries into themes using a consistent, documented set of rules, and label the group totals as disclosed clicks.
• Track the undisclosed share monthly. A sharp change usually signals a change in the mix of searches, a tracking or property change, or an export that dropped rows.
• When estimating a theme's true size, give a range with stated assumptions rather than a single extrapolated figure.
• For landing-page analysis, pair Search Console page data with your analytics sessions, which count visits regardless of query, and note that the two will still not match exactly.

Mistakes That Waste Time

The most common mistake is debugging a mismatch that is not a bug. Someone sees 12,000 clicks in the header and 8,000 in the table, suspects a tracking fault, and spends a day checking properties and filters. Check for the privacy gap first: remove every filter, compare totals, and compute the undisclosed share.

A second mistake is concluding that a query has lost traffic because it vanished from the table. A query can disappear from the list simply because it fell below the disclosure threshold for that period, even though the people searching it still arrived. Before reporting a loss, check the page-level clicks for the pages that used to rank for it. If page traffic held, the query likely dropped out of disclosure, not out of the results.

A third mistake is comparing the query table in Search Console to a keyword tool's estimated clicks and treating one as the error. They measure different things: one is real but partial, the other is modelled. Use each for what it does well, and avoid forcing them to reconcile.

Finally, be careful with the download button. The interface export is limited to the rows the report displays, so an export is not the complete disclosed set, and a sum of it understates even further. If precision matters, use the API with pagination or the bulk export, and record which method produced each figure so the next person can reproduce it.