The Google Search Console API lets you pull performance data, clicks, impressions, CTR and position, by query, page, country, device and date, straight into your own scripts, spreadsheets or warehouse. It is the standard route past the row limits of the web interface, and the basis of most serious SEO reporting.
It is also widely misunderstood. People expect the API to return every query that ever produced an impression. It does not, and Google says so in its own documentation. The useful work is knowing where the ceilings are and designing your extraction around them.
The Google Search Console API limits that matter
Google’s guide to getting all your data from the Search Analytics method sets out the row limits. Its sample code declares “int maxRows = 25000; // Current max response size”, so one request returns at most 25,000 rows. Above that, a daily ceiling applies: “the Search Analytics method exposes a maximum of 50K rows of data per day per search type (web, image, and so on–sorted by clicks).”
Separately, Google’s usage limits page sets request quotas. These are the figures at the time of writing (October 2026):
| Limit | Scope | Value |
|---|---|---|
| Rows per request | Search Analytics | 25,000 |
| Rows exposed per day | Per search type, sorted by clicks | 50K |
| Search Analytics queries | Per site | 1,200 per minute |
| Search Analytics queries | Per user | 1,200 per minute |
| Search Analytics queries | Per project | 30,000,000 per day; 40,000 per minute |
| URL Inspection API | Per site | 2,000 per day; 600 per minute |
For most sites the request quotas are generous and the row limits are what bite. The URL Inspection quota is the exception: 2,000 inspections a day per site is plenty for a blog and nowhere near enough to check every URL on a large catalogue daily.
A Google Search Console API example request
A Search Analytics query is a small JSON body sent to the site’s query endpoint. The five fields below are enough to start: a date range, the dimensions to group by, how many rows to return and where to start.
Note the single day. Google recommends querying one day at a time, and there are two good reasons. The 50K daily ceiling applies per day, so a month queried as one range compresses thirty days of long tail into one capped result. And daily rows are easier to store, deduplicate and re-run when something fails.
The same ceiling applies per search type, so web, image and other search types are separate result sets. If image or video traffic matters to your site, query each type on its own rather than assuming the default covers it. Each one is a separate pass through the paging loop, with its own 50K allowance.
Choose dimensions with the end report in mind. Every dimension you add multiplies the number of rows: query alone is one list, query and page is every combination of the two, and adding country and device multiplies it again. If a report only ever needs pages, ask for pages. Smaller, purpose-built queries stay under the ceilings and lose less to the data dropping described below.
Paging through results with startRow
If a query has more than 25,000 rows, you page. Google’s instruction is direct: “Page through results by re-running the same query, increasing the startRow value by 25,000 in the request until you reach the last page (a response with 0 rows).”
In practice the loop is simple. Send the request with startRow at 0. Store the rows. Add 25,000 to startRow and send it again. Stop when a response comes back empty. Keep every other field identical between pages, because changing the dimensions or dates midway gives you rows that do not belong to the same result set.
Two habits save trouble. Write each page to storage as it arrives rather than holding the whole day in memory, and log the date and startRow of every request so a failed run can resume rather than restart. With the per-site quota at 1,200 queries a minute, a polite pause between requests costs you very little.
Why you still will not get every row
This is the limitation that surprises people. Even with perfect paging, the API does not return the complete picture. Google states: “When you group by page and/or query, our system may drop some data in order to be able to calculate results in a reasonable time using a reasonable amount of computing resources.”
So the more detailed your grouping, the more likely the totals will fall short of what you see when you query by date alone. Sum the clicks from a query-and-page export and compare them with a date-only query for the same day, and expect a gap. That gap is not a bug in your script. It is the long tail that the API chose not to calculate, combined with whatever the 50K daily ceiling cut off.
The workaround is to keep two kinds of export. Use date-only or date-and-device queries for trustworthy totals, and query-and-page exports for analysis of which terms and URLs drive traffic. Report totals from the first and patterns from the second, and never mix them in one chart. The same logic explains why Search Console and analytics numbers rarely agree, which we cover in Search Console vs Google Analytics.
BigQuery export, cost and when to use which
Google also offers a bulk data export from Search Console to BigQuery. It is a different mechanism from the API: rather than requesting pages of rows, you configure an export and the data lands in your own BigQuery project. For large sites that need query-level history, it is worth evaluating alongside the API, though its own limits and costs sit outside the scope of this guide.
On cost, Google doesn’t charge for Search Console. Whether anything else in your setup costs money, such as the warehouse you store results in or the cloud functions that run your scripts, depends on what you build around it.
A sensible default for most teams looks like this. Run a daily job that pulls the previous few days, one day per request, paging with startRow until an empty response. Store raw rows with the date and the dimensions used. Then build reports on top of the stored rows, not on live API calls.
Once you have clean daily rows, the analysis gets interesting. Comparing click-through rate against position for your own queries, as in our guide to CTR by position, is far more reliable on stored API data than on whatever the interface happens to show. If you are new to the tool itself, start with how to use Google Search Console before you automate anything.
Frequently asked questions
What are the Google Search Console API limits?
25,000 rows per request, a maximum of 50K rows per day per search type, and query quotas such as 1,200 Search Analytics queries per minute per site.
Is the Google Search Console API free?
Google doesn’t charge for Search Console. Any cost comes from the infrastructure you use to run requests and store the results.
How do I get more than 25,000 rows?
Re-run the same query, increasing startRow by 25,000 each time, until a response returns 0 rows.
Why don’t API totals match the date-only totals?
Grouping by page or query can cause Google to drop some data, and the 50K daily row ceiling cuts off the long tail.
The takeaway Query one day at a time, page with startRow in steps of 25,000, and store the rows. Take totals from date-level queries and patterns from detailed ones, because the detailed exports will never be complete.
