Direct answer
Google updated the Indexing API quota page on October 16, 2026. Current defaults are 200 publish requests per project per day, 180 read-only metadata requests per project per minute and 380 requests across all endpoints per project per minute. Batch calls still consume quota per URL. The more important boundary did not change: the API is only for pages containing JobPosting or BroadcastEvent embedded in VideoObject. Ordinary product, service, article and press pages should rely on crawlable internal links, sitemaps and correct canonicals, with Search Console URL Inspection for a small number of URLs. HTTP 200 proves that Google received the notification and may try to recrawl; it does not prove indexing, ranking or inclusion in an AI answer.
Facts and background
Google Search Central updated its Indexing API quota page on October 16, 2026, stating that the change reflects current quota limits and process while removing an outdated form. The current page lists three defaults: 200 publish requests per Google Cloud project per day, 180 read-only getMetadata requests per project per minute and 380 requests across all endpoints per project per minute. Use of the API is free.
The update did not turn the Indexing API into a general URL-submission service. Google still limits it to two page classes: a page containing JobPosting, or a livestream page with BroadcastEvent embedded in VideoObject. Ordinary product, category, service, technical article, case-study, press and landing pages did not become eligible because the quota documentation changed.
What the three default quotas control
| Official quota | Current default | What is counted | Operational meaning |
|---|---|---|---|
DefaultPublishRequestsPerDayPerProject | 200/day/project | URL_UPDATED and URL_DELETED combined | Update and removal notifications share one daily pool |
DefaultMetadataRequestsPerMinutePerProject | 180/minute/project | Read-only getMetadata calls | Useful for notification receipt, not continuous index-status polling |
DefaultRequestsPerMinutePerProject | 380/minute/project | Requests across all endpoints | Publish and metadata traffic also share an overall minute limit |
The daily quota resets at midnight Pacific Time, and Google notes that new quota can take up to 24 hours to become effective. Teams should inspect the actual quota for each project in Google API Console rather than hard-code the defaults as a guaranteed allowance per account, domain or market. Quota belongs to a Cloud project, while calls also require Search Console ownership and service-account authorization. Available quota does not authorize arbitrary URLs.
A batch of 100 is not one quota unit
The Indexing API lets a client combine up to 100 calls in one multipart HTTP batch to reduce connection overhead. Google explicitly counts quota at URL level: a batch containing ten URL calls consumes ten requests, not one. The 100-call batch limit therefore does not multiply a 200-request daily default into 20,000 URLs.
Batching improves network throughput, not eligibility, quota or outcome guarantees. An operating system should retain the request type, HTTP result, notification time, page class, structured-data version and later indexing observation for each URL. A single “batch succeeded” record is not sufficient evidence.
HTTP 200 proves receipt, not indexing
For URL_UPDATED, Google says HTTP 200 means that it may try to recrawl the URL soon. For URL_DELETED, HTTP 200 means that Google may remove the URL. A successful response does not prove that a crawl finished, rendering succeeded, the page entered the index, a rich result appeared, rankings improved or a generative AI answer used the page.
getMetadata returns the last notification type and receipt time. Google explicitly says it does not tell you when a URL was indexed or removed. Notification and outcome evidence must remain separate: API responses prove submission, server logs prove a fetch, Search Console or public results help observe indexing and presentation, and AI-source testing separately records citations.
| Evidence layer | What it can prove | What it cannot prove |
|---|---|---|
| Publish HTTP 200 | Google accepted an eligible URL notification | Crawl, indexing or presentation |
| getMetadata | Latest update/removal notification type and receipt time | Current index status or page version |
| Origin or CDN logs | A real Google fetch occurred at a recorded time | The content entered the index or an answer |
| Search Console and public results | Observable index and selected search-presentation states | Complete visibility for every market, user and AI surface |
| Fixed-question AI test | A citation for one platform, time and question set | That the Indexing API caused the citation |
Eligible and ineligible page classes
| Page scenario | Indexing API eligibility | Correct route |
|---|---|---|
| An individual, publicly available job detail page | Eligible when the visible page truthfully contains compliant JobPosting | Notify on creation, material update or closure while keeping visible facts and markup aligned |
| A livestream event page | Eligible when BroadcastEvent is embedded in VideoObject and requirements are met | Maintain page state and notifications around the event lifecycle |
| Ordinary product, category or service page | Not eligible | Use internal links, sitemap, canonical, crawlable HTML and relevant merchant-data channels |
| Industry article, news release or case study | Not eligible | Use normal discovery; request a recrawl in URL Inspection for a small number of important URLs |
| Ordinary content with fabricated job or event markup | Noncompliant and high risk | Remove mismatched markup; structured data must match visible content and the real page role |
Eligibility follows the real page class and compliant markup, not a team's desire for faster discovery. Adding fictional JobPosting or BroadcastEvent data does not legitimately transform ordinary content. It creates a mismatch between structured data and visible text and raises spam and rich-result quality risks.
The correct discovery path for ordinary pages
Google's official path for ordinary URLs remains a crawlable site architecture. Important pages should be reachable through navigation or contextual links and expose a stable 200 response, a unique canonical, correct language relationships and an updated sitemap. Google states that a sitemap assists URL discovery but does not guarantee that every listed item will be crawled or indexed.
For a few new or changed URLs, use Search Console URL Inspection to request a crawl. For many URLs, submit a sitemap. Google also states that crawl requests do not guarantee immediate or eventual inclusion and that repeatedly requesting the same URL will not make crawling faster. A global brand needs durable, discoverable authority URLs for every market, not a universal submit button.
Build a notification state machine for eligible pages
Brands with multinational recruiting or livestream operations can connect the Indexing API to a publication state machine. Before publishing, validate page type, visible facts, structured data, canonical, HTTP status and Search Console ownership. Send URL_UPDATED only after a new page or material change becomes public. When a job closes or livestream page should leave the index, first return 404/410 or deploy a crawlable noindex, then send URL_DELETED.
The system should deduplicate notifications, track daily and per-minute project quotas, and queue work near a limit instead of adding accounts to bypass it. Google prohibits circumventing submission limits; abuse, including multiple accounts used to exceed quota, may revoke API access. Service-account private keys belong in dedicated secret management, never source repositories, public pages, build logs or third-party analytics.
Measure freshness as four separate layers
Freshness acceptance for eligible pages should separate notification receipt, actual fetch, expected index or removal state, and accurate presentation on search or AI surfaces. Passing one layer never substitutes for the next.
A job update may receive HTTP 200 before Googlebot fetches it. A new fetch may occur before Search Console reflects the state. Search may display the new version while an AI answer still uses an older cache. Each case needs a different diagnosis and cannot be summarized as insufficient quota. Record the URL version, notification time, fetch time, index observation and public-result time to locate the delay.
Business impact
Global brands operating multi-market career sites, livestream launches or real-time event pages should read this update as a renewed quota and process boundary. The daily publish pool combines updates and removals. When countries, subdomains and business units share a Cloud project, ownership, queueing, expiration handling and post-notification evidence need explicit governance. Batching saves connections but does not increase quota. For most product-marketing and knowledge teams, the central lesson is to stop using the wrong interface. Submitting ordinary products and articles through the Indexing API falls outside the official scope and hides the real faults in internal links, sitemaps, canonicals, rendering or content quality. Google indexing, Bing or IndexNow notifications, OpenAI search crawling and AI-citation measurement are separate control planes. Success in one cannot stand in for visibility across all of them.
Zhihe Growth assessment
The value of Google's documentation change is not a new indexing shortcut. It makes the current defaults and process legible again. In GEO programs, the costly error is rarely a shortage of a few requests; it is collapsing submission, crawl, indexing, citation and business outcomes into one metric. The Indexing API is a narrow notification channel, not a substitute for technical admission, authoritative content or explanation chains. Zhihe Growth recommends an eligibility-first, notify-second, layered-acceptance model. Ordinary pages return to internal links and sitemaps. Only job and livestream pages enter the Indexing API state machine. API response, crawl evidence, index state and citation outcome remain separate fields per URL. Discuss project quota only when evidence localizes the delay to the notification layer; otherwise fix the actual crawl, index, content or measurement failure.
Recommended actions
- Record the actual publish, metadata and total per-minute quota for every production project in Google API Console rather than treating defaults as guarantees.
- Inventory every URL planned for Indexing API submission and retain only genuine JobPosting or BroadcastEvent-in-VideoObject pages.
- Stop Indexing API calls for ordinary products, services, articles and cases; audit internal links, sitemap, canonical, HTTP status and crawlable copy instead.
- Preserve Search Console ownership, service-account authorization, page class, structured-data version and canonical evidence for eligible URLs.
- Count URL_UPDATED and URL_DELETED against the same default 200-request daily publish pool and monitor the overall minute limit.
- Charge batch quota by child URL request, preserve each child response and never use one batch-success flag as URL-level acceptance.
- Store HTTP 200, getMetadata, origin fetch logs, Search Console state and public search or AI citations in separate fields.
- Before URL_DELETED, return 404/410 or deploy a crawlable noindex on a closed job or retired livestream page.
- Use Search Console URL Inspection for a few ordinary URLs and maintain sitemap freshness for many URLs without repeated crawl requests.
- Audit service-account keys, project owners, quota anomalies and duplicate notifications monthly; prohibit multi-account quota circumvention and retain revocation and rotation records.
Limitations
This article reflects Google Search Central documentation accessible on October 22, 2026 and confirms the October 16 quota-page update and current defaults. Actual project quota must be checked in API Console. Defaults, process and product scope may change. The daily reset uses Pacific Time, and new quota can take up to 24 hours to become effective. The Indexing API supports only pages containing JobPosting or BroadcastEvent embedded in VideoObject. The presence of markup does not prove compliance with all content and feature requirements. A successful notification does not guarantee crawling, indexing, rich results, rankings, traffic or AI citation. Sitemaps and URL Inspection requests for ordinary pages do not guarantee indexing either. This article does not recommend fabricated page types, repeated submission, multiple accounts or projects to bypass limits. Cross-platform freshness also depends on each search and AI system's crawler, index, cache and retrieval mechanisms. Google Indexing API status cannot be generalized to Bing, OpenAI or other platforms.