The URL Inspection API's two thousand a day belongs to the property
The per-site limit is the one that binds: 2,000 calls a day and 600 a minute, counted against the property rather than against the key or the tool that asked.
Google's URL Inspection API allows 2,000 queries a day and 600 a minute per site, alongside a far larger per-project allowance of 10,000,000 a day and 15,000 a minute. The per-site figure is the one that binds in practice, and the word that matters in it is site: the allowance follows the Search Console property, not the API key, not the tool and not the person. Two applications inspecting the same property draw down one shared 2,000, and each will be told it has plenty right up to the moment neither does.
The URL Inspection API is bounded by two pairs of numbers, and Google enforces each of them with an HTTP 429. Per site there are 2,000 queries a day and 600 a minute. Per project — that is, per Developer Console key — there are 10,000,000 a day and 15,000 a minute. Anyone inspecting a handful of properties will hit the site limits and never come near the project ones, which is why a design that budgets against the key is budgeting against the wrong number.
| Limit | Scope | Value |
|---|---|---|
| Queries per day | Per site | 2,000 |
| Queries per minute | Per site | 600 |
| Queries per day | Per project | 10,000,000 |
| Queries per minute | Per project | 15,000 |
The per-minute limit deserves separate attention because tripping it wastes the calls it refuses. A batch job that fires a few hundred inspections as fast as the network allows can exhaust 600 in a minute, receive 429s, and — if it retries immediately — trip the same limit again on the retry. Pacing the batch is cheaper than handling the refusals.
Counting inspections per application is a mistake with a specific failure: two applications pointed at one property each believe they have a full allowance, and together they spend twice it. Market4 keys its spend ledger on the Search Console property string — the value that looks like sc-domain:example.com — rather than on the app, because that is the unit Google's quota belongs to. The ledger row is uniquely indexed on the property and the day, so
Google's five words say the page was fetched and left out of the index. They say nothing about why. Here is what the string reports, how it differs from "discovered", and the evidence that narrows it to a cause.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
The day boundary in any such ledger is a local approximation rather than a copy of Google's. Google's usage-limits page gives the daily figure without naming the moment it resets, so a counter that rolls over at midnight UTC will sometimes refuse a call Google would have allowed and, across a reset guessed wrongly, will briefly believe it has more room than it does. The way to use a ledger like that is as a budget to stay under, never as a promise that call number 2,000 will succeed.
An automated job should leave a reserve, because a person clicking around in Search Console has no way to know that a batch has already spent the day. Market4 holds back 200 of the 2,000 and never lets a sweep touch that slice, which is a tenth of the allowance kept for whatever else is pointed at the property. The exact fraction matters less than the principle: a background job that can consume the whole day's quota will eventually consume it on the morning somebody needs one urgent answer.
The URL Inspection API reads and never submits. It reports whether Google has the page indexed, whether the fetch succeeded, which sitemap Google attributes the URL to, the canonical the page declares against the one Google chose, and Google's verdict on the page's structured data. It does not request indexing, and the Indexing API that does is restricted to job postings and livestreams — using it for ordinary articles risks the property's access to it. A tool that offers to index a URL on demand is either doing something else or doing something inadvisable.
Per site. Google's usage-limits page lists the URL Inspection index inspection quota as 2,000 queries per day and 600 per minute for calls querying the same site, alongside a much larger per-project quota tied to the Developer Console key. For anyone working across a small number of properties, the per-site figure is the binding one, and adding a second key does not raise it.
Google answers with an HTTP 429. Both the daily and the per-minute limits are enforced that way, and a call refused with 429 has still been made, so an immediate retry usually trips the same limit again. The practical response is to stop the run, record what was spent, and resume in the next window rather than treating the refusal as a transient error to retry through.
It can, because the allowance belongs to the property rather than to any one client of it. That is why an automated sweep should reserve part of the daily quota and stay out of it. Market4 keeps 200 of the 2,000 aside for exactly this reason, so a scheduled job cannot be the reason an urgent manual check is refused later in the day.
No. The URL Inspection API reads Google's current view of a URL and submits nothing. Google's Indexing API, which does submit, is restricted to job posting and livestream pages, and using it for ordinary content puts the property's access at risk. For everything else the supported routes are a sitemap and internal links from pages Google already crawls.
The submission itself can be undone. The saved address is the part that keeps acting on its own, because it is re-submitted every time you publish.