Google Search Console API: the Google URL Inspection API, GSC API quotas and limits

The 2,000 per day URL Inspection quota is the real constraint

Google publishes a per-site quota of 2,000 queries per day and 600 per minute for URL Inspection. The per-project ceiling is 10,000,000 QPD, which sounds generous until you notice the limit that binds is the per-site one, and properties are what you own.

Do the arithmetic against a real catalog. A 5,000-page site can be inspected end to end in under three days. A 40,000-page ecommerce site takes twenty days for a single complete pass, by which point the first URLs you checked are three weeks stale. A 200,000-page marketplace cannot be inspected comprehensively at all, not once a quarter, not once a year.

There is no form to request more. The quota is not listed as adjustable, and unlike the Indexing API there is no documented process for asking. This is the point at which most teams stop trying to inspect everything and start sampling: inspect the pages that matter commercially, inspect anything that changed, inspect a rotating slice of the long tail, and accept that a full picture is not available through this endpoint. That sampling strategy is exactly what a monitoring tool automates, and it is why we exist alongside the API rather than instead of it.

Why the Search Console API cannot submit URLs for indexing

This is the question that brings most developers to the documentation, so it deserves a direct answer: there is no method for it. Not a restricted one, not a quota-limited one. The resource list contains Search Analytics, Sitemaps, Sites and URL Inspection, and none of them accept a URL to be indexed.

The Request Indexing button that exists in the Search Console web interface is a UI-only feature. It is rate limited in practice to roughly ten to twelve URLs per day per property, and Google has never exposed it programmatically. Scripting the interface to click it is a terms-of-service problem and a fragile one, and the automation tools that claim to do it at scale are usually doing something else entirely.

The Indexing API is a genuinely separate product with its own scope. Google restricts it to pages carrying JobPosting or BroadcastEvent structured data, with a default quota of 200 URL notifications per day per project. Publishers outside those two categories are not the intended audience, and Google is explicit about that.

What is left is the honest set: submit sitemaps (which the Sitemaps API does support), keep your internal linking sound so discovery works, use IndexNow for the engines that accept it, and use the Indexing API where your content genuinely qualifies. None of those force a page into the index. Anyone selling you an API that does is selling you something Google does not offer.

Authentication: OAuth versus a service account

The API uses standard Google OAuth 2.0, which means your script needs credentials tied to a Google account that has access to the property. For anything running on a schedule, a service account is the right choice: create one in a Google Cloud project, enable the Search Console API on that project, take the service account email address, and then add that email as a user on the property inside Search Console.

That last step is the one that trips people up. Creating the service account and enabling the API grants nothing by itself. Search Console permissions are per property and are granted inside Search Console, not inside Cloud. Until you add the service account email under Settings then Users and permissions, every call returns a permission error that looks like a credentials problem and is not.

Full permission is required for the URL Inspection endpoint, while restricted users can read Search Analytics. Domain properties and URL-prefix properties are separate entities to the API, and a URL you inspect has to belong to the property you name in the request. If you have both a domain property and a prefix property for the same site, they carry separate quotas.

• Create a Google Cloud project and enable the Search Console API on it
• Create a service account and download its JSON key
• In Search Console, add the service account email under Users and permissions
• Grant Full permission if you need URL Inspection, Restricted is enough for Search Analytics
• Use the property URL exactly as Search Console lists it, including the sc-domain: prefix for domain properties

What the API costs, and what people mean when they ask

The Search Console API is free. There is no billing tier, no paid quota, no per-call charge, and enabling it in a Google Cloud project does not put a card on file. When people search for Search Console API pricing what they usually want to know is whether the quotas can be bought up, and the answer is no for URL Inspection.

The costs that do show up are engineering costs. A script that pulls Search Analytics into a spreadsheet is an afternoon. A system that inspects a large catalog on a rotating schedule, stores history so you can see what changed, handles token refresh and quota backoff, notices when a URL drops out of the index, and then does something useful about it is a maintained internal product. Plenty of teams build it. Plenty of teams build it, use it for four months, and then nobody owns it after the person who wrote it changes jobs.

Common failure modes in a first Search Console API integration

Most of the pain in this API is not in the API. It is in the four or five specific mismatches that produce confusing errors.

• Only 1,000 rows come back: rowLimit defaults to 1,000. Set it to 25,000 and page with startRow.
• Permission denied on every call: the service account email was never added as a user inside Search Console.
• URL Inspection returns permission denied specifically: the account has Restricted rather than Full permission.
• Property not found: a domain property must be addressed as sc-domain:example.com, not https://example.com/.
• Numbers do not match the interface: the default dataState is final, while the interface may be showing fresh data.
• Quota exhausted mid-afternoon: URL Inspection is 2,000 per day per property and resets on Google schedule, not yours.

When the API is the right answer and when it is not

Build on the API directly when you want performance data. Search Analytics is generous, the quota is effectively unlimited for normal use at 1,200 QPM per site, and pulling your own query and page data into a warehouse or a spreadsheet is a well-trodden path with good libraries in Python, PHP and Node.

Think harder before building on URL Inspection. The endpoint is fine; the quota makes comprehensive coverage impossible above a few thousand URLs, and the endpoint reads only, so whatever you build stops at the moment it finds a problem. You get a list of pages that are not indexed and no mechanism to act on it.

That gap is the whole reason this tool exists. We read the same index status, on a schedule sized around the same published quotas, keep the history so you can see what changed rather than only what is true today, and then push the pages that qualify back out through the channels that genuinely accept submissions. We cannot force Google to index anything, and we say so on every page. What we can do is make sure you know what is in, what fell out, and why, without you maintaining an API client to find out.