Google Search Console API Guide: Limits, Quotas and Exports

What is the Google Search Console API?

The Google Search Console API is Google’s free REST API for reading Search Console data in code. It has four parts: Search Analytics (clicks, impressions, CTR and position by query, page, country, device, date and search appearance), Sitemaps, Sites and URL Inspection. It returns up to 25,000 rows per request and up to 50,000 rows of Performance data per day, per search type, per property. Reports such as Page indexing, Links and Core Web Vitals are not in it at all.

Every limit below comes from Google’s documentation, checked on 30 October 2026; follow the links before you build on a number. We make GSC MCP Server, a hosted Search Console MCP server that reads Search Console through this API, so we mention it where it helps and say where a plain script or BigQuery is the better tool.

What the Search Console API covers

The API reference lists four resources. Search Analytics, Sitemaps and Sites live under https://www.googleapis.com/webmasters/v3; URL Inspection lives under https://searchconsole.googleapis.com/v1.

Two details trip people up:

• Sitemaps don’t report indexed counts. The indexed field in a sitemap’s contents is marked deprecated (“do not use”) and Google stopped filling it in 2019. You get the number of URLs submitted, not how many are indexed.
• URL Inspection reads the indexed version only. Google’s method reference says you can’t test a live URL through the API, and there is no request-indexing method. Our guide to URL Inspection from Cursor and VS Code covers how to use the results.

Recent changes worth knowing

• April 2025: hourly data arrived through a new hour dimension and the hourly_all data state, covering up to 10 days.
• Later in 2025: responses gained a metadata object that marks the first incomplete date or hour.
• August 2026: the FAQ search appearance was deprecated in the API, after FAQ rich results stopped appearing in Google Search on 7 May 2026.

What the API doesn’t include

Google’s overview says the API offers “much of the functionality” of Search Console. The gaps matter, because many people assume every report is available.

If indexing is your problem, the interface remains the place to start; our walkthrough of “Crawled – currently not indexed” shows how to combine the report with URL Inspection. For AI features, see what Search Console’s generative AI report shows and why it is export-only. For brand splits, the branded vs non-branded guide builds the regex.

Row limits: 1,000, 25,000 and 50,000

Three different numbers get mixed up in most guides. They apply at different layers.

Pagination with startRow

To get past 25,000 rows, repeat the identical request and raise startRow (zero-based) by your rowLimit: 0, then 25,000, then 50,000. Stop when a response returns fewer rows than you asked for; a startRow beyond the end returns a successful response with no rows. Rows come sorted by clicks, highest first (by date, oldest first, when you group by date), so change nothing but startRow between pages.

Google’s “getting all your data” guide recommends querying one day at a time, with startDate and endDate set to the same date, and paging through each day. That keeps every request cheap and lets each day reach its own 50,000-row ceiling. Even then, Google says the API returns the top rows and doesn’t guarantee all of them.

How to export more than 1,000 rows from Search Console

1. Slice the export. Filter the Performance report by folder, country or device and export each slice. Fine for a one-off job, tedious beyond that.
2. Use the Looker Studio connector or a Sheets add-on. Both call the API for you, so the 50,000-row daily cap still applies.
3. Call the API with pagination, in a script or a no-code connector.
4. Set up the bulk data export if you need every row from now on.

GSC MCP Server’s query_search_analytics returns at most 1,000 rows per call and gives you a nextStartRow to continue from. The cap is deliberate: 25,000 rows would swamp an AI assistant’s context window, so filter first and page only when you need to.

The regex syntax (RE2, no lookarounds) is covered in our Search Console regex cheat sheet.

Why API totals don’t match the Performance report

Sum the rows from a query-level API pull and you will almost always get less than the chart in Performance → Search results. Neither number is wrong. These are the usual reasons:

• Anonymised queries. Google’s performance data deep dive explains that queries not issued by more than a few dozen users over two to three months never appear as rows, but their clicks still count in unfiltered totals. Any query filter removes them, so “contains X” plus “doesn’t contain X” falls short of the total.
• Property vs page aggregation. When you group by query, country, device or date, two of your URLs in one result count as one impression. Group or filter by page and each URL counts separately. The aggregationType field controls this (auto, byPage or byProperty), and the response tells you which was used.
• Dropped rows. Grouping by page or query, and above all both together, can drop some data so results are calculated in reasonable time.
• Top rows only. Past the daily cap, the long tail is simply not exposed.
• Dates and data state. Dates are Pacific Time, not your time zone, and the default final state leaves out the last two or three days that the interface shows.
• Units. The API returns CTR as a fraction from 0 to 1, while the interface shows a percentage.

Historical impressions also need care. Google’s data anomalies page records a logging error that affected impressions, CTR and position (not clicks) from 13 May 2025 to 27 April 2026. The API serves the same data, so year-over-year impression comparisons across that window are unreliable. Our explainer on Search Console metrics goes deeper on how each metric is counted.

Freshness, dataState and 16 months of history

• Final data lags 2–3 days. That is Google’s typical figure for finalised data, and the API’s default.
• dataState: all adds fresh data that isn’t final yet, some of it less than a day old. When you group by date, the response’s metadata.first_incomplete_date marks where numbers may still change.
• hourly_all with the hour dimension returns hourly rows for up to 10 days, against 24 hours in the interface. GSC MCP Server doesn’t expose hourly data; our tools work at daily granularity.
• 16 months is the ceiling. The API can’t return anything older than the interface can. If you want longer history, archive the data yourself every month or start the bulk export.
• New properties take time. Google says a newly added site can take up to a week to show data.

Search Console API quotas and load limits

From Google’s usage limits page, checked on 30 October 2026. QPS, QPM and QPD mean queries per second, minute and day.

The load quota

Search Analytics also has a load quota, which measures the work a query costs Google rather than how many you send. Exceed it and you get a “quota exceeded” error.

• Short-term load is counted in 10-minute windows. Wait 15 minutes and spread your queries across the day.
• Long-term load is counted per day. If a single query in a 10-minute window still triggers the error, you have hit it, and you need to make queries cheaper.

Grouping or filtering by page or query is expensive, and both together is the most expensive. Longer date ranges cost more, and re-pulling the same data counts every time. Query one day at a time, drop the page dimension when you don’t need it, and cache what you have already fetched.

URL Inspection’s 2,000 a day

The inspection quota is per property, so 2,000 a day is enough to check new or changed URLs, not to crawl a large site. Prioritise pages that earn clicks or should.

Our server’s plans add their own monthly allowance on top of Google’s quotas: 30 tool calls on Free, 10,000 on Pro and 50,000 on Agency, with each call inside a multicall counted. See pricing.

Authentication: OAuth or a service account

Google’s authorisation guide is blunt: requests must use OAuth 2.0, and API keys alone won’t read your data. There are two scopes:

• https://www.googleapis.com/auth/webmasters.readonly for reading. Use this unless you must change something.
• https://www.googleapis.com/auth/webmasters for read and write, which you need to submit or delete sitemaps and add or remove properties.

OAuth for people, service accounts for jobs

OAuth with user consent suits tools that people sign in to. The user approves the scope once, you store a refresh token, and the API sees exactly the properties that person can see.

A service account suits scheduled jobs. Create it in Google Cloud, then add its email address as a user in Settings → Users and permissions → Add user on each property. Only owners can open that page, and a property allows up to 100 non-owner users. According to Google’s permissions help page, Restricted users get view rights on most data, while Full users can see everything and submit sitemaps. Google’s API docs centre on OAuth, so treat the service-account route as common practice rather than a documented recipe.

Your first Search Analytics API request

In words: enable the Google Search Console API in your Cloud project (APIs & Services → Library), create credentials, then send a POST to https://www.googleapis.com/webmasters/v3/sites/SITE_URL/searchAnalytics/query with your access token in the Authorization header and a JSON body. This body asks for the top queries and pages in the blog folder for September 2026:

The response holds a rows array. Each row has keys (dimension values in the order you asked for), clicks, impressions, ctr and position, plus a responseAggregationType for the whole response. Note that equals and notEquals are case-sensitive for page and query, while contains and notContains are not.

Search Console API with Python

1. Install google-api-python-client and google-auth-oauthlib.
2. For a local script, create an OAuth client of type Desktop app and run InstalledAppFlow with the read-only scope. For a server job, load a service account key with service_account.Credentials instead.
3. Build the client with build("searchconsole", "v1"), the service name Google’s Python quickstart uses.
4. Call searchanalytics().query(siteUrl=..., body=...) with the fields above, then .execute().
5. Loop over days, and within each day raise startRow by 25,000 until a response comes back short. Write rows to a database as you go so a quota error doesn’t lose the run.

Four ways to get Search Console data out

1. Export from the interface

Most reports have an Export button that downloads what is on screen, filters included, to Google Sheets, Excel or CSV. It stops at 1,000 rows, and cells shown as “~” or “-” export as zeros. It is also the only way to get data out of reports the API lacks, such as Page indexing and Links.

2. The API, directly or through a connector

Scripts, ETL tools, Google Sheets add-ons and Looker Studio’s Search Console connector all sit on the same API and the same daily row cap. The Looker Studio connector offers two tables: Site Impression (aggregated by property; web, image, video and news) and URL Impression (aggregated by page; also Discover and Google News). You need at least view permission on the property.

3. Bulk data export to BigQuery

The bulk export writes a daily copy of your Performance data into BigQuery, without the 50,000-row cap. The setup steps:

1. In a Google Cloud project with billing, enable the BigQuery API and BigQuery Storage API.
2. In IAM and Admin, grant search-console-data-export@system.gserviceaccount.com the BigQuery Job User and BigQuery Data Editor roles.
3. In Search Console, open Settings → Bulk data export, enter the project ID, keep or change the searchconsole dataset name, and choose a location carefully: it is hard to change later. You need owner permission on the property.

The first export arrives within 48 hours. You get three tables: searchdata_site_impression (by property), searchdata_url_impression (by URL, with true/false columns for each search appearance) and ExportLog. Anonymised queries are flagged by is_anonymized_query, with the query text left empty.

If an export fails, Search Console retries the next day and holds the missing data for about a week; after about a month of failures it stops. Some properties lost 28 February and 1 March 2026 for good, according to the anomalies page.

4. An MCP server for questions in plain English

An MCP server puts the API behind tools your AI assistant can call, so you ask “which blog posts lost clicks this month?” instead of writing the request. It is the right fit for ad hoc analysis, not for extracting every row. Our plain-English guide to Search Console MCP servers explains how they work, and the comparison of Search Console MCP servers covers hosted and open-source options.

GSC MCP Server uses the read-only scope: it can’t submit sitemaps, request indexing or change anything, and it can’t read reports the API lacks. It also reads Bing Webmaster Tools through Bing’s own API. Setup takes a few minutes in Claude, ChatGPT, Cursor or VS Code (see the connection guide).

Which method should you use?

Many teams combine three: the bulk export as the permanent archive, a Looker Studio report for stakeholders, and an assistant for the questions in between. All of them read the same underlying data, with the same anonymised queries and Pacific Time dates, so note which route each figure came from and compare like with like.

Frequently asked questions