Why Search Console Query Rows Do Not Match Totals: A 28-Day Benchmark

Google Search Console totals do not match the sum of visible query rows because anonymized queries and other truncated rows can remain in property totals while their query text is omitted from the table and Search Analytics API response. Measure the difference as an unitemized share, not as a recoverable list of hidden keywords.

In Aident's latest complete 28-day window, Search Console reported 2,450 total clicks, while the 3,394 named query rows summed to 1,142 clicks. The unitemized difference was 1,308 clicks, or 53.39 percent of the property total. That gap is real, but it does not reveal which query strings produced the clicks.

This guide shows how to reproduce the comparison with Codex and Aident Loadout, preserve the method, and avoid making content decisions from a privacy-filtered sample as if it were a complete keyword database.

What Did the Aident Benchmark Find?

We compared two equal, complete 28-day periods for the aident.ai domain property. Each total request used final web data, property aggregation, no dimensions, and no filters. Each named-query request kept the same scope and added only the query dimension. The current Aident Search Console Action accepted up to 25,000 rows, and both exports finished below that request limit.

The named query inventory grew from 981 rows to 3,394 rows, but its click coverage fell. That does not prove that Google hid more valuable keywords, that AI search caused the gap, or that a particular content change caused the movement. It proves only that the visible query rows represented a smaller share of the property totals under the same extraction method.

Google documents two relevant limits. Rare queries can be anonymized to protect user privacy, and Search Console can retain only top data rows rather than every row. Both effects can make a query-row sum lower than the unfiltered total.

Why Should You Call It an Unitemized Share?

The difference contains clicks and impressions that cannot be assigned to a visible query string in this API response. Calling every missing row an "anonymized keyword" overstates what the data proves.

Use these formulas:

unitemized clicks = total clicks - sum(named query clicks)
unitemized click share = unitemized clicks / total clicks

unitemized impressions = total impressions - sum(named query impressions)
unitemized impression share = unitemized impressions / total impressions

The metric describes reporting coverage. It is not a ranking score, a traffic-quality measure, or a keyword opportunity count.

This distinction matters when a team says, "Search Console shows 2,450 clicks, so why can we explain only 1,142 of them?" The correct answer is that Search Console preserved the property total while withholding or truncating some query-level detail. No query filter can reconstruct text that the API did not return.

What Do You Need Before Running the Comparison?

Prepare:

• a verified Google Search Console property;

• a connected Google account with read permission;

• the public Aident CLI installed and authenticated;

• one complete analysis window and an equal prior window; and

• a written extraction method that fixes data state, search type, aggregation, filters, row limit, and pagination.

Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then confirm the account and Vault state:

aident account auth status
aident vault vault --action status

If the property is not connected, start with How to Connect Google Search Console to Codex With Aident Loadout.

Step 1: Inspect the Current Search Analytics Schema

Ask Codex to search the live Aident catalog for the Search Console Action that returns clicks, impressions, CTR, and position. Inspect its current schema before execution instead of copying an internal Action identifier into a permanent workflow.

Confirm:

• the property identifier exactly as the connected account returns it;

• start and end dates;

• final data state;

• web search type;

• property aggregation;

• dimensions;

• row limit and pagination; and

• any country, device, page, or query filter.

Run a small proof request before the full extraction. A successful proof should return the selected property and numeric metrics without changing Search Console.

Step 2: Request the Property Total Without Dimensions

Run the first request with no dimensions and no dimension filters. Keep the date range, data state, search type, and aggregation explicit.

Conceptually, the input is:

{
  "start_date": "2026-07-29",
  "end_date": "2026-08-25",
  "dimensions": [],
  "data_state": "final",
  "search_type": "web",
  "aggregation_type": "byProperty"
}

Store clicks, impressions, CTR, and average position as the property total. Do not infer a keyword count from this row.

Step 3: Request and Sum the Named Query Rows

Run the second request with the exact same scope and add only the query dimension. Use the largest reviewed row limit the current schema supports and paginate until a response contains fewer rows than requested.

Preserve:

• the number of returned query rows;

• the sum of their clicks;

• the sum of their impressions;

• the request limit and number of pages; and

• the extraction timestamp.

Search Analytics prioritizes top rows. A response that finishes below the request limit is still not proof that the API exposed every query because anonymization and internal data limits can apply before pagination.

Step 4: Calculate Coverage Without Guessing the Missing Queries

Subtract the named-query sums from the property totals, then divide each difference by its matching total. Keep click coverage and impression coverage separate.

Clicks answer how much observed traffic can be assigned to named queries. Impressions answer how much observed visibility can be assigned. A site can have a much larger impression gap than click gap because rare long-tail impressions often produce no click.

Do not generate synthetic query strings to fill the gap. Do not distribute the difference across visible rows. Do not use third-party keyword estimates as if they identified the withheld Search Console rows.

Step 5: Compare Equal Complete Windows

The gap becomes more useful when the method stays fixed across time. Compare the latest complete period with the immediately preceding period of equal length.

Review these movements together:

Use named rows for query-level prioritization. Use the property total for reach. Keep the coverage gap beside both so stakeholders understand the limits of the visible inventory.

When Should You Use Bulk Export?

Google's Search Console bulk export can preserve anonymized rows with an empty query and an anonymization flag. That makes it better for warehouse-scale counting and longer retention, but it still does not reveal protected query text.

Use the Search Analytics API when you need a bounded, current agent workflow and the connected property already exists. Evaluate bulk export when daily row volume, warehouse joins, or retained history justify the additional Google Cloud setup. Do not claim a direct API comparison unless both systems were actually configured and tested under the same scope.

Common Mistakes

Treating the Difference as Lost Traffic

The clicks exist in the total. The missing element is query-level detail, not the visit itself.

Calling Every Difference Anonymization

Google also documents top-row limits and aggregation effects. Use "unitemized" unless your data source explicitly marks an anonymized row.

Applying a Query Filter to Recover Hidden Text

Filtering removes or reshapes the anonymous portion. It cannot reveal a query string that the report withheld.

Mixing Aggregation Methods

Page aggregation and property aggregation can return different totals. Keep aggregation identical within the comparison and explain any separate page-level analysis.

Turning a Coverage Gap Into a Content Brief

A large unitemized share does not name a reader problem. Draft only from visible demand, verified community evidence, product evidence, or another source that can support a distinct canonical.

Reusable Codex Prompt

Paste this after setup and replace the bracketed values:

Use Aident Loadout to inspect the current Google Search Console Search Analytics schema and list the properties available to my connected account. Ask me to select the exact property. Run one proof read, then compare [current start] to [current end] with the immediately preceding equal period. For each period, request final web property totals with no dimensions and no filters, then request named query rows with the same scope and bounded pagination. Calculate named and unitemized clicks, impressions, and coverage shares. Treat the difference as unitemized reporting coverage, not a list of recoverable keywords. Preserve the dates, aggregation, limits, row counts, extraction time, and formulas. Do not submit a sitemap, change a property, expose credentials, invent hidden queries, or perform another write.

Set up Aident Loadout and measure your Search Console query coverage.

Next, use the keyword-footprint workflow to keep ranking buckets beside clicks and impressions. If multiple pages appear for the same visible query, continue with the cannibalization review.

Sources

• Google Search Console troubleshooting for chart and table discrepancies

• Google Search Console dimensions, anonymized queries, and data truncation

• Google Search Analytics query method

• Google Search Console bulk export table reference

• Google Search Console bulk export query examples

• Aident Loadout setup

Refresh this benchmark when Google's reporting rules or the live Search Console schema changes, or when a comparable complete period establishes a more useful coverage baseline.