Google Search Console API: What It Gives You That the Dashboard Doesn't

The Google Search Console API is a free way to pull the same performance and indexing data you see in Search Console into a spreadsheet, a script, or another tool. It doesn't contain secret metrics. What it changes is volume and repeatability: one request can return up to 25,000 rows, Google exposes up to 50,000 rows of data per day per search type, and you can run the identical query every morning without clicking through a single filter.

Whether that matters for your blog depends on what you're trying to do with the data. This guide covers what the API actually exposes, the limits Google documents, and the point where calling it yourself stops being worth the effort.

What the Search Console API Actually Includes

The API is smaller than most people expect. Google's reference lists four resources:

| Resource | What you can do with it | | --- | --- | | Search Analytics | Query clicks, impressions, CTR, and position with your own filters and groupings | | URL Inspection | Read the index status of a specific URL | | Sitemaps | List, get, submit, and delete sitemaps | | Sites | List, get, add, and remove Search Console properties |

That's the whole surface. There is no method for requesting indexing, and nothing that returns the full Page Indexing report as a table. If you want to know why a batch of URLs is excluded, you inspect them one at a time through URL Inspection.

Google's pricing page puts the cost in one line: all use of the API is free of charge, but subject to usage limits. So the real constraint is quota, not budget.

What Do You Get From the API That the Interface Doesn't Give You?

Three things, in practice.

More rows per pull. A Search Analytics request accepts a rowLimit between 1 and 25,000 (the default is 1,000) and a zero-based startRow. To go past the first page you re-run the same query and increase startRow by 25,000 until a response comes back with zero rows. For a small blog, a few of those pages can cover every page-and-query combination worth looking at.

Dimensions combined the way you want. You can group by query, page, country, device, searchAppearance, date, and hour in a single request. Grouping by page and query together is what makes it possible to build a real list of queries sitting on page 2 for each post, instead of clicking into posts one by one.

Control over data freshness and search type. The dataState parameter defaults to final, which returns only finalized data. Setting it to all includes fresh data, and hourly_all adds an hourly breakdown. The type parameter defaults to web, with discover, googleNews, news, image, and video as the other options. If your numbers look behind, check which dataState you asked for before assuming something is broken; the usual causes are covered in why Search Console data stops updating.

A minimal request looks like this:

POST https://www.googleapis.com/webmasters/v3/sites/sc-domain:example.com/searchAnalytics/query

{
  "startDate": "2026-09-01",
  "endDate": "2026-09-28",
  "dimensions": ["page", "query"],
  "rowLimit": 25000,
  "startRow": 0
}

Note the property format. A Domain property is written as sc-domain:example.com, while a URL-prefix property is the full URL with a trailing slash. Using the wrong form is an easy way for a first request to fail to find the site.

The Limits Google Documents

The API is generous, but it is not a full export of everything Google knows about your site.

It returns top rows, not all rows. Google's reference states that the API "does not guarantee to return all data rows but rather top ones." Separately, the guide on retrieving all your data says the API exposes a maximum of 50K rows of data per day per search type, sorted by clicks. For a small blog you may never touch that ceiling. For a site with tens of thousands of URLs, the long tail gets cut off.

Heavy queries cost more quota. Search Analytics allows 1,200 queries per minute per site and per user, but there's also a load quota measured in 10-minute and 1-day chunks. Google's wording is direct: queries are expensive when you group or filter by page or query string, queries grouped or filtered by page and query are the most expensive, and load increases with the date range. A year of page-and-query data in one call is the worst case on all three counts. Pulling it a day or a week at a time is cheaper.

URL Inspection has a daily cap. The inspection quota is 2,000 queries per day and 600 per minute per site. That's plenty for checking this month's new posts and far too little for auditing a large archive daily.

URL Inspection reads the index, not the live page. The method documentation says only the status of the version in the Google index is available, and that you cannot test the indexability of a live URL. It tells you what Google has stored, which is exactly what you need when working out whether a page is discovered or crawled but not indexed, but it won't confirm that a fix you deployed an hour ago worked.

If you genuinely need everything, Google's separate bulk data export schedules a daily export of performance data to BigQuery. According to the help page it covers all performance data for the property except anonymized queries. That's a data-warehouse project, though, and overkill for most blogs.

How Do You Get Access?

Google's prerequisites are short. You need a Google Account with the appropriate Search Console permission on the property, a project created in the Google API Console with access to the API activated, and OAuth 2.0 credentials. Every Search Console API except the Testing Tools API requires OAuth2, so there is no simple key you can paste into a URL.

Two details save time:

1. Ask for the read-only scope. The documentation lists two scopes, webmasters and webmasters.readonly. Reporting only needs the second one. A script that can't delete a sitemap or remove a property is a script that can't do damage when it has a bug.
2. Start with a narrow query. One week, one dimension, the default row limit. Confirm the numbers match what Search Console shows for the same filter before you scale up the date range and add dimensions.

From there you have options that don't require writing much code. Spreadsheet add-ons, dashboard connectors, and the community servers described in our guide to the Google Search Console MCP all sit on top of this same API. An MCP server is simply the API with an AI assistant doing the query-writing for you.

Is the API Worth It for a Blogger?

It depends on which of three jobs you have.

A one-off investigation. You want to know which queries a specific post lost over the last three months. The API works, but so does the Performance report with a page filter and a date comparison. Setting up a Cloud project for a single question is rarely worth it.

A repeatable report. You want the same page-and-query pull every week to spot posts drifting down. This is where the API earns its keep, because the query is identical each time and the comparison is the valuable part. It's also where the hidden work shows up: the API returns the date range you ask for and nothing else, so storing each pull and working out what changed since the last one is your job.

Ongoing monitoring. You want to be told when a post drops, not to remember to check. The API gives you the raw numbers, but the scheduling, storage, comparison logic, and alerting are all yours to build and maintain. That's the gap Traffic Monitor fills: it connects to your Search Console with read-only access, pulls clicks, impressions, and CTR every day, and stores each day's numbers so a change shows up as a change. If the reason you were looking at the API is "I don't want to check Search Console by hand," a monitoring tool gets you there without a Cloud project.

One caution applies to all three. API numbers and Analytics numbers will still disagree, because they measure different things. Pulling the data programmatically doesn't change that, and the reasons the two never match are the same whichever way you fetch them.

The Short Version

The Search Console API is free, returns up to 25,000 rows per request with a ceiling of 50,000 rows of data per day per search type, and exposes four things: search analytics, URL inspection, sitemaps, and site management. It won't give you every row for a large site, it won't test a live URL, and it won't tell you what changed since the last time you asked.

Use it when you have a query worth running repeatedly and a plan for comparing the results. For a single question, the interface is faster. For "tell me when something changes," you want something that runs on a schedule and keeps history, whether you build that yourself on top of the API or use a tool that already has.