Search Console data limits: row caps, anonymised queries, API and bulk export

Search Console is the only source of Google's own data about your search performance, and it is incomplete by design. Some limits come from the interface, some from privacy rules, some from storage. Each one produces a familiar complaint: "the rows don't add up", "I can't see my long-tail queries", "the data stops after 16 months", "the export only has 1,000 rows". This guide lists the limits, what each one hides, and the workaround.

The limits at a glance

Limit	What you notice	Workaround
Interface tables show up to 1,000 rows	Exports from the Performance report stop at 1,000 queries or pages	Filters to narrow the view; the API; bulk export
Anonymised queries	Query rows add up to less than the chart total	None for the queries themselves; use page-level data and totals
About 16 months of history	Older data disappears	Regular exports or bulk export to your own storage
Data delay	Last two days look low and change later	End comparisons a few days back
API row limits and quotas	Large sites cannot pull every query-page combination daily	Bulk export to BigQuery
Aggregation differences	Totals by page differ from totals by property	Compare like with like; understand the two methods

The 1,000-row interface limit

The query and page tables in the Performance report, and their exports, show at most 1,000 rows. For small sites that is everything. For larger sites it is the top slice. Two ways around it inside the interface:

• Filter first, then export. A filter by page section, country or a regex pattern returns a different top 1,000 each time. Several filtered exports can cover much more than one unfiltered one. The regex filters guide has patterns for splitting by section and query type.
• Use shorter date ranges. The top 1,000 for each week differs from the top 1,000 for the quarter.

Beyond that, the API or bulk export is the right tool, and for anything you report on regularly it is worth setting up once rather than repeating manual exports every month.

Anonymised queries

Google does not list queries that very few people searched, to protect user privacy. Their clicks and impressions still count in the chart totals and in page-level data, but they never appear as query rows. On sites with a long tail of specific searches, which describes most content-heavy and e-commerce sites, a large share of clicks can be attributed to these hidden queries.

Practical consequences:

• Never add up query rows and compare them with the chart total.
• Query-filtered totals exclude anonymised queries, so they are smaller than they would be in reality.
• Page-level data includes everything, so it is the better base for traffic analysis; use query data to explain why pages perform as they do.
• The share of hidden queries itself is informative: a growing share suggests more long-tail, specific searches.

There is no workaround that reveals the anonymised queries. The bulk export marks them as anonymised rather than listing them.

Sixteen months of history

The Performance report keeps roughly the last 16 months. Year-over-year comparisons therefore work only within that window, and once data ages out it is gone. If long-term trends matter, and they usually do for seasonal businesses and for reporting to clients, store the data yourself:

• Monthly exports of page and query data (within the row limits) into a spreadsheet or database.
• A scheduled pull through the API.
• Bulk export to BigQuery, which accumulates daily data indefinitely in your own project.

Tools that pull Search Console data daily, such as DeskSEO once Search Console is connected, store it day by day for the queries and pages they track, which makes per-query trends easy to read. For history beyond 16 months, though, plan on exports or bulk export.

The API

The Search Analytics API returns the same data as the Performance report, with more rows: up to 25,000 per request, with paging. Google documents daily limits on how many rows of query and page combinations you can retrieve per property and search type, and per-minute quotas on requests. For most small and mid-sized sites, the API returns essentially everything except anonymised queries. For very large sites, the combination of query and page dimensions over many days can exceed the limits, and some long-tail rows will be missing.

Good API habits: request one day at a time for detailed data, include the date dimension, re-request the last few days because they are revised, and store results so you do not need to re-pull history.

Bulk data export to BigQuery

Search Console can export performance data daily to a Google Cloud BigQuery dataset you own. It is the most complete source available: no 1,000-row cap, no daily row limit for the export itself, and data kept for as long as you keep it. Anonymised queries are included as rows flagged as anonymised, so totals add up, even though the query text is withheld.

Considerations before setting it up:

• It starts from the day you enable it; there is no backfill. Start early if you expect to need it.
• It needs a Google Cloud project with billing enabled. Storage and query costs are usually modest for small and mid-sized sites, but large sites querying carelessly can generate bills.
• You need someone who can write SQL, or a reporting tool connected to BigQuery.

For a small business site, the interface and occasional exports are often enough. For agencies managing many sites and for large sites, bulk export pays for itself in completeness.

Aggregation: property versus page

Search Console counts some numbers differently depending on the grouping. When grouped by property (the chart totals), a search where two of your pages appeared counts as one impression at the position of the higher page. When grouped by page, each page gets its own impression. That is why page-level impressions summed over all pages exceed the property total. Neither is wrong; they answer different questions. The Performance report guide and the average position guide explain the consequences for impressions and positions.

The data delay

Search Console also offers a view of the most recent 24 hours for quick checks after a launch or a fix, but treat it as provisional. Performance data for complete days usually lags around two days, and recent days can be revised upward as processing completes. Short comparisons that end today will often show a false drop on the last day or two. End comparison windows a few days back for anything you will act on.

Other differences worth knowing

• Search types are separate. Web, image, video and news are reported separately; the default view is web only. Image search traffic, for example, does not appear unless you switch the search type.
• Discover and Google News have their own reports and do not appear in the Performance report for search.
• Property scope matters. A URL-prefix property for https://www.example.com/ excludes traffic to example.com without www, to other subdomains and to http://. A Domain property covers them all. If numbers look low, check which property you are looking at; see properties.
• Country is the searcher's location, not the language of the page or the version of Google used.
• Clicks are not sessions. Analytics counts sessions with its own rules and misses visitors who block scripts or decline consent, so the two will never match exactly.

Choosing the right source

Need	Best source
Quick look at trends and top queries	Interface
Full page list for a mid-size site	Interface with filters, or API
Daily query-level data stored over years	API with your own storage, or bulk export
Complete data for a large site, including totals that add up	Bulk export
Reporting for many client sites	API or bulk export feeding a reporting tool