Google updated its Indexing API documentation on October 16, 2026, removing an outdated quota-request form and revising the explanation of the process. That does not mean the API now offers unlimited submissions: the current quota page still lists a default of 200 publish requests per day per project.
The practical change is in the published guidance. Site owners need to check their actual project limits rather than follow an old approval-form tutorial or assume that a successful notification guarantees indexing. The API also remains restricted to eligible job-posting and livestreaming-video pages. It has not become a supported shortcut for indexing ordinary blog posts or product pages.
What Google changed on October 16
Google's Search Central changelog describes an update to the Indexing API quota documentation and the removal of an outdated form. It does not announce a higher daily allowance or an expansion to every type of website content.
Contemporaneous coverage of the documentation changes compared the previous approval instructions with the revised pages. Earlier wording directed users toward an approval and quota-request form and described the initial allowance in a testing context. The current quickstart no longer lists that approval step in its getting-started sequence.
There is an important limit to that comparison: removing explanatory wording does not, by itself, establish how every existing or newly created project is handled behind the scenes. Google's current documentation is the basis for configuring a workflow today; older screenshots explain the confusion rather than establish today's limits.
| Question raised by the update | What the current official pages establish |
|---|---|
| Was an old form removed? | Yes. Google's changelog explicitly identifies an outdated form. |
| Did the default publish allowance disappear? | No. The current quota table still specifies 200 requests per day per project. |
| Does the new quickstart retain setup requirements? | Yes. It still points to API access, a service account, property ownership and authentication prerequisites. |
| Did ordinary articles become eligible? | No. The quickstart still identifies the supported job and livestream page types. |
| Is there a newly documented guarantee of higher quota or approval time? | The reviewed pages provide no such guarantee. |
Treat this as a reason to review instructions and effective project settings. A workflow that already has a different assigned quota should be assessed against that actual value. Do not overwrite a working configuration merely to make it match a default shown in an article.
Current Google Indexing API quota limits
The official quota page, checked on October 17, lists three defaults. Each answers a different capacity question.
| Quota | Documented default | What it measures |
|---|---|---|
| Publish requests per day per project | 200 | Notifications using the publish endpoint, including both URL_UPDATED and URL_DELETED |
| Metadata requests per minute per project | 180 | Read-only notification-status requests to getMetadata |
| All requests per minute per project | 380 | Requests across the API's endpoints |
These are project limits, not a fresh allowance for each domain, worker process or service-account file. If two publishing jobs use the same project, their activity has to be considered together. A local counter in one script cannot show what the other has consumed.
The daily boundary is midnight Pacific Time. Avoid a scheduler that assumes midnight in your own time zone is the reset. Also avoid treating Pacific Time as one permanent UTC offset: daylight saving changes that relationship. Use a time-zone-aware schedule if your workflow depends on the reset.
The minute counters still matter when the daily budget has room. A burst of metadata polling can encounter its own limit without exhausting the daily publish allowance. Conversely, spreading requests slowly through the day does not create more daily publish capacity.
Google currently lists Indexing API use as free. That is not evidence that buying another product, enabling billing or paying a third-party service buys an official quota increase. A vendor's subscription limits and Google's assigned project limits are separate constraints.
The public table supplies defaults; your project supplies the effective values to plan around. Record the project's current limit and usage in the API Console before running a large job. Do not report that you have 200 requests remaining merely because the documentation says the default is 200.
Which indexing workflow should you use?
Check eligibility before optimizing a request budget. The Indexing API quickstart limits supported pages to JobPosting or BroadcastEvent embedded in a VideoObject. The content must genuinely meet that description. Adding unrelated markup to an article does not turn it into an eligible job or livestream page.
Several interfaces use the word “indexing,” but they perform different jobs:
| Reader's task | Appropriate documented route | What not to assume |
|---|---|---|
| Notify Google about an eligible job or livestream page | Indexing API, with the required access and actual project quota | A notification is an instruction that forces indexing |
| Request a recrawl of a few ordinary URLs you manage | URL Inspection's Request indexing action in Search Console | Its manual allowance equals the API's 200-per-day default |
| Help Google discover a larger inventory of public URLs | A maintained sitemap and crawlable site links | Submitting a sitemap guarantees every listed URL is indexed |
| Retrieve Google's recorded index status programmatically | URL Inspection API | A successful inspection sends an indexing request or performs a live test |
Google's recrawl guidance explains the individual-URL and sitemap routes. Its manual submission quota is separate; that page does not publish the same numeric daily allowance as the Indexing API quota table.
The URL Inspection API reference describes access to the version in Google's index. Even though the request uses HTTP POST, its operation is inspection. The HTTP verb does not make it a submission endpoint. This distinction also applies when a tool wraps the API: a report that reads index status is not proof that a Request indexing action happened.
For ordinary blog posts, product pages and category pages, stay with the appropriate discovery and recrawl workflow. Screpy's XML sitemap guide explains the broader discovery process. If you are connecting analysis through an AI client, the Search Console MCP guide covers a separate analysis workflow; it does not expand Google's Indexing API eligibility.
What to do if you need more quota
Start with the project that your current integration actually uses. A different browser-selected project, an old development project or a vendor-managed integration can make the quota screen look unrelated to the requests in your logs.
Google's current quota documentation directs users to the API Console to view their allowance. After the October 16 cleanup, it no longer provides the old public form instructions as a dependable step-by-step approval route. Use the options actually presented for your project; do not assume an old tutorial's button, external form or promised response time still applies.
Before changing anything, collect this small evidence record:
| Field | What to record |
|---|---|
| Project identity | The project used by the submitting integration, checked against its configuration |
| Effective limits | Current daily publish, metadata-per-minute and overall-per-minute limits |
| Observed usage | Relevant consumption window and any other jobs sharing it |
| Eligible workload | New, meaningfully changed and removed job or livestream URLs |
| Failure detail | Operation, timestamp, HTTP status, structured reason and message |
| Capacity shortfall | The gap between the real eligible workload and available allowance |
Keep credentials, access tokens and private keys out of support tickets and shared worksheets. The project identity is a diagnostic reference; it is not a substitute for authentication.
If the console offers an increase-request route, review its current requirements and retain the request details. If no usable route is available, record that state. The documentation change alone does not establish that requests will be approved, that an old pending application has been accepted, or that Google will automatically scale a project's quota with traffic.
The Indexing API prerequisites still matter. Confirm that the API is enabled, the correct service account has the required site ownership and the request has valid authentication. More quota will not repair missing access.
Avoid creating multiple accounts to get around a limit. Google's quickstart warns that attempts to circumvent usage quotas can result in revoked access. Preserve a working integration, address the actual capacity problem and continue maintaining discovery through your site while any access issue remains unresolved.
Plan notifications within your project budget
A budget becomes useful when it describes changes to eligible pages, rather than the total number of pages on the site. Repeatedly sending the same unchanged inventory can consume capacity without representing a new publishing event.
Consider a fictional job board whose project has an effective daily publish limit of 200. Its planned workload is:
| Event | Planned notifications |
|---|---|
| New eligible job pages | 70 |
| Existing jobs with meaningful content changes | 100 |
| Removed jobs that satisfy Google's removal prerequisites | 50 |
| Total | 220 |
| Amount above the assumed daily allowance | 20 |
The arithmetic is 70 + 100 + 50 = 220. This is a planning example, not a measured workload or a recommendation to defer a particular type of job change. It shows why “we only publish 70 new jobs a day” can underestimate the notification requirement.
Count the whole project workload before dispatching it. Another integration using the same project may already have consumed part of the allowance. Decide how your publishing policy handles insufficient capacity, preserve unsent work explicitly, and do not mark it as successfully notified merely because a task was scheduled.
For removal notifications, check the underlying page first. Google's API usage guide requires a qualifying removal state, such as a 404, 410 or noindex, before requesting removal. Sending URL_DELETED is not a substitute for updating the page itself.
Batching changes transport efficiency, not the notification budget. Combining 100 notifications into one multipart request still represents 100 requests for quota accounting. Inspect each item's response so that a successful outer request does not hide failed entries.
A useful local dispatch record has the canonical page URL, event type, content-change identifier, attempt time and per-item outcome. Deduplicate repeated work for the same event, while allowing a later genuine change to create another notification. Keep notification acceptance separate from a later indexing observation.
Do not invent an accounting rule for every failed attempt. Retain failure details and compare your own records with actual project usage. Neither restarting a worker nor clearing its local counter changes Google's quota.
Diagnose errors without mistaking acceptance for indexing
Read a failed response as evidence about that operation. An HTTP status alone rarely identifies the entire problem; retain the structured error reason and message as well. Google's Indexing API error reference lists several reasons that can share a status code.
| Observation | Check next | Avoid concluding |
|---|---|---|
401 with an authentication-related reason |
Token validity and the intended authenticated identity | The daily publish allowance is exhausted |
403 with a permissions-related reason |
Service-account access and verified property ownership | Buying capacity will fix access |
A quota- or rate-related reason, potentially with 403 or 429 |
The named limit, its time window and actual project usage | Every such response means the same daily limit |
| A daily-limit failure | Stop that dispatch path until allowance is available | A tight retry loop can produce more daily quota |
| A short-term rate failure | Reduce request rate and follow applicable retry guidance | The entire day's publish allowance has necessarily been spent |
| A successful publish response | Store the per-URL notification result and observe subsequent indexing separately | The URL is now indexed or will rank |
| Missing metadata for a URL | Exact URL, project/identity context, request records and returned error | This alone proves a specific undocumented approval or sandbox state |
The last two rows are particularly important after a documentation change. A response can confirm an API operation without answering every SEO question about the page.
Google explains that a successful update notification means it may try to recrawl the URL. The notification-metadata endpoint reports received notifications; it does not report the time Google indexed or removed the page. Keep those two types of evidence in separate fields in your reporting.
For example, a job's record might contain a notification timestamp and HTTP result, followed later by a separate URL Inspection observation. Until the latter is available, the indexing field should remain unknown. Do not fill it with the notification time to make a dashboard look complete.
Likewise, do not diagnose a universal approval freeze from one failed metadata lookup. Reports of that pattern are useful questions to investigate, but an undocumented explanation requires evidence beyond a status code. Save enough context to distinguish a reproducible fault from an assumption.
For a team reviewing its integration after October 16, the useful outcome is a reconciled record: current documentation, effective project limits, eligible workload, per-request results and separately observed indexing status. That gives you something concrete to correct without treating the removal of a form as proof of unlimited access.
The official documentation and competing explanations used here were checked on October 17, 2026. This is a documentation-based guide; the worked job-board budget is illustrative, and no live API experiment or approval outcome is claimed. Recheck the quota and quickstart pages when Google publishes further process guidance.