Google Indexing API: Setup, Supported Uses and Limitations

Clean tech SEO diagram showing Google Indexing API workflow from Cloud Project and Service Account to crawling and verified indexing

The Google Indexing API lets eligible websites notify Google when supported pages are added, updated or removed. Google currently supports it for pages containing job posting structured data, and for livestream event markup embedded in a video object.

The API can prompt Google to schedule a fresh crawl. It does not guarantee instant indexing, inclusion in Search, or any effect on rankings. That distinction matters, because the setup looks like a general-purpose indexing tool and is not one.

The API is a notification channel, not a delivery channel. An eligible page changes, your server sends an authenticated request naming that URL, and Google may schedule a fresh crawl. Everything after runs through Google’s normal indexing systems, which decide whether the page belongs in the index. Nothing is pushed there directly.

Infographic showing the Google Indexing API workflow from supported page changes and an authenticated API notification to Google receiving the request, scheduling a possible fresh crawl and making a normal indexing decision.
How the Google Indexing API sends supported URL changes to Google before the normal crawling and indexing process.

Searches for instant indexing google collapse three things into one phrase. The notification is instant. The crawl is not guaranteed to be. The indexing decision is separate again.

A successful request returns an HTTP 200, meaning Google may try to recrawl the URL soon. It does not mean the page has been or will be indexed, or will appear in Search within any timeframe. Instant indexing describes the submission, never the outcome.

Google documents two eligible content types: pages carrying job posting structured data, and pages with livestream broadcast event markup inside a video object.

Both share a trait that explains the exception: the content has a short, unpredictable lifespan. A role gets filled, a stream ends, and the page becomes misleading immediately. Waiting for a normal recrawl would leave stale listings in Search, so Google accepts direct notification instead.

Google does not support the Indexing API for ordinary web pages.That includes blog posts, product pages, service pages, category pages and everything else on a typical site. Ecommerce stores are where the temptation is strongest, since new products need visibility quickly, but the route for them stays the ordinary one: a clean sitemap, crawlable internal links and canonical product URLs. This Shopify SEO checklist works through that setup on the platform where duplicate product paths cause the most trouble.

A plugin may expose a submit button for those page types, and the endpoint may return a success response. Neither changes what Google documents as eligible. A success response confirms the request was well-formed and authenticated, not that the page qualifies.

Three operations exist, and the third is most often misread.

ActionPurpose
URL_UPDATEDNotify Google of a new or meaningfully changed supported page
URL_DELETEDNotify Google that supported content has been removed
getMetadataRead the most recent notifications you sent for a URL

The API cannot guarantee indexing, commit Google to crawling at a set time, bypass quality systems, or influence ranking.

Metadata is not an index checker.The metadata endpoint reports whether your notifications were received and when. It does not tell you whether the URL is in Google’s index. Plugin labels like “check URL status” invite exactly this confusion.

Open the Google API Console and create or select a project. Give it a name you will recognise later, because credentials and quota attach to the project rather than your account.

Payment is not part of this step. Google states the Indexing API is available without payment, and billing activation is not listed as a prerequisite.

Inside the project, open APIs and Services, find the Indexing API in the library, and enable it.

Confirm the project selector shows the right project first. Enabling the API on the wrong one is confusing to debug, because credentials created afterwards authenticate correctly while requests fail on permissions.

 Four-step tutorial graphic showing how to enable the Google Indexing API in Google Cloud: select the correct project, open APIs & Services, find the Indexing API in the Library and click the Enable button.
Step-by-step view of how to enable the Google Indexing API in Google Cloud by selecting the correct project, opening APIs & Services, finding the Indexing API and clicking Enable.

Create a service account inside the same project. The optional step granting it a Cloud role can be skipped, since the Indexing API does not require one.

Create a key, choose JSON, and download it.That file contains a private key.Keep it out of version control, public directories and client-side code. Anyone holding it can send notifications for your property.

Step-by-step Google Cloud interface showing how to create a service account, open the Keys tab, add a new JSON key, download it, and keep the private key secure.
Create a Google Cloud service account, generate a JSON key, and store the private key securely before using the Indexing API.

Add the Service Account as a Search Console Owner

Open the JSON file and copy the client_email value. In Search Console, open the property, go to Settings, then Users and permissions, and add that email as an owner.

This is the ownership requirement that matters. A service account does not need to own the Cloud project; it needs verified site ownership in Search Console. Many guides conflate the two and grant Cloud roles that do nothing.

Google Search Console Users and permissions screen showing a service account email added as a new user with Owner permission selected.
Add the service account email to Google Search Console as an Owner so it can submit Indexing API requests for the property.

Every request must be authenticated with an OAuth access token carrying the indexing scope: https://www.googleapis.com/auth/indexing.

The JSON key is not pasted into the request itself. It obtains a short-lived access token, which travels with the request in an authorisation header. Google’s client libraries handle the exchange, which is why plugins can hide the step entirely.

Infographic showing the Google Indexing API OAuth flow from JSON credentials to a service account, OAuth access token, Authorization header and Indexing API, with the required indexing scope and a note that the JSON key is not sent directly with the request.

OAuth authentication flow for the Google Indexing API, from JSON credentials and the service account to the access token and authorised API request.

Send a POST request to the publish endpoint:

POST https://indexing.googleapis.com/v3/urlNotifications:publish

Content-Type: application/json

{

“url”: “https://example.com/jobs/example-role”,

“type”: “URL_UPDATED”

}

Two requirements are easy to miss. The Content-Type header must be application/json, and a single publish request carries one URL only, so an array in the body will not work. Use this for a new eligible page, or one whose content has meaningfully changed.

Infographic showing a Google Indexing API URL_UPDATED POST request with the application/json content type, example URL and URL_UPDATED type, alongside an HTTP 200 response and a note that acceptance does not guarantee indexing.
Example of a URL_UPDATED request sent through the Google Indexing API, with an HTTP 200 response confirming that the notification was accepted.

Order matters here, and reversing it produces silent failures. Before sending a removal notification, the URL must already return a 404 or 410, or carry a robots noindex meta tag. Remove the content, confirm the response, then notify Google:

POST https://indexing.googleapis.com/v3/urlNotifications:publish

Content-Type: application/json

{

“url”: “https://example.com/jobs/example-role”,

“type”: “URL_DELETED”

}

 Four-step infographic showing the correct Google Indexing API removal workflow: remove supported content, return a 404 or 410 response or apply noindex, send a URL_DELETED notification, and confirm Google receives the removal notification.
Correct sequence for sending a URL_DELETED notification through the Google Indexing API after the supported content has already been removed or blocked from indexing.

The metadata endpoint takes a GET request, and the URL parameter must be URL-encoded. Colons become %3A and forward slashes become %2F:

GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fexample.com%2Fjobs%2Fexample-role

The response returns your latest update notification, your latest removal notification, and when each was received. It answers what you told Google and when, not whether the page is indexed.

Split infographic showing a Google Indexing API metadata GET request and a response with the latest URL_UPDATED and URL_DELETED notification timestamps, with a note that metadata does not indicate Google index status.
Use notification metadata to review the latest update and removal notifications sent to Google, not to confirm whether a URL is indexed.

Batching reduces the HTTP connections your client opens, and uses a different endpoint from single notifications:

POST https://indexing.googleapis.com/batch

Content-Type: multipart/mixed; boundary=”BOUNDARY_STRING”

The body is multipart, and each part is a complete HTTP request with its own headers and body rather than an entry in a JSON array.

Batching does not save quota.Quota is counted per URL, so a batch consumes the same quota as sending each notification separately. The saving is connection overhead only.

Infographic showing three Google Indexing API requests bundled into one multipart HTTP batch request and sent through a single connection, with a note that each URL or request still counts individually toward quota.
Batch requests bundle multiple Indexing API notifications into one HTTP connection, while each URL still counts separately toward quota.

The default quota on a new project is intended for onboarding and testing, not production. Google requires a separate approval request both to use the API properly and to receive quota beyond that default, submitted through a form linked from its quota documentation.

The documented defaults, along with the batch limits, are as follows.

LimitDefault
Publish requests per day, per project (URL_UPDATED and URL_DELETED combined)200
Metadata requests per minute, per project180
All requests per minute, per project380
Calls combined in one batch request100
Size of each part within a batch1 MB

The daily allowance resets at midnight Pacific Time, and newly granted quota can take up to a day to take effect. Treat these as starting values rather than fixed ones, and read the live figures from the project’s quota page in the API Console.

Two points carry consequences. Google’s spam policies apply to anything submitted here, and the allocation is not fixed in your favour: quota can move up or down depending on the quality of documents submitted. Creating extra accounts to dodge limits is treated as abuse.

Google Cloud Quotas page for the Indexing API alongside a three-step flow showing initial testing quota, approval request and production quota, with a reminder to check current quota values in Cloud Console.
Google Indexing API quota workflow from initial testing limits through approval to production use, with current quota values checked in Google Cloud Console.

A plugin removes the awkward parts of the implementation. It stores the credentials, performs the token exchange, fires the notification when content changes, and often queues URLs for batching.

That is convenience. A plugin automates the request; it cannot widen the list of content types Google supports.

Three separate propositions get marketed as one, and separating them is the point:

  • The plugin will send the request.True for almost any URL you give it.
  • Google officially supports that page type.True only for job postings and livestream events.
  • Google will index the page instantly.Not guaranteed for anything, including supported content.

The risks follow the same order: ineligible URLs, routing around quota, an exposed JSON key, multiple accounts. The last two are expensive, because access can be revoked.

Decision-tree infographic showing Google Indexing API for supported JobPosting or livestream content, URL Inspection and Request Indexing for a few normal URLs, XML Sitemap for many URLs, and IndexNow for participating search engines other than Google.
Choose the right Google indexing method based on the type and number of URLs, while keeping IndexNow separate from Google’s own indexing tools.

Phrases like Google IndexNow and index now Google appear constantly in search, and neither describes a real feature. IndexNow is a separate open protocol with its own key verification and its own list of participating search engines, and Google is not among them. Implementing it has no effect on Google Search, though it remains worthwhile for the engines that do.

For ordinary pages outside the API’s scope, the supported route is URL Inspection in Search Console. Inspect the URL, confirm Google can access the current version, then use Request Indexing when a page is new, substantially updated or newly fixed. Like the API, this asks Google to crawl again without guaranteeing indexing.

Requesting indexing one URL at a time does not scale. For a full set of pages, a clean XML sitemap of canonical URLs with accurate last-modified dates is what Google recommends.

This holds even where the Indexing API applies. Google notes the API can prompt crawling sooner than a sitemap update, while still recommending sitemap coverage for the whole site. The API supplements sitemaps rather than replacing them.

Where pages still fail to appear after all of this, the problem is usually diagnostic rather than a submission gap. At that point the next step is a technical SEO audit covering crawl access, canonical signals, duplication and internal structure, because no submission method resolves any of those.

Yes. Google states that use of the Indexing API is available without payment.

Cost is not the limiting factor. Quota and approval are. A new project receives a default allocation intended for testing, and proper use requires an approval request to Google first.

No. Google documents the API for job posting and livestream event pages only.

Another page type may still return a success response, because that confirms the request was valid and authenticated, not that the content qualifies. For blog, product, service and category pages, use URL Inspection for individual URLs and a sitemap for the rest.

No. The notification is instant. The crawl and the indexing decision are not.

A successful response means Google may try to recrawl the URL soon. What follows is the same process every other page goes through, including the decision about whether it belongs in the index. No submission method for Google Search removes that step.

No. Google is not listed among the search engines participating in the IndexNow protocol.

For Google Search that leaves three routes: the Indexing API for supported content, URL Inspection for individual URLs, and a well-maintained sitemap for broad discovery. IndexNow can run alongside these for other engines without conflicting.

Yes, for actual supported usage beyond initial onboarding/testing, Google currently requiresapproval and quota provisioning.

A new project receives an initial quota intended for setup and submission testing. After confirming that the implementation is for supported content such asJobPostingor eligible livestream pages, you need to request approval and the resources required for ongoing use.

A401 errorusually points to invalid or expired authentication credentials. A403 error can mean Google cannot verify that the authenticated service account owns the URL being submitted. A429 errormeans the project has exceeded its available Indexing API quota. Check authentication, Search Console ownership and current project quotas before retrying the request.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

HiAgency
HiAgency
HiAgency is a digital marketing and web development agency specializing in SEO optimization and content management solutions. We help businesses improve their online visibility through technical implementations, user experience enhancements, and strategic content organization.

Leave the first comment