Google Indexing API Setup for a Website: The Honest 2026 Guide

Google’s default Indexing API allowance starts at 200 publish requests per day per Google Cloud project, but that does not turn it into a general-purpose “index every page” button. This Google Indexing API setup guide shows us how to configure the API, service account, JSON key, and Search Console permissions correctly—while choosing the right discovery method for ordinary product, blog, and landing pages. (developers.google.com)

Start with the eligibility rule—not the setup screens

The most consequential part of a Google Indexing API setup is not creating credentials. It is confirming that the URLs belong to the API’s documented use case: pages with `JobPosting` structured data or a `BroadcastEvent` embedded in `VideoObject` for livestream content. Google’s own API documentation frames the endpoint as a way to notify Search about updated or removed pages in those two categories. (developers.google.com)

That distinction matters because an accepted HTTP request is not a promise that a normal blog post, category page, product page, PDF, or homepage will be crawled and indexed. Google still evaluates crawlability, canonicalization, quality, duplication, robots directives, and its broader indexing systems. Google defines an indexed page as one Googlebot has visited, analyzed, and stored in its index—not simply a URL that a site owner submitted. (support.google.com)

Use this guide if we operate one of these scenarios:

• A job board publishes, changes, and removes time-sensitive job listings marked up with JobPosting.
• A video publisher needs Google notified when a livestream page’s BroadcastEvent status changes.
• A developer or agency needs a compliant, repeatable notification workflow instead of manually clicking through Google Search Console.

For regular editorial, ecommerce, service, and documentation pages, a clean XML sitemap and internal links are the baseline. Search Console’s manual Request Indexing feature is best reserved for individual URLs that we have fixed or need to test, not a batch-submission system. See our guide to how to index your website and get new or updated pages found for that broader workflow.

What a Google Indexing API setup can and cannot do

Google’s endpoint receives a notification that a URL was updated or deleted. The request type is either URL_UPDATED or URL_DELETED; it is not an instruction that Google must add a URL to search results. Google’s documentation specifically describes these operations as notifying Google to update or remove supported pages. (developers.google.com)

What it can do

For eligible pages, API notifications give Google a timely signal that a URL has changed. That is particularly useful where a job listing can disappear before a routine crawl finds the update, or where a livestream status changes from scheduled to live to completed.

A practical example: a job board updates salary, location, or availability on https://example.com/jobs/marketing-manager. After updating the visible content and valid JobPosting markup, the site can send one URL_UPDATED notification. When that role closes and the page is removed or returns an appropriate unavailable status, it can send URL_DELETED.

What it cannot do

The API cannot overcome technical or content barriers. It will not make a blocked URL indexable, override a noindex directive, choose your preferred canonical, or make thin duplicate pages valuable enough to index. It also does not replace validation of structured data, server responses, or site architecture.

It is also not Google Search Console’s general URL submission API. The Search Console API and URL Inspection API can help us manage properties and inspect status, but they do not provide a supported way to automate unlimited “Request Indexing” clicks for ordinary pages. For a clearer comparison, read Google Search Console API quota vs. the Indexing API and IndexNow.

Create a Google Cloud Indexing API project

Google’s prerequisite flow begins with a Google Cloud project. A project is the container for API activation, credentials, quotas, and usage controls, so agencies should normally keep each client’s access clearly separated rather than sharing an unmanaged personal project. Google’s setup documentation directs users to create a project and activate Indexing API access through its setup flow. (developers.google.com)

Follow these steps:

1. Sign in to the Google account that manages the website’s Search Console property.
2. Open Google Cloud Console and create a project, such as Client Name – Indexing API.
3. Select that project in the Cloud Console project picker.
4. Open APIs & Services, search for Indexing API, and enable it.
5. Confirm that the project now lists the API as enabled before creating credentials.

Keep the project name descriptive. If an agency manages 12 job-board clients, a naming convention such as client-domain-indexing-api makes it much easier to audit keys, ownership, quota requests, and former staff access.

Google’s current setup guidance also makes an important separation: creating the Cloud project is not the same as proving that we own the website. We need both a Cloud project and a verified Search Console property before API requests can work. (developers.google.com)

Create the service account and protect the JSON key

A service account is the non-human identity that authenticates requests from our script, CMS integration, or local automation tool. It has its own email address, typically ending in iam.gserviceaccount.com; it is not the email address of the person who created the Cloud project.

In Google Cloud Console, go to IAM & Admin → Service Accounts, choose Create Service Account, and give it a recognizable name such as indexing-notifier. Google says that assigning optional project-level service-account permissions is not required for this setup step. (developers.google.com)

Next, create a key for that service account:

1. Open the newly created service account.
2. Select Keys and choose Add key → Create new key.
3. Select JSON as the key format.
4. Download the file once and store it securely.

Google recommends JSON and explains that the downloaded private key is the only copy of that key pair supplied at creation time. Treat it like a production password: do not email it, place it in a public repository, paste it into a ticket, or expose it in browser-side JavaScript. (developers.google.com)

For a local workflow, store the JSON file outside the website directory and reference its path through an environment variable or OS credential store. For a server workflow, use a secret manager or protected deployment variable. If we believe a key was exposed, create a replacement key, update the integration, and delete the old key immediately.

Add the service account as a Search Console owner

This permission step causes a large share of failed setups. Enabling the API in Google Cloud does not grant the service account permission to notify Google about our URLs. The service account must be added as an owner of the relevant Search Console property.

Google’s documented order is: first verify site ownership in Search Console, then add the service account as a delegated owner. Google supports either a Domain property such as example.com or a URL-prefix property such as https://example.com/; the service account email is available in the JSON file’s client_email field. (developers.google.com)

Assign ownership carefully

1. Open Google Search Console and select the property that covers the URLs we will notify.
2. Open Settings → Users and permissions.
3. Add the service-account email address from client_email.
4. Grant the owner access Google’s Indexing API prerequisites specify.
5. Save the change, then wait briefly for the permission to register before retrying a failed request.

A Domain property is usually the cleaner choice for a whole domain with multiple protocol or subdomain variations. A URL-prefix property can be appropriate where access must be limited to a particular protocol or section, but the property must actually cover the submitted URL.

If an API call returns a permission-related 403 error, check this before rebuilding code: correct Cloud project, enabled API, exact service-account email, and owner-level permission on the matching Search Console property. Google explicitly identifies adding the service account as a site owner as a prerequisite. (developers.google.com)

Send your first URL_UPDATED request

Once authentication is in place, the core request is small. The publish endpoint is https://indexing.googleapis.com/v3/urlNotifications:publish, and the payload contains the canonical URL plus the notification type.

Here is a compact test request, assuming our code has already created a valid OAuth access token from the service-account JSON key:

curl -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/marketing-manager",
    "type": "URL_UPDATED"
  }'

Use URL_UPDATED when a supported page is new or materially changed. Use URL_DELETED when a supported page has been removed. Do not send a deletion notification simply because a page has a typo or a temporary rendering problem; fix the page, return a stable status, and send URL_UPDATED after the change is live.

Before notifying Google, check these four items:

• The submitted URL is the canonical, publicly accessible HTTPS URL.
• It returns the expected HTTP status, normally 200 for a live page.
• It is not blocked by robots.txt, a noindex tag, login wall, or accidental redirect.
• Eligible pages contain valid JobPosting or BroadcastEvent markup that matches visible page content.

Google’s API usage documentation limits this workflow to updating or removing JobPosting and BroadcastEvent pages. Sending every URL in an XML sitemap through the endpoint is not a compliant substitute for a discovery strategy. (developers.google.com)

Quotas, batches, and realistic indexing speed

Google documents an initial default quota of 200 publish requests per day per project and provides a formal process to request approval and additional quota where justified. Both URL_UPDATED and URL_DELETED notifications consume publish-request capacity, so a job board with 150 new listings and 80 expired listings can exceed the starting allowance in one day. (developers.google.com)

Batching may reduce HTTP overhead in an implementation, but it does not make individual URL notifications free. Plan the workflow around meaningful changes rather than repeatedly resubmitting unchanged URLs.

How fast will Google index the page?

There is no official universal indexing-time promise. The API supplies a fast notification mechanism for supported changing content, but Google still decides whether and when to crawl, process, and index the URL. A successful API response means Google received the notification; it does not prove a search result will appear.

Measure outcomes with Search Console rather than guessing from a site: query. Review URL Inspection for the canonical URL, crawl status, indexing state, and exclusion reasons. Google’s definition of indexing requires Googlebot to visit and analyze the page before it can be stored in the index. (support.google.com)

If we need more than the initial quota, request it through the Cloud project instead of attempting to evade limits by rotating projects, credentials, or accounts. A production request should explain the eligible content type, number of new and changed URLs, and why timely notifications are necessary.

Use XML sitemaps, Search Console, and IndexNow for the right jobs

A solid indexing workflow starts with durable URL discovery. Google recommends sitemaps as a way to provide information that helps it crawl a site more intelligently, particularly for URLs that are not easily discovered through normal crawling. (developers.google.com)

XML sitemap: the default for normal website pages

Put canonical, indexable URLs in an XML sitemap and submit the sitemap in Search Console. For large sites, Google supports sitemap index files; a single sitemap is limited to 50,000 URLs or 50 MB uncompressed, so larger properties should split content across multiple files. (developers.google.com)

Use sitemap <lastmod> values only when they accurately reflect meaningful page changes. A sitemap is a discovery signal, not a guaranteed-crawl schedule.

Search Console Request Indexing: selective manual follow-up

Use the URL Inspection tool’s Request Indexing control for a small number of priority URLs after a correction, migration issue, or major update. It is unsuitable for processing hundreds of pages every day; Google Search Central community guidance consistently directs bulk URL discovery toward sitemaps rather than repeated manual requests. (support.google.com)

IndexNow: notify participating search engines

IndexNow is a separate protocol for notifying participating search engines that a URL was added, updated, or deleted. Its documentation describes URL submission through a hosted key and endpoint-based notifications, which makes it useful alongside sitemap monitoring for engines that support the protocol. (indexnow.org)

This is why we keep the channels distinct: Google’s Indexing API is for its documented eligible content; XML sitemaps support broad Google discovery; and IndexNow is useful for supported non-Google search engines. Our comparison of Google crawl requests, sitemaps, the Indexing API, and IndexNow maps those decisions in more detail.

Troubleshoot a request that did not lead to indexing

Start by separating two outcomes: an API error means authentication, permission, quota, or request formatting failed; a successful notification without indexing means Google received the signal but did not necessarily select the URL for its index.

Check this practical sequence:

1. 403 permission error: Confirm the service account is an owner of the exact Search Console property and that the property covers the submitted URL.
2. 401 authentication error: Regenerate the access token from the correct JSON key, confirm server time is accurate, and make sure the key has not been deleted.
3. 429 or quota error: Review the Indexing API quota page in the selected Cloud project and stop retry loops that resend the same request.
4. URL is not indexed: Inspect noindex, robots access, canonical tags, redirect chains, HTTP status, soft-404 signals, duplicate content, and structured-data eligibility.
5. Wrong page type: Move ordinary pages back to an XML sitemap and internal-linking workflow instead of treating the Indexing API as a shortcut.

For PDFs, the same principle applies: a PDF needs a crawlable, indexable URL and discoverability signals; it is not automatically an Indexing API candidate. We cover that distinction in how to index a PDF in Google: PDF SEO vs. API submission.

Where Indexa fits in a responsible workflow

At Indexa, we built our desktop app around the operational problem many site owners actually have: noticing sitemap changes and notifying the appropriate search-engine endpoints without handing URL data to a recurring third-party SaaS.

For a site with normal pages, Indexa can monitor XML sitemaps for new or updated URLs and automate IndexNow notifications to participating engines. For Google, the workflow should remain honest: eligible JobPosting and BroadcastEvent notifications can use Google’s official API, while ordinary URLs should stay in the sitemap-based discovery process rather than being presented as guaranteed Google submissions.

That separation is useful for agencies managing several domains. We can track which URLs appeared or changed in each sitemap, keep an audit trail of notifications, and avoid reprocessing stale URLs—all from a one-time-purchase local desktop app. It is automation for URL discovery and notification, not a claim that anyone can force Google to index every page.

FAQ

How do I index a website with Google?

Start with crawlable internal links, indexable canonical URLs, and an XML sitemap submitted in Google Search Console. Then use URL Inspection to investigate important pages that remain excluded. Google’s Indexing API is only officially intended for JobPosting and BroadcastEvent pages, so it is not the general indexing route for an entire regular website. (developers.google.com)

Is Google Indexing API free?

Google provides an initial Indexing API quota of 200 publish requests per day per Cloud project. Google’s documentation describes an approval and quota-request process for production needs beyond the initial allowance. The relevant cost is usually implementation and operational effort, not a monthly API subscription fee. (developers.google.com)

How do I set up a Google Indexing API service account and JSON key?

Create and enable an Indexing API Google Cloud project, create a service account, generate a JSON key, and securely store the downloaded file. Then verify the website in Search Console and add the service-account email from the JSON file’s client_email field as an owner of the matching property. (developers.google.com)

Can the Google Indexing API submit any website URL?

No—not as an officially supported use case. Google documents the API for pages containing JobPosting structured data and BroadcastEvent markup in a VideoObject. Normal blog posts, product pages, category pages, and PDFs should generally rely on internal links, XML sitemaps, and selective Search Console inspection instead. (developers.google.com)

Why is Google not indexing my website after an API request?

An API request is a notification, not an indexing guarantee. Check whether the URL is accessible to Googlebot, returns the correct status, is canonical, lacks noindex, has sufficient unique content, and fits the API’s supported content types. Then use Search Console URL Inspection to identify Google’s reported indexing or canonicalization reason. (support.google.com)