Search Console query coverage
The clicks in a query table often do not add up to the total on the chart above it. Google documents several reasons, and which of them bear on the report in front of you depends on how it was requested. What is rarely said is that quoting a share of the gap means naming the population you divided by, and that the share can differ between clicks and impressions on the same pull.
The reasons, and when each one applies
Four are documented, and they are habitually discussed as though they were one thing. They are not, only the first is what people mean when they say a query was anonymised, and each carries a condition worth reading before it is applied to your own report.
- Queries too rare to show
- A query searched by only a few people over a period is left out of the table to protect the person who searched it. Google states that these rows are omitted from the table but included in the chart totals, unless a query filter is applied, in which case the totals change too. There is no row for the remainder, so the table cannot be made to add up by summing harder.
- The table's row limit, which is not the API's
- The interface table displays at most a thousand rows, and rare or long-tail rows past that are absent from it while remaining in the chart total. A request made through the Search Console API is a different instrument: it takes a row limit of its own and pages through results. The example below is an API request that asked for up to 25,000 rows and received 3,328, so this reason did not apply to it at all.
- Aggregation, when a filter changes it
- Grouped by property, several results from one site appearing for a single search count once between them; grouped by page, each of those results counts. Google documents this as something a page or search appearance filter brings about, changing how the chart and the table are aggregated, so it is a condition of the report in front of you rather than a standing difference between every chart and every table.
- The filter itself
- Applying a filter changes which rows the totals admit, so a filtered total is a total of that population and not of the property. Google notes that filtered figures may not reconcile with unfiltered ones for this reason together with the omissions above.
An export gives you no way to tell which of them contributed to a given difference, or by how much. So the honest name for the remainder is not represented, rather than anonymised or missing. Anonymised names one of the four as though it were all of them, and missing suggests something went wrong, which the file does not show either way.
How much of a Search Console report do the query rows hold
Not a constant, and one pull settles it for no other property. Over 28 days the query rows we pulled for a single cluster returned 636,317 impressions and 820 clicks. Against that cluster's canonical page count those are 78.5% of impressions and 45.7% of clicks; against the wider set of rows the page filter matched, 76.3% of impressions. Which population the query rows were drawn from is not established by the export, so each share is reported against the denominator it used. Report clicks and impressions separately and do not assume their coverage shares are equal.
Here is that measurement in full, so its shape is visible rather than asserted. It comes from a 28-day window, 2026-08-13 to 2026-09-09, on a property we operate. The query rows were requested through the API for one family of pages rather than for the whole property, filtered on a substring of the address, with a row limit of 25,000: 3,328 queries came back, carrying 636,317 impressions and 820 clicks.
The page rows for that same family, counted as findings 01 and 02 count them, come to 810,421 impressions and 1,793 clicks over the same days. Divide and the query rows come to 78.5% of those impressions and 45.7% of those clicks. Two shares from one pull, more than thirty points apart, which is enough to show that the two metrics need not agree. It is not enough to say that one never indicates the other, and this page does not claim that. Report them separately.
Why the denominator has to be stated
Those page rows were matched by a substring of their addresses, and the same filter caught 7 rows ending in a fragment, carrying 23,342 impressions. The page count discards those rows before counting rather than folding their impressions into the addresses they belong to, so they are absent from the 810,421 above. Measured instead against every row the filter matched, the query rows come to 76.3% of impressions rather than 78.5%.
Nothing in the export says which of those two populations the query rows were drawn from. Each share is correct about its own denominator and neither is established as the coverage of the cluster, so the pair is reported rather than one of them chosen. That is the part worth carrying away: a share needs both sides taken on the same terms, and a share quoted without its denominator is not a measurement of anything. The sample report works the same pull through in the five sections a diagnostic has.
Measuring your own
What has to hold is compatibility: the same dates, the same filters, the same search type, and populations you can name on both sides. Our own example above combines a separate query request with the page export, and that separation is not what gives it two candidate denominators. Requests made apart can describe compatible populations perfectly well. The two arise because the page calculation discards fragment rows that the query filter did not exclude, so the export does not establish that the returned query rows match the population used by the canonical page count.
An unmodified zip from one Performance export keeps the exported tables and the filters they were made under together, which is convenient and is what the query coverage tool reads. It does not settle compatibility by itself: the populations and the aggregation still need checking before a ratio between them is read as coverage. What the tool does is the division on your own file, in your browser, with nothing uploaded and nothing kept, reporting the share the rows hold, naming the remainder as not represented, and refusing to say which of the reasons above the remainder consists of, because the file cannot show that.
What the number is good for is narrow and worth stating. It tells you how much of your own report a query-level reading describes, which is the difference between saying these are our queries and saying these are the queries the request returned. It does not tell you what the rest of them were, and no arithmetic on the same file will recover them.
What it does not mean
A low share is not by itself a fault or a penalty. Where demand is spread thinly across many rare phrases, rows omitted for rarity are expected to account for more of the total than where it concentrates on a few common ones, so the figure describes the distribution of your demand as well as the reporting. How much of any particular gap that accounts for is not something one export settles.
It is also not a licence to rescale. Taking a query-level figure and dividing it by the share, to estimate what the whole would have been, assumes the rows that came back behave like the rows that did not, and the export offers no support for that. The method page sets out the rules every figure on this site follows, including that one.