Google Indexing API: what it's for, quotas and setup

For every other kind of page, the routes Google supports are sitemaps, internal links and Request indexing in Search Console. This guide covers what the API is for, its quota and limits, what URL_UPDATED and URL_DELETED do, how a job site sets it up, and why using it for other pages is outside Google's stated scope.

What is the Google Indexing API for?

The Google Indexing API is for job posting and livestream video pages, the kind of "short-lived pages" Google says it was built to keep fresh. As of October 2026, Google's quickstart says it "allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed. This allows Google to schedule pages for a fresh crawl", and that it "can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject" (Indexing API Quickstart).

Google's structured-data guides tell those two kinds of site to use it:

• Job postings: "For job posting URLs, we recommend using the Indexing API instead of sitemaps because the Indexing API prompts Googlebot to crawl your page sooner", while still submitting a sitemap for the whole site (Job posting structured data). Expired jobs must be removed, and Google warns that failing to act on them "may result in a manual action."
• Livestreams: call the API when the video goes live, when it stops and the markup shows the endDate, and whenever the markup changes. Google adds: "The Indexing API only supports livestream videos" (Video structured data).

Anything else, including blog posts, product pages, landing pages and backlinks on other people's sites, falls outside that scope.

What are the Indexing API quota and limits?

The Indexing API's default quota is 200 publish requests a day per Google Cloud project. As of October 2026, Google's quota page lists three defaults and says "All use of the Indexing API is available without payment" (Quota and pricing):

Other limits from Google's Using the Indexing API page:

• One URL per update request, or up to 100 requests combined in one batch.
• Batching doesn't save quota. "Quota is counted at the URL level. For example, if you combine 10 requests into a single HTTP request, it still counts as 10 requests for your quota."
• No workarounds. "Don't circumvent our submission limits, such as by using multiple accounts."
• Going over quota returns HTTP 429 with "Insufficient tokens for quota 'indexing.googleapis.com/default_requests'" (Indexing API errors).

What do URL_UPDATED and URL_DELETED do?

URL_UPDATED and URL_DELETED are the only two notification types the Indexing API accepts, and both go to the same publish endpoint. A third call, getMetadata, reads back what you sent.

Google is clear that the status call isn't an index check: "The GET request doesn't tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request." Removal also has a precondition: "Before you request removal, the URL must return a 404 or 410 status code or the page must contain <meta name="robots" content="noindex" /> meta tag."

To confirm there's nothing more to the API, we read Google's machine-readable description of it on October 17, 2026:

curl -s 'https://indexing.googleapis.com/$discovery/rest?version=v3' \
  | jq -r '.. | objects | select(has("httpMethod") and has("id")) | "\(.httpMethod) \(.id)"'
curl -s 'https://indexing.googleapis.com/$discovery/rest?version=v3' \
  | jq -r '.schemas.UrlNotification.properties.type.enum | join(", ")'

GET indexing.urlNotifications.getMetadata
POST indexing.urlNotifications.publish
URL_NOTIFICATION_TYPE_UNSPECIFIED, URL_UPDATED, URL_DELETED

Two methods and two real notification types. Nothing in the API reports whether a page is indexed, and there's no priority setting.

How do you set up the Indexing API for a job site?

Set up the Indexing API by creating a Google Cloud project, giving a service account owner access to your Search Console property, and sending authenticated requests. These steps follow Google's prerequisites page as of October 2026:

1. Create a project and enable the API. Google says to "use the setup tool, which guides you through creating a project in the Google API Console and enabling the API."
2. Create a service account. On the Service accounts page, click Create Service Account, skip the optional permissions, then Create key and choose JSON. Google notes the downloaded key "serves as the only copy of this key", so store it securely and never commit it to a repository.
3. Verify the site in Search Console with any supported method, as a Domain or URL-prefix property.
4. Add the service account as an owner. In Search Console, open the property, click Add an owner in the Verified owner list, and enter the service account's email (the client_email value in the JSON key).
5. Get an OAuth access token with the scope https://www.googleapis.com/auth/indexing. Google's client libraries handle this for Python, Java, PHP and Node.js.
6. Send a notification when a job or livestream page is published, changed or removed:

curl -sS -X POST https://indexing.googleapis.com/v3/urlNotifications:publish \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -d '{"url":"https://example.com/jobs/42","type":"URL_UPDATED"}'

The Content-Type header is required: Google says calls "MUST use "application/json" as the Content-Type header." We sent the same request without a token on October 17, 2026, to show the first error most people hit:

{
  "error": {
    "code": 401,
    "message": "Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
    "status": "UNAUTHENTICATED"
  }
}

If the token works but the service account isn't an owner of the property, Google's documented error is HTTP 403: "Permission denied. Failed to verify the URL ownership." Google adds that for these errors "the request was rejected and Google doesn't crawl the URL."

Can you use the Indexing API for blog posts or other pages?

Using the Indexing API for blog posts, product pages or other non-job, non-livestream pages is outside the scope Google states, and we don't recommend it. Google's quickstart is explicit about the page types, and it adds: "All submissions through the Indexing API undergo rigorous spam detection. Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked." Google's guidelines also say "Our spam policies apply to content submitted with the Indexing API."

The practical risks for a site that ignores this:

• Access can be revoked for the project, under Google's own wording above.
• A 200 isn't a result. It only means Google "may try to recrawl"; nothing in the response says the page was indexed.
• The quota is small. 200 URLs a day per project, and Google forbids using extra accounts to get around it.

If your pages aren't jobs or livestreams and you want to know which ones Google hasn't indexed, check your pages' index status free.

WordPress plugins that use the Indexing API

Several WordPress plugins send posts to the Indexing API. Rank Math's Instant Indexing for Google plugin says it "sends a crawl request to Google using the Google Indexing API" when you publish or update content, and its own listing notes "Google recommends that you use the Indexing API ONLY for Job Posting and Live Streaming websites" (WordPress.org plugin page, as of October 2026). Our comparison of FreshlyCited and Rank Math Instant Indexing covers the differences, and our roundup of WordPress indexing plugins shows which ones use which method. If your WordPress site isn't a job board or livestream site, Google's scope applies to the plugin's requests too. The same goes for AI-assistant tools: some servers in our review of Google Search Console MCP servers add Indexing API calls.

What should other sites use instead?

Other sites should use the methods Google documents for all pages: a sitemap, internal links, and Request indexing for a few important URLs. Google says "Crawling can take anywhere from a few days to a few weeks" and "Our systems prioritize the fast inclusion of high quality, useful content" (Ask Google to recrawl).

IndexNow is an open "this page changed" notice that Bing and other participating engines accept; Google doesn't use it, so it's a complement for Bing, not a Google route.

Our guide to the free ways to submit a URL to Google walks through each method, the URL Inspection tool guide covers Request indexing and its limits, and fixing "Sitemap could not be read" helps if your sitemap isn't being fetched. For how it all fits together, see how Google crawls and indexes pages.

FreshlyCited is a separate service, not the Indexing API. It checks the Google index status of each URL, pushes only the ones Google hasn't, and re-checks them on days 1, 3 and 7; an index credit is used only if the link gets indexed, and comes back after the day-7 re-check if it isn't (exclusions apply, such as pages that return an error or carry noindex). Google still decides what it indexes.

Not a job board? Check which of your pages Google has indexed, free, push only the invisible ones, and get them re-checked.