Two protocols exist for telling search engines about URL changes directly: Google’s Indexing API and the IndexNow protocol used by Bing, Yandex, and others. Both promise faster indexing. Both are widely misused. The first step in deciding whether to implement either is understanding what each one is actually for.
The promise of direct indexing APIs is real for specific use cases. For job postings, livestream videos, and other time-sensitive content, instant notification can change whether a piece of content gets indexed in time to matter. For general SEO, the same APIs do nothing useful, and using them outside their intended scope can produce problems Google has explicitly warned against.
What the Indexing API is:
Google’s Indexing API is a REST endpoint that lets a website notify Google when specific URLs change. The notification triggers a crawl request, which Googlebot processes faster than it would through normal discovery channels.
Google’s documentation states the scope explicitly: the Indexing API can only be used to crawl pages with either JobPosting structured data or BroadcastEvent embedded in a VideoObject. Job listings and livestream videos. Those two content types, nothing else.
The reasoning is in the use case. Job postings and livestream events are time-critical. A job posted today that gets indexed three days later misses most of its applications. A livestream announced an hour before it starts misses the audience if Google doesn’t index it before the stream begins. Normal crawl timing doesn’t work for these content types, so the Indexing API exists to bypass it.
For everything else, normal crawl timing works fine. Blog posts, product pages, news articles, category pages, About pages: Google’s normal discovery and crawl pipeline handles them within hours to days, which is fast enough for content that doesn’t expire on a specific schedule.
The Indexing API misuse trap:
A pattern recurs across the SEO industry: site owners discover the Indexing API, read the marketing claim that it produces “instant indexing,” and start sending all of their URLs through it. The logic seems sound. Faster indexing should help, the API is there, why not use it.
The problem is that Google’s API enforcement is real. Three things happen when sites use the Indexing API for non-job, non-broadcast content:
- The API still processes the requests. It doesn’t return an error for the wrong content type, which is part of why the misuse pattern is widespread.
- Google’s spam systems detect the misuse. Pages submitted via the Indexing API are checked against the documented scope. Pages without JobPosting or BroadcastEvent structured data flag the misuse pattern.
- Quota gets revoked. Sites that consistently misuse the API have their quota reduced or revoked. The legitimate use case (real job postings) becomes harder to support.
Google’s own documentation states that “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.”
The trap is that the misuse appears to work in the short term. Some pages do get indexed faster after submission. The site owner concludes the API “works” and continues using it. The longer-term effect, including ranking impact and quota revocation, isn’t immediately visible.
What John Mueller and Martin Splitt have said:
Both Google representatives have addressed the misuse pattern directly. John Mueller has stated that the Indexing API is for the documented scope and that submitting other content types doesn’t help indexing. Martin Splitt has emphasized that submitting a URL via the API places it in a priority crawl queue, but Google still decides independently whether to index based on normal quality signals.
The summary: the API accelerates discovery, not inclusion. It tells Google to crawl sooner; it doesn’t tell Google to index.
For the content types where the API is in scope, this distinction is fine. Job postings and livestream events get crawled fast and either get indexed (if they meet quality bars) or not. For content types outside the scope, the distinction means the API does nothing useful: the page would have been crawled eventually anyway, and Google’s indexing decision is unaffected by the submission.
What IndexNow is:
IndexNow is an open protocol for notifying search engines about URL changes. Bing, Yandex, Seznam, and Naver support it. Google does not support IndexNow.
The protocol works by sending a simple HTTP request to a participating search engine endpoint, listing the URLs that have changed. The search engine then crawls the URLs faster than it would through normal discovery.
IndexNow has fewer restrictions than Google’s Indexing API. Any content type can be submitted. The protocol is designed for general URL change notification, not specific schema types.
The trade-off is reach. IndexNow notifies Bing and the other supporting search engines, but doesn’t reach Google, which is the search engine that matters most for most sites. For sites where Bing traffic is meaningful (typically B2B sites in certain industries, Microsoft-centric organizations, regional markets where Bing has higher share), IndexNow is a reasonable addition. For sites where Google is the only meaningful search engine, IndexNow’s value is limited.
Comparison:
| Aspect | Indexing API (Google) | IndexNow (Bing, Yandex, others) |
|---|---|---|
| <strong>Search engines covered</strong> | Google only | Bing, Yandex, Seznam, Naver |
| <strong>Content scope</strong> | JobPosting + BroadcastEvent only | Any content |
| <strong>Authentication</strong> | OAuth, service account | Simple key file |
| <strong>Default quota</strong> | 200 requests/day, increases on approval | Higher limits, less restrictive |
| <strong>Misuse risk</strong> | High; spam detection active | Low; broad acceptance by design |
| <strong>Indexing guarantee</strong> | None; crawl queue priority only | None; crawl queue priority only |
The right tool depends on the content type and search engine target.
When the Indexing API actually helps:
The legitimate use cases:
- Job boards. New listings submitted via the API appear in Google for Jobs within minutes rather than hours. For listings where applications arrive in the first 24-48 hours, the speed difference is meaningful.
- Livestream event sites. New livestream events submitted before the stream begins can appear in Google Search and the Google Live Events surfaces in time to drive viewership.
- Job removal. When a posting expires or fills, submitting URL_DELETED through the API tells Google to deindex faster than the natural process.
The setup is non-trivial: Google Cloud project, service account authentication, JobPosting or BroadcastEvent structured data on every submitted page, sometimes a quota request to Google. For sites with hundreds or thousands of job postings, the setup pays back quickly. For sites with a handful, the manual submission via Search Console is usually enough.
When IndexNow helps:
The legitimate use cases for IndexNow:
- News sites and content publishers where Bing traffic represents meaningful share.
- E-commerce sites with frequent product updates targeting Bing’s audience (often heavier on B2B and certain demographic segments than Google).
- Sites in regions where Yandex or Naver have meaningful market share (Russia, Korea, parts of Eastern Europe).
- Sites where comprehensive indexing across all major search engines matters, even if Bing is a small share, because the implementation cost is low.
The setup is simple: generate a key, host a key file at the site root, send a POST request with the URL list. Most CDN providers and CMS platforms have built-in IndexNow integrations.
What neither tool does:
Both protocols are notification mechanisms. They don’t change the underlying indexing decision; they only change when the crawl happens. The pages still need to:
- Meet quality bars for indexing
- Have proper canonicals, hreflang, and other technical signals
- Not be blocked by robots.txt or noindex
- Pass duplicate content checks
- Have internal links pointing to them
A site with poor content quality won’t suddenly rank because it uses an indexing API. A site with technical SEO problems won’t fix them by notification. The APIs are tools for time-sensitive indexing, not for SEO that should be working through normal channels.
Robots.txt as prerequisite for the APIs:
The notification APIs fail silently when robots.txt blocks the URLs being notified. The pattern that breaks sites:
# WRONG: API notifications for URLs that robots.txt blocks
User-agent: *
Disallow: /jobs/The site submits /jobs/senior-engineer-12345 to the Indexing API. Google receives the notification, attempts to crawl, hits the robots.txt rule, and abandons the crawl. The URL stays unindexed. The API call returns success because the notification was accepted, not because the indexing happened. Misleading.
# RIGHT: allow the URLs the API will notify
User-agent: *
Allow: /jobs/
Disallow: /jobs/admin/
Disallow: /jobs/preview/The same principle applies to IndexNow. Submitting a URL via IndexNow that’s blocked by robots.txt produces a 200 response from the IndexNow endpoint but no indexing. Sites that monitor API success rates without monitoring indexation rates miss this failure mode entirely.
Verify with Search Console URL Inspection after API submission. The Live URL test shows whether Google can fetch the URL; if the test reports “blocked by robots.txt”, the API notification is wasted regardless of how many were submitted.
Implementation patterns for the Indexing API:
For sites with eligible content (JobPosting or BroadcastEvent), the implementation has a few standard patterns. Google’s documentation provides the full API specification; the integration logic is straightforward.
The notification flow:
- Content event occurs (new job posting published, broadcast scheduled).
- The site’s backend triggers a
URL_UPDATEDorURL_DELETEDnotification to the Indexing API. - Google receives the notification and queues the URL for priority crawling.
- Crawl typically happens within hours; indexation follows normal pipeline timing.
The authentication is service-account-based: a Google Cloud project, a service account with Indexing API permissions, the service account verified as an owner of the site in Search Console. Requests use OAuth 2.0 with the service account credentials.
Common implementation issues:
- Rate limits. The Indexing API has a default quota of 200 requests per day, with higher quotas available on request for verified high-volume use cases. Sites that submit speculative URLs (everything published, not just time-sensitive content) hit quota limits quickly and miss notifications that would have mattered.
- Authentication scope errors. The service account needs ownership of the verified Search Console property for the domain being notified. Cross-domain authentication issues are the most common implementation failure.
- URL validation. The submitted URLs need to be reachable and return 200 (or appropriate status codes). Submitting URLs that 404 or redirect produces errors and consumes quota.
Implementation patterns for IndexNow:
IndexNow is simpler than the Indexing API. The flow:
- Site generates a key file at
https://example.com/[your-key].txtcontaining the key. - Site’s backend sends a POST request to one of the supporting search engines (
https://www.bing.com/indexnow,https://yandex.com/indexnow, etc.) with the URLs to notify and the key. - Each search engine that supports IndexNow processes the notification and queues the URL for crawl.
The key file proves ownership; the URL submission triggers the notification. The protocol is shared, so submitting to any IndexNow-supporting endpoint propagates to all of them. Bing and Yandex are the major endpoints in 2026; Seznam, Naver, and a few others also participate.
Most major CMS platforms have IndexNow plugins (WordPress: IndexNow plugin official from Bing; Wix: built-in; Cloudflare: automatic for sites using Cloudflare). The implementation cost for these platforms is configuration, not code.
Monitoring whether the APIs are actually helping:
Implementation is the first step; verifying that the notification produced faster indexing is the second. Most sites skip the verification, which is why misuse persists.
The verification pattern:
- Compare time-to-index for notified URLs vs unnotified URLs. Pick a sample of similar URLs; notify half, leave half alone. Measure days until each appears in Search Console as indexed. A statistically meaningful difference confirms the notification is producing benefit; no difference suggests the notification isn’t necessary for the site’s normal indexing pace.
- Track quota usage and error rates. Search Console shows Indexing API quota usage and any errors returned. Quota exhaustion or persistent errors indicate the implementation isn’t working as designed.
- Monitor crawl rate after notification. Server logs show whether Googlebot’s crawl rate for notified URLs increases. The pattern that suggests effective notification: crawl within hours of submission, distinct from the site’s normal crawl rate.
Sites that monitor these metrics typically find that the Indexing API helps for eligible content (the documented scope: JobPosting, BroadcastEvent) and doesn’t help meaningfully for ineligible content (everything else). The verification confirms what Google’s documentation already says, but with site-specific data.
Narrow scope, broad misunderstanding:
The Indexing API has a narrow legitimate scope. For sites in that scope, it’s standard infrastructure. For sites outside that scope, it’s not a useful tool, and the marketing claims around “instant indexing” for general SEO usage are misleading.
IndexNow has broader scope but limited reach without Google support. For sites that care about Bing and other search engines, it’s worth implementing. For Google-only sites, it’s optional.
The misuse trap is real and worth avoiding. The first question before implementing either tool is: does the site’s content match the protocol’s actual purpose? If not, the time spent on implementation is better spent on the fundamentals that drive crawling and indexing through normal channels: content quality, internal linking, sitemap accuracy, server performance.
The fundamentals work. They’re slower than instant notification for the narrow cases where instant notification matters, but for everything else, they produce the same outcome with less risk.
The seductive promise of instant indexing turns out to be irrelevant for most of the situations that prompted it. A site that doesn’t get crawled fast enough has crawling problems; faster notification doesn’t fix slow crawling. A site whose new pages don’t rank has ranking problems; faster indexing doesn’t fix poor pages. The APIs do one thing well, for one type of content; everything else is a category error dressed up as a tool selection question.