The Google Indexing API lets a site tell Google that a URL was added, updated or removed, and Google officially supports it only for pages carrying JobPosting or BroadcastEvent structured data. The hard limit is 200 publish requests per day per Google Cloud project, not per website, so every site that shares a project and service account draws down the same pool, and once it is gone every further call returns HTTP 429 until the daily reset. This guide covers what the API actually does, how to set it up, how the quota behaves across a portfolio, and which other indexing tools to use when the API is the wrong one.
One definition to anchor the rest: the Indexing API is a Google Cloud service that accepts a URL plus a notification type, URL_UPDATED or URL_DELETED, from an authorized service account and queues that URL for Googlebot to fetch. It does not index the page. It does not guarantee a crawl. It asks.
What the Indexing API is actually for.
Google's documentation is narrow on purpose. The API exists so job boards and live-stream publishers can get short-lived pages in and out of the index quickly, because a job listing that closed yesterday is worse than useless in results. Those two schema types, JobPosting and BroadcastEvent, are the only ones Google says it supports, and the documentation states that other content types are not supported.
In practice many sites, including many we run, send ordinary article and product URLs through it, and what happens is this: the request is accepted, Googlebot usually shows up within hours to a couple of days, and the page is then evaluated like any other page. Whether it gets indexed depends on the same quality and demand signals it would face if Google had found it through a sitemap. The API buys a crawl, not a ranking, and on unsupported page types it does not even promise the crawl.
We treat it as an accelerant for pages already worth indexing: a new service page with real depth, a rewritten post, a URL whose canonical changed during a migration. It is not a fix for pages Google has looked at and declined to keep.
The quota is per project, not per site.
The default quota is 200 publish requests per day, and the unit that owns it is the Google Cloud project, not the domain or the Search Console property. One project can hold a service account that is an Owner on twenty properties, and all twenty share the same 200. Nothing in the API response tells you which site spent it; the count is simply gone.
This is where portfolio operators get burned. The failure pattern looks like this: a morning cron job on site A pushes 120 URLs from a fresh sitemap, a content deploy on site B pushes 80 more at lunch, and the manual push you try on site C at three in the afternoon returns 429 RESOURCE_EXHAUSTED on the very first URL. Repeat that for a week and site C never gets a single request through while its task log reports the pings as sent.
Two rules follow. First, one project per site, or at least per group of sites you are willing to have share a budget; projects and service accounts are free. Second, log the response code of every call. A 200 with the URL echoed back means the request was accepted; a 429 means the day is over for that project and retries only burn time. Google does let you request a higher quota through the Cloud console, but it evaluates requests against the intended job and broadcast use, so do not build a pipeline that assumes an increase will arrive.
The batch endpoint, which accepts up to 100 notifications in one HTTP request, does not change the math. Each notification inside the batch counts against the same daily limit.
Exact canonical URL or nothing.
The URL you send must match the canonical exactly as Google understands it: the same host (www or bare), the same scheme, the same trailing slash policy, and no tracking parameters. We have watched task runners ping a path with a trailing slash for weeks while the page canonicalized to the version without it. Every one of those calls was accepted, counted, and pointed at a URL Google treats as a different address that redirects. The page never moved.
Before any URL enters the queue, resolve it: fetch it, follow redirects, read the rel=canonical in the final response, and send that exact string. If the canonical and the requested URL differ, fix the site, not the API call. Right after a migration, when hosts and paths have just changed, the migration checklist covers the redirect and canonical work that has to land first.
How to set up the Indexing API.
What the URL Inspection API does instead.
The URL Inspection API is a different Search Console API with a different job. It returns the same data you see when you paste a URL into the Inspect box: the verdict, the coverage state, the last crawl time, the Google-selected canonical next to the user-declared one, and any referring URLs Google knows about. Its quota is 2,000 calls per day per property and 600 per minute, and it is read only. It does not request indexing. The Request Indexing button in the Search Console interface has no API equivalent.
We run it as the sensor and the Indexing API as the actuator. Inspect first, act second, and act only on URLs whose state justifies it: a fresh page with no crawl, a page whose crawl predates a rewrite, or a page where the canonical Google picked is not the one you declared.
IndexNow, sitemaps and the durable path.
IndexNow is a shared protocol that Bing, Yandex and several other engines accept; one ping to any participating endpoint fans out to all of them. Google does not participate. A task log that reports IndexNow submissions as done can hide a Google indexing problem for months.
The durable path is boring: an accurate XML sitemap listed in Search Console and referenced in robots.txt, lastmod dates that change only when the page changes, and internal links from pages Google already crawls to the pages you want it to find. Every indexing gain we have been able to attribute across our sites came from that path, with the API acting as a timing nudge on top. When the sitemap is stale, or the new pages hang off a hub that links to only a fraction of them, the API is shouting into a room Google is not in. The plumbing has to be right before any submission tool matters, which is where our SEO service starts.
| Tool | What it does | Limit | When to use it |
|---|---|---|---|
| Indexing API | Asks Google to crawl a URL you added, updated or removed | 200 publish requests per day per Cloud project, shared by every site on that project | JobPosting and BroadcastEvent pages officially; a timing nudge on other pages you have already made worth indexing |
| URL Inspection API | Reads index status, canonical, last crawl time and referring URLs for one URL | 2,000 calls per day per property, 600 per minute, read only | Auditing which pages are indexed and why before deciding what to push |
| IndexNow | Notifies Bing, Yandex and other participating engines that URLs changed | Generous per key; Google does not accept it at all | Getting non-Google engines updated quickly after publishing or removing pages |
| XML sitemaps | Lists every canonical URL with a lastmod date so crawlers can discover them | 50,000 URLs or 50 MB per file, with an index file above that | Always; this is the baseline every other tool assumes is in place |
| Manual request in Search Console | Requests a crawl for one URL through the URL Inspection tool | A small daily cap per property, no API equivalent | A handful of urgent URLs after a fix, a launch or a canonical change |
“The API buys a crawl, not a ranking. Everything after the crawl is the page's own problem.”
When unknown to Google means discovery, not the API.
Search Console reports a URL as unknown to Google when it has never been crawled or discovered. If a page sits in that state for weeks, the last crawl time stays empty, and the page has been pushed through the API more than once, the API is not the bottleneck. Google has nothing that points at the page, so it has no reason to prioritize the fetch. The fix is discovery: a link from an indexed hub, a link from a related post that already gets traffic, a mention on another site.
We have seen brand-new sites where the homepage was the only indexed page for weeks, every other URL sat unknown with no crawl, and the API returned 429 every morning because a sibling site on the same project had spent the quota first. Separating the projects fixed the 429. Adding real links fixed the indexing. Those are two different problems, and both were present at once.
Mistakes that waste the quota.
- Sharing one Cloud project across a portfolio, so the first site to run its cron wins and every later site sees 429 for the rest of the day.
- Pinging the wrong URL form: a trailing slash, http instead of https, or a bare host that redirects to www.
- Treating a 200 response as indexed. It means accepted and nothing more; only URL Inspection tells you what happened next.
- Re-sending the same unchanged URLs every day, which spends quota on pages Google already crawled and chose not to keep.
- Pinging IndexNow and reporting it as a Google submission; Google does not read IndexNow.
- Pushing pages the site itself does not link to, then blaming the API when they sit unknown to Google for a month.
Is the Google Indexing API only for job postings?
Officially yes. Google documents support for pages with JobPosting or BroadcastEvent structured data and states that other content types are not supported. Many sites use it for ordinary URLs and often see a crawl follow, but there is no guarantee, and quota increase requests are judged against the intended use. Treat it as a nudge for pages you have already made worth indexing.
Why does the Indexing API return 429 on the first request of the day?
Because the 200 per day quota belongs to the Google Cloud project, not to the site. If any other site or job uses the same project, it can spend the whole allowance before your call runs. Give each site its own project and service account, log every response code, and find the spender before requesting more quota from Google.
Does IndexNow get pages indexed in Google?
No. IndexNow is accepted by Bing, Yandex and several other engines, and one ping reaches all of them, but Google does not participate. For Google, the levers are an accurate sitemap, internal links, the Indexing API within its limits, and the manual request in Search Console. Report IndexNow pings as non-Google submissions so nobody mistakes them for progress.
How long does the Indexing API take to work?
When Google acts on a request, the crawl usually follows within hours to a few days, and you can confirm it by checking the last crawl time through URL Inspection. If weeks pass with no crawl and the page still shows as unknown to Google, the request was never the problem; the page has no links pointing to it and needs discovery, not another ping.