Current default200 publish requests per project per day. Eligible page types only.
Google documented the current Indexing API quotas on October 16
Google Search Central recorded an Indexing API quota documentation update on October 16, 2026. Google said the page was updated to reflect current limits and process, and to remove an outdated form.
This was a documentation update, not an announcement that the API launched or that every site's allowance increased that day. That distinction matters because the quota page describes the current operating rules without claiming a new product capability.
The quota page lists 200 publish requests per project per day, 180 metadata requests per project per minute and 380 total requests per project per minute. The daily quota resets at midnight Pacific Time. Use is free.
The 200 daily publish allowance includes both `URL_UPDATED` and `URL_DELETED` notifications. Projects that need more must request approval and additional quota, which Google says may rise or fall with document quality.
The Indexing API still excludes ordinary website pages
The eligibility rule did not change. Google says the Indexing API can only be used for pages with `JobPosting` structured data or `BroadcastEvent` embedded in a `VideoObject`.
A studio publishing a new article, a retailer changing a category page or a SaaS company launching a feature page cannot treat this API as a general “index now” endpoint. The fact that an authenticated request can be sent does not expand the documented use case.
Google also tells developers not to evade limits through multiple accounts. The usage guide allows one URL per request or batches of up to 100, but each URL still counts against quota.
If a vendor proposes the Indexing API for every page on an ordinary marketing site, ask them to show the relevant Google eligibility rule. A fast workaround that contradicts the documentation is operational debt, not technical SEO.
An HTTP 200 response is not an indexing promise
A successful API response confirms receipt of a notification. Google says it may try to recrawl the URL soon. It does not promise that the page will be indexed, retained or ranked.
The same limit applies to manual requests. Google's recrawl guidance says a request does not guarantee inclusion and that repeated requests do not make crawling faster.
Consider a valid job page that returns 200 but points its canonical to the careers index. The notification may arrive successfully, while the canonical signal still tells Google that another URL is preferred. The API cannot repair contradictory page signals.
Treat notification status, crawl status, index status and search visibility as four different observations. Collapsing them into one “submitted” badge makes dashboards reassuring and decisions worse.
Choose the indexing path by page type and volume
Most indexing work does not need custom API code. Choose the mechanism that matches the page, then diagnose the result in Search Console.
| Situation | Primary mechanism | What it does | What it does not prove |
|---|---|---|---|
| Eligible job or livestream pages | Indexing API plus sitemap | Notifies Google of updates or removals | Indexing or ranking |
| A few important ordinary URLs | URL Inspection | Tests indexability and requests a crawl | Immediate inclusion |
| Many new or changed URLs | Generated sitemap with accurate lastmod | Helps discovery and monitoring | That every URL will be crawled |
| A missing template group | Technical diagnosis first | Finds canonical, robots, link or rendering problems | That submission alone fixes the cause |
Ordinary sites should fix discovery before adding an API
Start with one missing URL in Search Console. Check whether Google knows it, whether crawling and indexing are allowed, which canonical Google selected and whether the rendered page contains the expected content.
Then follow the route a crawler sees. The page needs a stable 200 response, a self-consistent canonical, crawlable internal links and a sitemap entry that uses the preferred URL. A page linked only through a client-side filter may remain difficult to discover even when it appears in your CMS.
Google calls a sitemap a hint, not a guarantee. Its sitemap guidance says `lastmod` should reflect a significant page update, not a cosmetic timestamp change.
For a recurring pattern, fix the template or publishing pipeline. A technical SEO audit should trace discovery, rendering, canonical selection and indexability across page groups instead of repeatedly submitting individual URLs.
What site owners should do now
- Confirm whether the pages contain eligible `JobPosting` or `BroadcastEvent` markup.
- If eligible, record current project quotas and approval status before designing volume.
- Treat `URL_UPDATED` and `URL_DELETED` as notifications, not outcome metrics.
- For ordinary pages, inspect one URL and fix the first contradictory signal.
- Generate a sitemap from canonical production URLs and maintain meaningful `lastmod` values.
- Link new pages from crawlable, relevant pages instead of relying on submission alone.
- Track discovered, crawled and indexed states separately.
- Review content quality with a content audit if technically valid pages remain unselected.
The practical takeaway is boring and useful: the quota changed on a documentation page, but the eligibility boundary remains narrow. Before anyone builds an integration, diagnose one URL end to end and decide whether the problem is discovery, indexability or selection.
If a redesign or migration is creating the problem, protect redirects, canonicals and sitemap logic inside the website redesign strategy. Submission is the final nudge, not the foundation.