Search Console Queries Don't Add Up: 9.5% Was Visible

By Ugur Saritepe · October 3, 2026

My Search Console query table showed 234 impressions and no clicks. The same property, the same 90 days, said 2,472 impressions and 12 clicks. Neither number is wrong and neither pull was truncated. Here is what each one actually counts.

The same window, pulled four ways

traffictriage.com is this site, and it is small enough to be useful here: every pull fits inside the row limit, so nothing below is a truncation artefact. Search Console data on it is complete through 2026-09-29, so that is where every window ends. Property totals for the 90 days from 2026-07-02: 2,472 impressions, 12 clicks, average position 24.6.

grouping            rows  truncated  impressions   of total  clicks  of 12
["query"]             68  false              234      9.5%       0      0%
["page"]              40  false            2,543    102.9%      12    100%
["query","page"]      70  false              234      9.5%       0      0%

Read the first two rows together, because that is the part nobody warns you about. Group by query and 90.5% of the impressions have no row. Group by page and you get 2.9% more impressions than the property recorded. Two different errors, pointing in opposite directions, in one window on one site. The number you quote depends entirely on which tab you were standing in when you wrote it down.

Why the query table is short

Google withholds queries that too few people search, and it is explicit about where those impressions go. The Search Console documentation on data discrepancies calls them anonymized queries and says they are omitted from the table, but are included in the chart totals unless a query filter is applied. So the rows and the total are measuring the same traffic; one of them is just allowed to skip most of it.

The clicks column on our property is the cleanest demonstration I have. All 68 query rows read zero clicks. The property recorded 12. So every single click this site earned in 90 days came from a query Google will not name. Our six clicking pages are all visible by page: the Vercel guide at 6, the homepage at 2, and four more at 1 each. The queries that earned them do not exist as rows anywhere.

That is the practical cost, and it is not an accounting curiosity: the question "which query is making me money" has no answer on this property at all, while the question "which page is" has a complete one.

Why the page table is long

The over-count is documented too, in a different place, which is part of why the two halves of this are rarely told together. Google's page on dimensions states that the graph data is always aggregated by property, regardless of the dimension selected while choosing the Pages dimension aggregates the table by page instead. Its impressions reference gives the worked example: one search element containing several of your links is counted either by URL or by property depending on the filtering options, so a single result block can be 1 impression by property and 5 by page.

On a site like this one that is easy to trigger. I have 56 posts, most of them on overlapping indexing and Search Console symptoms, so one search showing two of them is ordinary. Our 90-day page table runs 71 impressions ahead of the property total on 2,472, which is the right direction and a small magnitude. I want to be careful here: that figure is consistent with the documented rule, but I did not capture an individual search returning two of our pages, so the attribution is inference from Google's own description, not a receipt.

Adding the page dimension recovers nothing

The obvious next move is to pull query and page together and read which page each query hit. It does not help. Same 90 days, both dimensions, 70 rows, truncated: false, and the impressions sum to 234, identical to the query-only pull to the unit.

The two extra rows are the only two queries on the whole property that split across two pages, and both reconcile exactly: chatgpt mcp seo as 4 impressions on the pillar plus 1 on the ChatGPT post against a query-only row of 5, and seo mcp server for chatgpt as 4 plus 2 against a row of 6.

So 2,309 of our 2,472 impressions have a page attached and no query attached. Adding a dimension cannot recover them, because anonymization is applied to the query, not to the row. The only two things that change the number are a bigger site or a different question.

Does traffic fix it

Partly. game-scout.app is my games site, roughly 200 times this one on clicks, and its best-detective-games page took 2,362 impressions and 87 clicks in the fortnight to 2026-09-29. Filtering the query pull to that one page returns 106 rows, truncated: false:

property / page                       impressions in rows   clicks in rows
traffictriage.com, 90d                     234 / 2,472  9.5%      0 / 12   0%
traffictriage.com, 14d                        19 / 336  5.7%       -        -
game-scout best-detective-games, 14d      724 / 2,362 30.7%     33 / 87  37.9%

Coverage rises with volume and stops well short of complete. A page with 87 clicks in a fortnight still shows under 40% of them by query. That 37.9% is not a new measurement either: it is the same figure I hit on this page when I was working out why pages lost rankings with nothing changed, re-pulled on a different day and landing on the same number.

What this quietly breaks

Three normal pieces of SEO work read wrong once you know the shape of the gap.

• Exporting the query table and calling it your keyword set. On this property that export is 9.5% of the traffic and none of the revenue. Any share or percentage computed from it is a share of the visible slice, not of your site.
• Checking tabs against each other to find a discrepancy. Google's own traffic-drop guide tells you to check every tab, queries, URLs, countries, devices, search appearances, and says nothing about the tabs not reconciling. They will not reconcile, and the mismatch is not a finding.
• Average position read off the query table. It is a mean weighted by impressions, computed over whichever rows survived, which is a different question from the one you asked. We took that metric apart separately.

There is a ranked answer worth correcting on the second point. Search Engine Journal's write-up of John Mueller on this, from March 2022, has it that page-level reports show all the data while query-level reports leave the anonymized queries out. The first half is where our data disagrees: on this property the page level does not show all the data, it shows 102.9% of it. The direction of the page error is the part that goes missing when the story is told as an anonymization story only.

What this does not tell me

• This property is tiny. 12 clicks in 90 days means our 9.5% is a floor, not a typical figure, and the 0-of-12 clicks result is as much about having 12 clicks as about anonymization. Do not expect your own number to be this bad.
• The over-count is one property, two windows. Plus 71 impressions on 2,472 and plus 7 on 336 are consistent in direction and small in size. I have not measured it across sites, and I have not isolated a search that returned two of our pages.
• The high-traffic control is one page on one site. Two points, 9.5% and 30.7%, do not describe a curve.
• Nothing here says what the hidden 90% contains. Anonymized means withheld, not categorised. I know the volume I cannot see and nothing about its shape.

One more, on our own tool rather than on Google. Our MCP server caps this pull at 250 rows and we have not raised it. Google's API allows 1 to 25,000 rows and pages with an offset; ours allows 250 and has no offset. Every traffictriage.com pull above came back truncated: false, so the cap changed nothing here. On game-scout's whole property it bit immediately: rowCount: 250, truncated: true, which is why the control above is one page rather than the site. The coverage test this post teaches cannot currently be run property-wide on the larger of my two sites with my own tool, and that is a gap in our product, not in Google's.

How to check your own property

Four pulls, about five minutes. The point of doing all four is that any single one of them looks authoritative on its own.

1. Get the property total with no dimensions at all. One window, no grouping. This is the only number that is simply your traffic, and everything else gets compared to it.
2. Group by query and add the impressions up. Divide by the total from step 1. That percentage is how much of your search traffic you can see at the query level. Check the truncation flag first: if the result was capped, you measured your row limit instead.
3. Group by page and add those up too. Expect slightly more than 100%. If you get a lot more, you have pages that regularly appear together in one result block, which is worth knowing on its own.
4. Compare the clicks columns, not just impressions. Clicks are the sharper test because there are fewer of them, so the share Google withholds is more visible. Ours was 0 of 12. If yours is low, every query-level conclusion you have drawn is drawn from the minority of your traffic.

If the gap turns out to be large, the practical move is to do your diagnosis by page and use queries only on the pages big enough to show them. That is the order the page-selection read already uses, and it is also why we reconcile against analytics by country rather than by query when Search Console and GA4 disagree. If you want the raw-HTML and indexing side of a page checked at the same time, the free triage report runs eight checks from the URL alone.

What we have not done

We have not raised the 250-row cap, and the session this post was built from is the session that found the limit. We also have not explained the other thing our own property did in this window: daily impressions ran 44 on 2026-09-25 and then 16, 15, 4 and 2, an 83% fall week over week while average position improved 2.3 places. Re-reading those five days a day later returned the same five numbers, so it is not a reporting lag on the days that have data. It is unexplained, and it is not this post's subject. The rest of these reads are in the AI-assistant SEO series.

FAQ

Why don't my Search Console query rows add up to the total?

Because Google leaves rare queries out of the table and counts them in the total anyway. On traffictriage.com over the 90 days to 2026-09-29 the property total was 2,472 impressions and 12 clicks, and the query table held 68 rows carrying 234 impressions and no clicks at all. That is 9.5% of the impressions and 0% of the clicks. The pull was not truncated, so the missing 90% is not a row limit. Google calls the hidden rows anonymized queries and says they are omitted from the table but included in the chart totals.

Why does Search Console show more impressions by page than in total?

Because the two numbers are aggregated differently. Google's documentation says the chart is always aggregated by property while choosing the Pages dimension aggregates the table by page, so one search that shows two of your pages counts once for the property and twice by page. On our property the page table summed to 2,543 impressions against a 2,472 property total over the same 90 days, which is 102.9%. Nothing is broken and nothing is double-counted by mistake.

Does grouping by query and page together fix the gap?

No. We ran the same 90-day window with both dimensions at once and got 70 rows summing to 234 impressions, identical to the query-only pull. The two extra rows were two queries that split across two pages. So 2,309 of our 2,472 impressions have a page attached but no query, and no combination of those two dimensions reaches them.

Does the gap close on a site with real traffic?

It narrows and does not close. On game-scout.app's best-detective-games page, 2,362 impressions and 87 clicks in the fortnight to 2026-09-29, the query pull returned 106 rows untruncated holding 724 impressions (30.7%) and 33 clicks (37.9%). So a page with 200 times our click volume still showed under 40% of its clicks by query. Treat the query table as a sample of your head terms, never as your query list.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works