Grouping by query and page at once, and what Search Console withholds
Ask for query and page together and you get one row per pair — a genuinely useful shape, and one whose totals will never add up to the chart above it.
Grouping Search Console data by query and page at once gives you one row for each combination of the two: this query, landing on this URL, with its own clicks, impressions, click-through rate and average position. It is the most useful shape the Performance report can produce, and it is also the shape whose totals are furthest from the chart above it. Two things remove rows before you ever see them. Google omits anonymised queries to protect user privacy, and Search Console stores and shows only the most important data rows rather than every row that exists. Sum the pair table and you will always be short.
A query and page pairing returns one row per unique combination, not a query list annotated with pages. If the same query brought traffic to three different URLs on your site, that is three rows, each carrying the clicks and impressions attributable to that pair. In the Search Console interface this is what you get by opening a page in the Pages tab and then switching to Queries with the page filter still applied, one page at a time. Through the Search Analytics API it is a single request with both dimensions named, and the rows come back already paired.
Pairing is worth the trouble because it answers questions neither dimension can answer alone. A query with good impressions and poor clicks might be doing badly everywhere, or it might be doing well on one page and badly on another that Google keeps choosing instead. A page that lost clicks might have lost one important query or spread a small loss across a hundred. Only the paired rows distinguish those cases, and the distinction usually decides what you do next.
Search Console withholds two different kinds of row, and they behave differently in your totals. Anonymised queries are omitted from the report to protect user privacy; Google states that they are still included in chart totals, unless a query filter is applied, in which case they drop out of the totals as well. Separately, Search Console documents that due to internal limitations it stores and shows only the most important data rows, so not every query beyond the anonymised ones appears in the table either. Google names bulk data export as the route to the most complete list of queries.
| Grouping | What a row means | Why the sum is short |
|---|---|---|
| Dates only | One row per day for the whole property | Nothing is withheld at this level |
| Pages | One row per canonical URL | Rows Search Console chose not to store |
| Queries | One row per query string | Anonymised queries plus unstored rows |
| Queries and pages | One row per query and URL pair | Both effects, applied to a much longer tail |
| Any grouping, with a query filter applied | Rows matching the filter | Anonymised queries leave the totals as well |
Search Console's Performance report is a rolling sixteen-month window. At month fifteen the first month your site ever had is still inside it, and two months from now it will not be.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
The chart above the Performance table is not a plot of the table. Google documents that graph data is always aggregated by property, regardless of the dimension selected, while choosing the Pages dimension aggregates the table by page. So a paired table can be internally consistent and still sum to less than the line above it, and that difference is not a bug you can configure away. Any report you build should either quote the chart figure as the property total or quote the table sum as a floor, and should say which one it is doing.
This is the same family of problem as totals that disagree between two Search Console views, and the practical defence is the same: never present a derived total without saying how it was grouped. A number labelled "clicks" with no grouping attached is not reproducible by the person you gave it to.
The page dimension groups data by the final URL linked by a search result after any redirects, and most performance data is assigned to the page's canonical URL rather than to a duplicate. Google is explicit that when a user clicks a duplicate URL in search results, the click counts towards the canonical URL, not the URL the user visited. In a paired table this means a query you expected to see against one address appears against another, and the address it appears against is the one Google chose as canonical, which you can look up with the URL inspection tool.
Pair the dimensions when the question is about a specific page or a specific query, and skip the pairing when the question is about totals. Diagnosing why one article stopped earning clicks is a paired question: you want its queries, not the site's. Reporting how much search traffic the site earned last month is not a paired question, and answering it from a paired table will understate it. Choosing the grouping to fit the question is not a technicality; it is the difference between a number somebody can act on and a number somebody will quietly stop trusting.
Because two kinds of row are missing. Anonymised queries are omitted from the report to protect user privacy, and Search Console also stores and shows only the most important data rows rather than the complete set. Both effects hit hardest at the finest grouping, which is exactly what a query and page pairing is. The table is accurate about the rows it contains and incomplete about which rows it contains.
Google documents that anonymised queries are included in chart totals, and omitted from the query table. The exception matters: if you apply a query filter, such as queries containing or queries not containing a string, the anonymised queries drop out of the totals as well. That means the same date range can report different totals depending only on whether a query filter is switched on.
Yes, and it is far more practical for anything beyond a handful of pages. A single request naming both the query and page dimensions returns rows already paired, where the interface requires filtering to one page at a time. The withholding behaviour is the same either way: the API is subject to the same anonymised queries and the same row storage decisions as the report.
The page dimension groups by the final URL after redirects, and performance data is assigned to the canonical URL rather than to a duplicate. A click on a duplicate in search results counts towards the canonical. If a paired row names an address you did not expect, check which URL Google has selected as canonical for that page with the URL inspection tool before assuming the data is wrong.
No. In the table, average position is the average position for the specific grouping shown in that row, so a paired row reports the position of that page for that query. The chart reports the average position of the topmost result from the whole property. Reading a paired row's position as if it described the page across all queries is one of the easier ways to reach a confident wrong conclusion.
Search Console has no language dimension. On a site in more than one language you separate the data by page or by country, which means the URL structure you chose for translations decides what you can measure.
A report that arrives every Monday whether or not anything happened teaches its reader to ignore it. Three constraints fix that: alert only above a severity floor, only on kinds worth interrupting somebody for, and only when the finding is new.