Google Indexing API Quota: 200 a Day, Explained

The Google Indexing API quota is 200 publish requests per day per Google Cloud project, counting URL_UPDATED and URL_DELETED together, with 180 getMetadata requests per minute and 380 requests of any kind per minute. The daily counter resets at midnight Pacific Time. Batches of up to 100 calls save HTTP round trips, not quota. Google calls the 200 a default for onboarding and testing, links a form for asking more, and names the use of several accounts to get around it as abuse.

The numbers

Quota	Default	Scope
Publish requests (URL_UPDATED plus URL_DELETED)	200 per day	Per Cloud project
getMetadata requests	180 per minute	Per Cloud project
All requests combined	380 per minute	Per Cloud project
Calls per batch request	100	Per HTTP request
Price	Free

The unit is the Cloud project, not the service account and not the website. Three service accounts in one project share one pool of 200. One service account that is an Owner of five Search Console properties also has 200 in total, not 200 per property.

What counts

Every publish call is one unit, whichever type it carries. Telling Google a job page went live costs one; telling it the same page expired costs another. A site that posts 60 jobs a day and expires 60 needs 120 a day before any edits.

Batching does not change the count. One multipart request to https://indexing.googleapis.com/batch can carry 100 publish calls, and Google counts 100. The gain is a single HTTP round trip and a single token; see Google Indexing API code examples for batch code in Python, PHP and Node.js.

Count conservatively in your own logs: treat every publish call you send as spent, whatever came back. Then a day's log tells you how much is left without guessing about which errors were charged.

getMetadata calls do not touch the daily publish quota. They are limited per minute (180), and they only ever tell you what you already sent, so a log makes most of them unnecessary.

When it resets

Midnight Pacific Time. Google writes it that way rather than as UTC, so convert: 07:00 UTC while Pacific Daylight Time applies (March to November), 08:00 UTC in winter. A publisher in Europe gets a fresh 200 early in the morning; a publisher in Australia gets it in the evening.

If you queue URLs and drain the queue on a schedule, run the drain job shortly after the reset so that the quota goes to the oldest waiting pages, and spread the remainder through the day for pages that appear later. The per-minute ceiling of 380 means a full day's 200 can go out in one minute if you want, but there is no reason to.

Seeing usage in the Cloud Console

Open the Google Cloud Console, pick the project that owns the service account, then APIs & Services > Enabled APIs & services > Web Search Indexing API and the Quotas & System Limits tab. Each quota appears with its current usage and a chart over time, so you can see at what hour the 200 ran out. The same list is under IAM & Admin > Quotas filtered by the Indexing API service.

If a quota row is missing, the API is not enabled in the project you are looking at, which also explains a 403 with the message that the project is not configured to access the API.

What a 429 looks like and what to do

{
  "error": {
    "code": 429,
    "message": "Quota exceeded for quota metric '...' and limit '... per day' of service 'indexing.googleapis.com' ...",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Read the message, because the same status code covers two different situations, and the limit named in it (per day or per minute) tells you which:

• A per-minute limit. Back off for a few seconds and retry. Exponential backoff with a cap of a minute is enough.
• The daily limit. Stop. Retrying every few seconds until midnight Pacific gains nothing and makes your logs useless. Queue the remaining URLs for tomorrow.

Code that distinguishes the two by reading the message is in the examples article above. A 429 has no effect on the site's standing in search, and it is not a sign of abuse detection; it is a counter.

Asking for more

Google's quota page links to a request form. The page says the form is for sites with JobPosting or BroadcastEvent pages, that you need your Cloud project details, that quota may be increased or decreased based on document quality, and that changes can take up to 24 hours to take effect.

That framing matters. The API is officially for job postings and livestreams, and the form asks you to show that. Reports from site owners outside those two groups describe approvals as rare. If you run a job board and 200 is short, apply with real numbers: jobs posted per day, jobs expired per day, and the Search Console property. If you run a blog, the honest expectation is to stay at 200 and use the fully supported routes for the rest: sitemaps with accurate <lastmod>, internal links and the Request indexing button, whose own small allowance is described in Request indexing limits.

Why several projects for one site is a bad idea

The arithmetic is tempting: ten projects, ten service accounts, all Owners of the same property, 2,000 requests a day. Google's documentation addresses it directly. Attempts to abuse the API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked, and all submissions go through spam detection. The outcome you risk is not a 429 but losing the API for the site, and being marked as a source of spam submissions.

There is a practical argument too. If a site needs more than 200 crawl requests a day for pages that are not job ads or livestreams, the pages are not being discovered through links and sitemaps, and that is the thing to fix. The API does not change the indexing decision; it only brings the crawl forward. A thousand notifications a day for pages Google then declines is a thousand wasted calls, however many projects they came from.

How to spend 200 well

Most sites that feel the quota is tight are spending it on URLs that could never benefit.

Only new and changed pages. A page that is already indexed and unchanged gains nothing from a notification. Any page with an impression in the Performance report is indexed; skip it.

Never 404s, redirects, noindex or canonicalised pages. A notification for a URL that redirects gets the redirect crawled. A notification for a noindex page gets Google to read the noindex. A notification for a page whose canonical points elsewhere is a request to crawl a page Google will fold into another one. Each of these is a unit spent for nothing, and sitemaps full of them are common. Run a list through the redirect checker and single URLs through the indexability checker before they reach the API. This pre-check is what TurboIndex's crawler, TurboIndexBot, does for every URL before submission: it fetches the page, reads the status code, the redirect chain, meta robots, X-Robots-Tag and the canonical, and a page that fails is never sent, so the 200 go only to pages that can be indexed (details on the bot page).

Changed means changed. Do not re-notify on every save. Tie the call to a real content change, or diff the sitemap's <lastmod> values and send only the URLs whose date moved. How to keep that date honest is in lastmod sitemap best practices.

Prioritise. When the backlog exceeds the quota, send the pages that matter commercially first and let the sitemap carry the long tail. The indexing time calculator shows how many days a backlog takes at 200 a day, which is often the moment people realise the API was never going to carry a 30,000-page site by itself.

Deletions count, so use them properly. URL_DELETED is for pages that now return 404 or 410 or carry noindex. Sending it for a live page to "refresh" it is a wasted unit and a wrong signal.

A worked budget

A job site publishes 40 listings a day, edits about 20 and expires 40. That is 100 units on a normal day, leaving 100 for a backlog or a bad day. Within the quota, no form needed.

A content site publishes 15 articles a day and updates 10. That is 25 units. The quota is not the problem; the policy is, since none of those pages carry job or broadcast markup, and the honest approach is to treat those 25 calls as unsupported extras on top of a sitemap and internal links that already get the pages crawled.

A 30,000-page catalogue with 5,000 unindexed pages would need 25 days of the whole quota to notify each once, and the notifications would not change the reason those 5,000 pages were declined. That site needs the content and linking work described in the Google Indexing API guide under alternatives, not more quota.

What to do next

1. Open the Quotas tab for your project and check today's usage against 200.
2. Make your code read the 429 message and stop for the day on the daily limit.
3. Add a pre-check so that redirects, 404s, noindex and canonicalised URLs never reach the API.
4. Notify only on real change, and log every call with its response.
5. If you run job or livestream pages and 200 is short, fill in Google's form with real daily figures. Otherwise, put the effort into sitemaps and internal links.