The Search Console 1,000-row limit and anonymised queries

The Google Search Console web interface shows at most 1,000 rows in any table, and exports to Google Sheets, Excel or CSV are cut to the same 1,000 rows. The Search Console API returns up to 25,000 rows per request and exposes at most 50,000 rows per day per search type, sorted by clicks. On top of both limits, Google leaves out rare queries to protect searchers’ privacy. These anonymised queries count in the chart totals but never appear as rows, which is why the rows in a query table never add up to the total above it.

None of this is a bug, and most of it can be worked around. Here is what each limit is, where the gaps come from, and how to get more of your data out.

The limits at a glance

Where you read the data	Row limit	Notes
Performance report table	1,000 rows	Google: “Our tables can show a maximum of 1,000 rows”
Export to Sheets, Excel or CSV	1,000 rows	Totals in the export are actual totals, not capped ones
Search Console API, one request	1 to 25,000 rows	Default is 1,000; page through with startRow
Search Console API, per day	50,000 rows per search type	Top rows, sorted by clicks
Bulk data export to BigQuery	No row cap stated	Google: “all the performance data available”, except anonymised queries

What are anonymised queries?

Google’s help (which spells it “anonymized”) puts it in one line: “Some queries are omitted from the report to protect user privacy.” These are rare queries, and Google’s data documentation says it may not track some queries that are made a very small number of times at all.

The important behaviour is how they are counted. Anonymised queries are included in the chart totals, so the clicks and impressions at the top of the Performance report contain them. They are never shown as rows in the Queries table. And the moment you apply a query filter, such as “queries containing” or “queries not containing” a word, they drop out of the totals too.

That last point catches out anyone splitting branded from non-branded traffic. Filter for your brand name, then for everything not containing it, and the two totals add up to less than the unfiltered figure. The difference is the anonymised long tail, which belongs to neither side because Google never tells you what it was.

Google does not publish a typical share, and it varies by site. A site whose traffic comes from a few head terms should lose little this way; a site living on long, specific queries is likely to see more of its impressions behind the curtain. The section below shows how to measure yours.

Why the rows never add up to the total

Three separate effects stack up, and it helps to know which one you are looking at.

Anonymised queries. Counted in the chart total, absent from the table, as above. This one affects the Queries view.

Truncation. Google says that “due to internal limitations, Search Console stores top data rows and not all data rows”. The interface shows up to 1,000 of them; the API’s documentation says it “does not guarantee to return all data rows but rather top ones”. Google’s API guide adds that when you group by page or query, “our system may drop some data”.

Aggregation. The chart is always aggregated by property: if two of your pages appear for one search, that counts as one impression. The Pages table is aggregated by page, so the same search counts once for each page. Queries, countries, devices and dates are aggregated by property. So the Pages table can legitimately add up to more than the chart total, while the Queries table adds up to less. Search Console metrics explained goes further into how clicks, impressions and position are counted.

How to see more than 1,000 rows

1. Shorten the date range. The 1,000-row cap applies to whatever range you pick, so a single week surfaces different long-tail rows from a three-month view. Exporting week by week builds a fuller list.
2. Filter before you export. Filter by page or folder (for example, URLs containing /blog/), by country or by device, and each slice gets its own 1,000 rows.
3. Use the API. Request 25,000 rows at a time and page with startRow until a response comes back empty. Google’s own guide on getting all your data recommends querying one day at a time, and each day can return up to 50,000 rows per search type. Requests grouped or filtered by page or query are the expensive ones, so do not run them in tight loops.
4. Turn on the bulk data export. It sends a daily copy of the property’s performance data to BigQuery, which Google describes as all the performance data available to Search Console for the property, anonymised queries excepted. It needs a Google Cloud project with billing, and it does not backfill: it starts from the day you set it up. How long Search Console keeps data covers the setup.
5. Add URL-prefix properties for big sections. Google suggests a separate property for each subpath you want to track. A /blog/ property has its own 1,000-row tables, so the blog’s long tail is no longer competing with the rest of the site for the same rows.

How to measure your anonymised share

With the bulk export, it is one query. Rare queries arrive as rows with is_anonymized_query set to true and an empty query field, so you can sum them directly:

SELECT
  SUM(IF(is_anonymized_query, clicks, 0)) / SUM(clicks) AS anonymised_click_share,
  SUM(IF(is_anonymized_query, impressions, 0)) / SUM(impressions) AS anonymised_impression_share
FROM `your_project.searchconsole.searchdata_site_impression`
WHERE data_date BETWEEN '2026-09-01' AND '2026-09-30';

Without the export, you can estimate it from the API. Request the property’s totals for a day with no dimensions, then request the same day grouped by query and page through every row. The gap between the two is anonymised queries plus whatever was truncated, so treat it as an upper bound. The Search Console help on dimensions and data groupings has Google’s own description of what is left out.

What it means in practice

For most decisions, the top rows are what matter: rows are sorted by clicks, so the queries and pages that carry your traffic are not the ones that get cut. The limits bite in three places. Long-tail research, where the interesting queries are exactly the rare ones. Reconciliation, when a client asks why the queries in a report do not add up to the headline number. And branded versus non-branded splits, where the anonymised remainder belongs to neither. For the second, the honest answer is a sentence in the report: the total includes searches Google does not itemise, for privacy reasons.

Where QueryWatch fits

QueryWatch reads the same Search Console API, so the same rules apply to it. Its Queries and Pages tabs show the top 100 rows for the range you choose, alongside the country and device splits, and the gap between those rows and the property total is there for the same reasons. That is a deliberate fit for a phone: the top 100 is what you scan on the move, and striking distance picks out the queries at positions 8 to 20 worth working on. For complete long-tail data, use the bulk export on a laptop. The app is described on the QueryWatch page; QueryWatch is independent and not affiliated with Google.