Add up every query and you get less than your site total

The discrepancy anyone can reproduce in ten minutes

Open the Performance report in Search Console. Pick a three-month window ending three days ago. Search Console lags two to three days and restates the most recent ones, so a window running to today moves under you while you work. Write down the two totals at the top: clicks (people who came to your site from a result) and impressions (times one of your pages appeared in a result someone saw). Now export the query table and add up each column in a spreadsheet.

Both sums land short. How short each one lands depends on the site. On most, clicks come closer to the total than impressions do, because the searches Google withholds are the rare ones that earned an impression and no click.

The first explanation to rule out is a row limit, because there really is one and it has nothing to do with this. The interface draws about a thousand rows and its export carries what it drew, so of course a thousand rows do not add up to a site. The API pages past that, up to 25,000 rows per request, asked again and again with a higher starting row until Google hands back an empty page. That gets you far more than the interface will draw, but not everything: a single-day query pull stops at 5,000 rows however you ask for them, so on a busy day the tail is cut before anonymization is even in the picture. Ask for the whole window in one request rather than day by day and you have close to every query Google is willing to name. The sum is still short.

There is a second check that does isolate it, and it takes about a minute. For one week, add up the query list's clicks and divide by the clicks the date report gives for the same week. Now do exactly that for ninety days. The share the query list accounts for goes up with the length of the window: same site, same traffic, same export, and nothing changed except how many searches cleared the threshold over a longer period.

Why Google does it, described fairly

A search query is a sentence a stranger typed into a box, and it is often the most personal thing they will produce that day. People search their own name next to a symptom. They search an address, a court case, an employer, a phone number, a private worry phrased in the first person. If a query was typed by only a handful of people over a period, handing it to the owner of the site that appeared can identify one of them, and the site owner is not somebody they chose to tell.

So Google withholds them. The published term is anonymized queries: searches made by very few unique users over the period you asked about are removed from the query dimension entirely. Their clicks and impressions stay in your property totals (nothing is deleted from your traffic), but the text is never named.

Google does not publish the threshold, and no version of the API reveals it. Whatever the reason, the practical consequence is the same: you cannot compute the cut-off, only measure the hole it leaves. Every honest number about this is therefore a measurement taken on your own property, not a rule you can apply to it in advance.

It is worth being clear that this is not a paywall and not a quota. There is no tier of Search Console that returns the withheld queries, no API scope that unlocks them, and no vendor with a back door. The BigQuery bulk export does not restore them either: as documented in September 2026 it marks the anonymized rows rather than naming them, so it tells you the size of the hole precisely and tells you nothing about what is inside it. It also only records forward from the day you set it up, so it cannot even do that for last year. Whatever a tool calls it, no Search Console integration can return the withheld queries, because the API does not carry them. If a tool shows you keywords Search Console will not name, those keywords came from a source other than your Search Console data, and it is fair to ask which one.

Why the withheld searches are the rare ones, and what that does to each column

The threshold applies to whole queries. A query is named or it is not; nothing is ever partially withheld. So the question is not how much of your traffic is hidden but which queries are, and the answer is always the same population: the rare ones.

Think about what a rare query looks like in your data. Someone typed a long, oddly specific phrase. You appeared, well down the page. You were seen a handful of times. Nobody clicked. That row is several impressions and zero clicks. Multiply it by the thousands of such phrases a real site is shown for, and you have a large pile of impressions attached to almost no clicks.

Now think about where your clicks actually live. They concentrate in the phrases many people type: your brand, your main service, the obvious question your best page answers. Those are common by definition, which is exactly why they clear the threshold and get named.

The two facts compose, and on most sites they compose in the same direction: withholding rare queries removes a great deal of impression volume and comparatively little click volume, so the named list holds a larger share of your clicks than of your impressions, and a CTR summed from it reads high. Treat that as the usual shape rather than a law. Properties measured on this product have come out the other way round, with the named list covering more of the impressions than of the clicks. The ordering is a fact about a particular property's data, not a property of the mechanism. What always holds is that neither column sums to the site total, so the size and the direction of your gap are things to read off a coverage line under the table rather than assume.

It gets steeper the more dimensions you ask for at once. Query crossed with page, device and country is a much finer slice, so far more of it falls under the threshold. That detailed pull is truncated as well as thresholded, so two effects land on the same number and neither one alone accounts for it. Our own sync writes a warning into the log when the query-and-page detail it just pulled accounts for less than 25% of the clicks the property recorded over those same days. Both halves of that ratio have to describe the identical days: an earlier version divided a seven-day numerator by a ninety-day denominator and reported roughly a twelfth of the truth on every routine sync. On a site with a broad long tail that warning is a normal Tuesday, not an incident. The same query-by-page data has a second trap worth knowing: an impression of a query that surfaced three of your pages is counted once against each page, so adding that column up across pages overshoots the query it came from.

What this does to every metric built on a query list

Once you know the list is a sample with a known bias, every number computed from it inherits that bias, and some of them are wrong in a way that looks perfectly reasonable on screen.

1. CTR.

   Click-through rate is clicks divided by impressions: of the people who saw you, how many came. Compute it by summing a query list and you are dividing a numerator that lost one amount by a denominator that lost another, and the two amounts are never equal. The result is wrong by construction, and on the usual shape (a withheld tail heavy with impressions and empty of clicks) it is wrong upwards. This is the number printed as "average CTR" at the top of a great many query tables. Put it next to the CTR from your property totals for the same days and the two will disagree. If you are using CTR to judge whether a title is doing its job, the baseline you are judging against is not the site's.

2. Keyword counts.

   "You rank for 4,000 keywords" means four thousand queries Google was willing to name over that window. Widen the window and the number grows without a single ranking changing.

3. Brand versus non-brand splits.

   Brand terms are common, so they are nearly always named. Long-tail non-brand phrases are exactly what gets withheld. A brand share computed from a query list therefore runs high.

4. Average position.

   Average position is where your link sat in the results, averaged over every impression. Position 1 is the top result. It is a real average of a real population, just not your site's: it describes the queries Google named, weighted by their impressions, and the queries it did not name are absent from it entirely.

5. Comparisons between two periods.

   This is the one that produces confident, wrong stories. Diff last month's query list against this month's and you get a list of "new" and "lost" keywords, most of which are neither. A search can cross the anonymity threshold in either direction while your ranking for it sits exactly where it was. That is why the movement analysis in our own product is defined only over the queries named in both windows, and why arrivals and departures are counted beside that comparison rather than folded into it: they are reporting events, not ranking events. Searches with fewer than three impressions in a window are left out of the movement statement as well, because one impression carries no meaningful average position, and the number left out is printed on the screen rather than quietly absorbed.

The limit on all of this: the withholding lives in the query dimension and nowhere else. Your clicks and impressions by date are complete, and your per-page numbers, pulled as date crossed with page, have no withheld tail either: every page Google served is named. One warning if you sum them: impressions are counted per page, so a results page that showed two of your URLs is two page impressions and one site impression, and the page column adds up to more than the site rather than less. Clicks do not have that problem, because a click lands on one page. Site totals still come from the property-level numbers.

What an honest interface does about it

None of the above can be fixed. It can be stated, which is a different thing and is the whole of the obligation.

Under our query list is one sentence, in the product, in plain words: these queries hold ~X% of the property's clicks and ~Y% of its impressions in [dates], and the rest belongs to queries Google anonymizes. Both halves are checkable. The numerator is the query set on the page, added up. The denominator is your property's own daily totals over the same ninety days, which are complete. Both are Google's own numbers; the line is just their ratio, and you can reproduce it in a spreadsheet. It also tells you which way your own gap runs, which is the part no article can tell you.

That table is a fixed trailing ninety days and says so, because it is one stored set of query totals rather than something the date picker can reshape. Search it or switch on a filter and the coverage line disappears, because the denominator is then no longer your property and a percentage against a filtered numerator would be meaningless. Worse than meaningless, since it would still look like a fact. Filter to a device or a country and the disclosure changes rather than vanishes: what gets printed instead is what the numbers are, a query-by-page sample, where an impression is counted once per page, because there is no property-level mobile total to divide by.

The same statement travels with the file. Exports carry a header giving the window, the coverage, and one flat sentence saying that summing the file does not give site totals. Export while a filter is on and the header says the file is not filtered even though the table was, because a spreadsheet named after a segment gets summed as that segment by whoever opens it next, and by then nobody remembers where it came from.

The rule underneath all of it is simple enough to hold anyone to: the query total is never presented as the site total. Site totals come from the complete property series. Query lists are labelled as what they are. Where we show the queries behind a single page, that list is called a sample and prints the share of that page's clicks it accounts for. Clicks, not impressions, because a click lands on one page while an impression is counted once per page, so an impression-based coverage there could read above 100% and mean nothing. A sample without its coverage is just an assertion.

And the honest limit on our own answer: coverage tells you how much is missing, not what. We cannot give you the withheld queries, and neither can anyone else. What we can do is make sure you never mistake the part for the whole.