Google updated the Indexing API documentation on October 16 to describe the current usage limits and process. The company also removed an outdated form. The revision concerns developer information; access remains intended for pages containing job postings or live video broadcasts that meet Google's technical conditions.
The interface allows website administrators to notify Google individually when an eligible page appears, changes or is removed. It serves short-lived content, where publication and withdrawal times matter to the information displayed in search. Google can schedule a fresh crawl of a page after receiving a notification.
Limits apply by project and request type
The default daily allowance is 200 requests to the publishing function for each project. The same allowance covers both URL_UPDATED and URL_DELETED notifications. It resets at midnight Pacific Time. Reading metadata has a separate allowance of 180 requests per minute per project, while the overall limit is 380 per minute across all endpoints. The API is free to use, and project quotas can be viewed in Google API Console.
The reference documentation describes metadata retrieval separately. The getMetadata function works with addresses for which Google has previously received a successful Indexing API notification. The request identifies the address being checked and requires authorization. Checking a notification therefore concerns that URL's history within the interface, rather than providing a general analysis of any page on the internet.
The response object retains the address and the latest update and removal notifications. These fields give an application a record of the operations submitted to Google. A system that manages recruitment listings automatically can match this notification history with its own publication and withdrawal times, while keeping those records distinct from a page's presence in search results.
Eligibility remains tied to the page's content
Google specifies two accepted configurations: JobPosting structured data, or a BroadcastEvent embedded in a VideoObject. Indexing API usage therefore depends on the actual page type and its corresponding markup. Commercial service pages, ordinary articles and online shop categories do not enter this list simply because an administrator can technically submit them through an integration.
For recruitment listings, the search appearance rules require complete information about a real vacancy and a dedicated page for that listing. JobPosting markup belongs on the page for an individual position, rather than a general list of jobs. The visible content and structured data must describe the same offer so that information submitted to the search engine matches what a candidate reads.
Withdrawing a closed vacancy also has specific conditions. The recruitment documentation provides for updating the expiration date, removing the markup or taking down the page, depending on the circumstances. To request removal through the API, the page must return a 404 or 410 status code, or contain a noindex directive. The notification follows an actual change to the page.
Access requires ownership verification and authentication
An integration uses a project with the Indexing API enabled and a service account. Website ownership is verified in Search Console, after which the service account receives delegated owner status. Calls are authenticated with an OAuth token carrying the dedicated indexing scope. These requirements connect the operations to an authorized website administrator and to the project whose quota is being used.
Error responses distinguish access problems from capacity issues. Google documents a 403 error when URL ownership verification fails and a 429 error when the Indexing API quota is exceeded. Rejected requests do not cause Google to crawl the URL. A technical log therefore needs to retain the outcome of each operation so that a failed submission is identified correctly.
The error catalog also includes code 400 for incorrect or incomplete requests, such as a missing address, and code 401 for authentication problems. These responses describe how the interface processes a request. They distinguish an application configuration error from reaching a usage limit and from the situation of a page that the search engine has already analyzed.
An HTTP 200 response to an update notification confirms that the operation was accepted and is associated with its metadata. Google describes the next stage as a possible recrawl of the address. Submissions use JSON, with one URL in each notification. Multiple notifications can be grouped, up to 100 calls within a batch request; the instructions prohibit circumventing submission limits through multiple accounts.
Indexing status is monitored in Search Console
Search Console's URL Inspection tool displays the information available about a version of a page known to Google. This includes indexing status, the last crawl and details about the canonical address. The live test checks the page accessible at that moment, while the indexing report concerns the version processed previously. The two views therefore refer to different points in time.
Google also retains its general technical requirements for search participation: access for Googlebot, an HTTP 200 response from the page and indexable content. Pages that require authentication or block the crawler have different access conditions from a public page. These elements are checked at website level and remain part of SEO management, including when a notification integration is in place.
To discover ordinary pages, Google uses links between pages and information in sitemaps. A sitemap can describe important addresses, their last update and alternate language versions. It is particularly useful for large websites, new websites or sites containing specialized media resources. This mechanism covers a broader range of content than the recruitment pages and live broadcasts accepted by the Indexing API.
