Google's URL Inspection API allows 2,000 inspections per property per day and 600 per minute, and those numbers cannot be raised (developers.google.com, checked August 2026). Everything awkward about auditing indexing at scale follows from that single line: a 10,000-URL site takes five days for one complete pass, and no amount of budget, tooling or engineering changes it.
We built our Bulk Google Index Checker against this ceiling, so the design decisions here come from hitting it rather than reading about it. The one thing worth internalising before you plan around the quota: it is charged per property, not per Google account and not per Cloud project, and that distinction turns out to be the only real lever you have.
What are the actual limits?
Two per-property caps and two much larger per-project ones. The per-property limits are what you will hit; the per-project limits exist to stop one developer's tool overwhelming the service.
- Per property, per day
- 2,000 inspections
- Per property, per minute
- 600 inspections
- Per Cloud project, per day
- 10,000,000
- Per Cloud project, per minute
- 15,000
- Scope required
- webmasters.readonly (read only)
- Access requirement
- Only properties verified by the signed-in account
The gap between the two tiers is the useful part. Because the daily cap belongs to the property rather than to your project, a tool serving a thousand users is not dividing 2,000 checks between them — each user brings their own allowance. Multi-tenant index checkers are practical for exactly this reason.
The per-minute limit of 600 rarely bites in practice. Ten parallel requests finishing in a second each puts you at roughly 600 a minute at the absolute ceiling, and most implementations run well below that because each inspection takes noticeably longer than a second.
How long does a full site pass take?
Divide your URL count by 2,000 and round up. That is the whole calculation, and it is worth doing before you promise anyone a complete audit. Get the URL count itself from your sitemap rather than from an indexed total, since Google reports three different indexed counts and documents two of them as incomplete.
A site above roughly 50,000 URLs is where this stops being a scheduling inconvenience and becomes a strategy problem. Twenty-five days for one pass means that by the time you finish, the pages you checked first are a month stale. At that scale you stop trying to see everything and start sampling deliberately: newest pages, highest-value templates, sections you have just changed.
That constraint is why our checker orders by publication date rather than by sitemap order. On a large site the useful question is almost never "what is the status of all 50,000 pages" — it is "did the 40 things we shipped this month get indexed", and that fits inside a single day's quota with room to spare.
Can you get more than 2,000 a day?
There is one legitimate way, and it is a quirk of how Search Console models sites rather than a loophole. The quota attaches to a property, and a single website can be verified as two different properties: a domain property (sc-domain:example.com) and a URL-prefix property (https://example.com/). Each carries its own 2,000 per day.
Verify both and you have 4,000 inspections a day for the same site, at the cost of splitting your checking across two property identifiers. It is not a trick — Google treats them as genuinely distinct properties with different scopes, and the domain property covers subdomains while the URL-prefix one does not.
What does not work is asking. Unlike some Google APIs, the URL Inspection quota is not documented as adjustable and requests to raise it are not granted. Nor does adding service accounts help, because the limit follows the property being inspected rather than the credential doing the inspecting. Any tool promising unlimited checks against Google's real index is either using both property types, or is not reading Google's index at all — a distinction worth understanding before trusting one, and covered in how to check if a page is indexed by Google.
What does a 429 actually mean?
That you have spent the property's daily allowance, and the correct response is to stop rather than retry. The API returns HTTP 429 once the 2,000 are gone, and it does not reset on a rolling window you can wait out within the same day — it resets on Google's daily clock.
The implementation detail that matters: do not mark those URLs as checked. When we hit a 429 mid-run, the job leaves the remaining URLs with no recorded check time, which keeps them at the front of the queue for tomorrow. Recording them as attempted would quietly skip them for a full cycle, and you would end up with a site that never finishes a pass and no obvious reason why.
Retrying immediately is worse than useless — it consumes rate-limit headroom for nothing and can escalate. Treat 429 as a hard stop for that property until the next day.
Is the API worth using over the Page Indexing report?
For per-URL answers, yes; for spotting patterns, the report is better and free of quota concerns. They answer different questions, and the failure mode is using one for the other's job.
The report aggregates by status and lags by days, and Google documents its example URL lists as "limited to 1,000 items" that are not guaranteed to show every URL in a status even when there are fewer than a thousand. So it will tell you that 340 pages are "Crawled, currently not indexed", and it will show you some of them — but if you need to know whether one specific page is in that bucket, or you need the full list to work through, the report cannot give it to you.
The API gives a live, per-URL verdict with no sampling. That precision is what the quota buys, and it is the reason a bulk checker exists at all. If the status you keep seeing is the crawled-but-declined one, what "Crawled, currently not indexed" actually means explains why re-checking it daily is a poor use of your 2,000.
What about the Indexing API instead?
Different API, different job, and not a substitute. The Indexing API pushes URLs to Google for crawling; the URL Inspection API reads status back. One writes, one reads, and the write side comes with much tighter constraints: a default 200 URLs per day per Cloud project, and documentation limiting it to job postings and livestream pages.
The 200-per-day figure catches people out because it is per project, not per property — the opposite of the read side. Build a tool on it and every user shares the same 200, which is why serious submission tooling ends up needing separate Cloud projects per customer or abandoning the approach. We laid out what each submission route can legitimately reach in instant indexing: IndexNow, Google's Indexing API, and what actually works.
FAQ
Can I request a higher URL Inspection API quota from Google?
No. Unlike some Google APIs where quota increases can be requested through the Cloud console, the URL Inspection limit of 2,000 per property per day is not documented as adjustable, and requests to raise it are not granted. Adding more service accounts or Cloud projects does not help either, because the cap follows the Search Console property being inspected rather than the credential making the request. The only legitimate way to get more headroom for one site is verifying it as both a domain property and a URL-prefix property, which gives each its own allowance.
Does the quota reset at midnight in my timezone?
It resets on Google's own daily clock, not yours, and Google does not document the exact reset moment. In practice this means you should treat a 429 as a stop for the rest of your day rather than trying to time a retry, and design any recurring job to pick up where it left off rather than assuming a specific reset hour. Tracking which URLs you actually completed matters more than predicting the reset.
Do failed inspections count against the quota?
Requests that reach Google and return a result count, including ones that come back with an error verdict for the URL itself. Requests rejected with a 429 because the quota is already spent do not consume further allowance, since there is none left to consume. The practical implication is that malformed URLs and pages returning errors still cost you quota, so validating and de-duplicating your URL list before sending it is worth doing on large sites.
Is the URL Inspection API free?
Yes. There is no charge for calls to the URL Inspection API, and the Search Console API does not have a billing component. The quota is a capacity limit rather than a pricing tier, which is why it cannot be increased by paying. The only cost is on your side: the infrastructure to make the requests and store the results.