How to Reconcile Search Console UI and API Limits

If clicks or queries in Google Search Console’s Performance report do not match an API export, the two sources may list and filter the data differently. The Performance report is the Search Console screen that shows search clicks, impressions, and related details. Its table has a 1,000-row limit, while its chart totals can include activity that the table does not list.

Software can use the Search Analytics API to request Search Console performance data. The API returns more rows than the report table, but it still has limits and may omit detailed rows. Google’s BigQuery export, a way to store and analyze data in Google Cloud, covers more available performance data. It hides anonymized query text, while retaining flagged rows for those queries. A property is the Search Console site or domain whose data you request. Knowing which limit applies helps you tell a normal difference from a reporting or export problem.

What each access method returns

Google’s Search Console data documentation distinguishes report totals from table rows. The Search Analytics API reference documents the request-level limits, and Google’s BigQuery table reference describes the exported fields, including is_anonymized_query. That flag identifies anonymized rows whose query text is hidden.

Why chart totals exceed listed query rows

The chart can show clicks and impressions from more than the 1,000 rows listed in the Performance report table. Google also withholds some query strings for privacy. These anonymized queries contribute to chart totals unless a query filter is applied, but their names do not appear in the table.

As a result, adding the clicks from exported query rows does not necessarily reproduce the chart’s click total. The export can still report actual totals even when it lists only a subset of rows. Google describes this distinction in its explanation of performance-data filtering and limits.

What API pagination does and does not do

The API’s rowLimit parameter controls how many rows one response can contain. Its default is 1,000, and its maximum is 25,000. The startRow parameter sets the position where the next response begins, counting the first row as position zero. A client uses it to request one page after another.

Google documents a ceiling of 50,000 rows per day, per property, per search type. Two responses of 25,000 rows each reach the published ceiling. Google does not promise that every property, date, or combination of fields, such as query and page, will return 50,000 rows. Google says the API returns top rows and does not guarantee every available row.

Detailed requests can also lose data. Grouping or filtering by query or page gives more specific information. Google recommends leaving out these fields when complete counts matter more than detail. Compare an aggregate request with a detailed request before assuming the API has failed.

API row limits are separate from API request quotas. A client can hit a request quota while retrieving rows. It can also finish its requests without receiving every detailed row. Google’s published usage limits list separate short-term and long-term query-load limits, with rates for each site, user, and project. The same guidance says grouping or filtering by page or query consumes more query load. Longer date ranges do too.

How to compare the numbers

Use the same property, search type, date range, filters, and dimensions when comparing the UI with an API response. Use the same Search Console site or domain. If one report groups data by query and another by page, their row counts and totals describe different results.

Then check the date and data state. Search Console uses Pacific Time for API dates. Recent data normally takes two to three days to become available, so requests for newer data can return incomplete values that later change. Google’s data guidance covers these timing and time-zone differences.

To compare the results, first request totals without grouping by page or query. Then request detailed rows and compare their sum with the totals. If the totals align but the detailed rows do not, investigate row limits and privacy filtering. If the totals themselves differ, recheck the dates, filters, aggregation, and whether one report includes fresh data.

When retrieving API pages, set rowLimit to 25,000 and advance startRow to request the next page. Stop treating pagination as a path to unlimited data once you reach the documented daily ceiling. Google’s API export guidance explains how to retrieve performance data, but paging does not remove the API’s internal row-selection limits.

When BigQuery is the better choice

Use BigQuery to analyze large amounts of Search Console performance data over time. The bulk export avoids the API’s daily row limit. Its tables can include anonymized query rows marked with is_anonymized_query, but the query text remains hidden. Include those rows when calculating totals; filter them out only when you need identifiable query strings.

The export starts on the setup date and includes no earlier history. Google says the first export can take up to 48 hours after successful setup. BigQuery also requires a Google Cloud project with billing and BigQuery enabled, and charges can apply when usage exceeds free amounts. For data from before setup, use the API or Search Console reports. Google’s export setup instructions describe these requirements.

BigQuery does not guarantee a gap-free historical record. Google’s Search Console anomaly log records export and reporting issues, including dates when some properties’ bulk-export data was missing and would not be recovered. Check that log when a date is absent from an export.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com