Google Indexing API limits: what it officially supports in 2026
Google's documentation states the Indexing API can only be used for pages with JobPosting or BroadcastEvent structured data. Everything else is outside supported use, and a 200 response confirms receipt, not crawling.
This page exists because the API is the most oversold shortcut in indexing, and the cost of finding that out yourself is usually a week of engineering time.
The documented scope
Google's Indexing API documentation states that the API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject. That is two content types: job listings and livestream video pages. Not blog posts, not product pages, not backlink donors.
The usage guidelines add that Google's spam policies apply to content submitted through it.
The quota
The default is 200 publish requests per day per Cloud project. Higher quotas require a request through Google Cloud, and approval is tied to having the qualifying structured data — so the restriction is enforced at the quota stage, not merely documented.
What a 200 response means
It means the request was received. It does not mean the URL was crawled, and it certainly does not mean it was indexed. The endpoint does not validate that the page contains the required schema; it accepts, queues, and any filtering happens later. This is why people report the API "working" — they see success responses, not crawls.
Why building a workflow on it is a bad trade
- It is outside supported use for your content type. Google has publicly signalled it may stop honouring unsupported formats, and behaviour that is not documented is behaviour that can change without notice.
- It requires ownership verification. A service account and a verified property. For backlink indexing, where the URLs are on other people's domains, this alone rules it out.
- Multi-account rotation to bypass the quota is described as abuse in the same context as access revocation.
- The setup cost is real. Cloud project, service account, key management, error handling — for a path that is not designed for what you are trying to do.
What to use instead
| Goal | Supported path |
|---|---|
| Get your own new pages seen | Sitemaps, internal links, URL Inspection for individual pages |
| Check whether a URL of yours is indexed | URL Inspection API on a verified property |
| Get third-party donor pages crawled | Ordinary crawl requests at a controlled rate — see backlink indexing |
| Job listings or livestreams | The Indexing API, as designed |
If you run a job board, this API was built for you and you should use it. If you do not, the honest answer is that it is not a shortcut you have access to.
Questions
Will Google penalise me for submitting ordinary pages to the Indexing API?
Google has not described penalties for it, but it has described the behaviour as unsupported and has raised the possibility of dropping unsupported formats without notice. The practical risk is wasted effort and losing API access, not a ranking action.
Does SpeedyIndex use the Indexing API?
No. The API's documented scope does not cover ordinary pages or third-party donor URLs, which is what an indexing service is asked to handle.
The supported path, for pages the API does not cover
Ordinary crawl requests at a controlled rate, on URLs you do not need to own. Pay only for what ends up indexed.
See how it works