IndexNow Rate Limits by Search Engine

This guide is for site owners, developers and SEO leads who work with indexnow rate limits and need a reliable routine without guesswork. Many teams hit the same wall: submissions return mixed codes, logs are thin, and regional or automated coverage moves slowly while stakeholders ask for dates. The facts matter here. IndexNow is an open protocol co developed by Microsoft Bing and Yandex, Google does not support IndexNow, and one request can carry up to 10000 URLs with a key file at the site root for verification. You will learn exact checks, safe pacing, logging that proves what happened, and recovery steps that work in production. Follow the sections in order, test with a handful of URLs first, then scale once responses stay clean.

Intro scope: this article focuses on practical IndexNow operation for production sites. It assumes a live https host, access to server logs, and the ability to host a plain text file at the site root. It does not promise rankings or instant inclusion, because engines still decide crawl and index eligibility after a successful ping.

Key takeaways

What rate limits mean in IndexNow starts with key file health and host pure batches, not with faster retries.
How Bing handles IndexNow load works best with one test URL and full logs before bulk batches.
IndexNow is co developed by Bing and Yandex, Google does not support it, and one request can carry up to 10000 URLs.
Deduplicate, filter to changed canonical URLs, then queue at a fixed pace with backoff on 429.

What indexnow rate limits mean for submissions
How Bing handles IndexNow load
How Yandex handles IndexNow load
Naver Seznam and smaller engines what to expect
429 and 422 reading engine feedback correctly
Batch sizing and pacing that avoids blocks
Queue design for steady submissions
Priority rules when volume exceeds comfort
Monitoring submission rate and engine fetch
Recovery after over submission
Checklist to stay polite at scale
FAQ
Sources
Further reading

Indexnow rate limits gauges and per engine quota bars on dark

What indexnow rate limits mean for submissions

This section covers what rate limits mean in indexnow in the context of indexnow rate limits. Rate limits in IndexNow are politeness controls that protect engines from bursts, not fixed daily numbers published for every partner. Engines expect honest pings for URLs that actually changed, with reasonable pacing and deduplication. A burst of full sitemap dumps looks abusive even when each request is technically valid. Treat limits as trust guidance: send less, more accurately, with pauses, and engines will fetch more reliably. Watch indexnow quota signals, tune indexnow frequency to real changes, use indexnow throttle logic in the worker, and review indexnow usage limits weekly. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

IndexNow is a simple notification protocol co developed by Microsoft Bing and Yandex. When you create, update or delete a page, your site sends an HTTP request with the list of affected URLs plus a key that proves ownership. Participating engines can then prioritize those URLs for recrawling. The protocol does not upload content, does not guarantee indexing, and does not change quality evaluation. It shortens discovery time so good pages can be evaluated sooner with less waiting.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

Google does not support IndexNow, so plan for two ecosystems from the start. IndexNow notifies Bing, Yandex, Naver, Seznam and other partners that share the protocol, while Google relies on sitemaps, Search Console inspection and the Indexing API for JobPosting and BroadcastEvent pages only. A practical setup prepares one URL list at publish time, then branches to IndexNow batches plus Google sitemap coverage. Coverage improves without double counting or false expectations.

Server logs prove whether IndexNow prompts faster fetches. Record submission time, endpoint, host, URL count and response code for every batch, then watch for engine fetches of the key file and notified URLs. Compare submitted URLs against an unsubmitted control group from the same template to measure delay honestly. If fetch quickens but index state does not change, the constraint is content or eligibility rather than discovery. Evidence beats assumptions in every review.

In practice, create a short runbook for what rate limits mean in indexnow and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

How Bing handles IndexNow load

This section covers how bing handles indexnow load in the context of indexnow rate limits. Bing documents IndexNow submission and webmaster tooling with the clearest guidance for Western sites. It accepts single and batch POSTs, validates key plus host plus URLs, and returns success or client error codes quickly. Heavy bursts can still trigger throttling with retry guidance, so pace batches to a few hundred URLs with short pauses. Monitor Bing Webmaster submission reports and server log fetches together to tune pace. Track indexnow submissions per day, respect the practical indexnow daily limit for your host, and compare engine quotas across partners before raising volume. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Ownership in IndexNow is proven by a key text file hosted at the site root. The file name is your key plus .txt and its content is the key string itself. Engines fetch that URL during verification and compare it with the key in your submission. If the file is missing, returns 404, wraps content in HTML, or blocks anonymous fetch, verification fails with client errors. Keep the file plain text, publicly reachable, and stable across deploys and redesigns.

Step 1: Confirm host, key, keyLocation and endpoint in server config.
Step 2: Validate JSON shape locally against the official docs before sending.
Step 3: Deduplicate URLs and split by host so each request stays host pure.
Step 4: Send at a fixed pace, handle 429 with backoff and 403 with pause for review.
Step 5: Review fetch logs daily and record submit to fetch delay per URL group.

One IndexNow POST can carry up to 10000 URLs in urlList, but polite batches of a few hundred with pauses work better for steady trust. Deduplicate before sending, keep requests host pure with absolute https URLs on one host, and split larger backlogs across requests with delays. Reject invalid entries at queue entry with a logged skip reason so one bad URL never fails a batch of good ones. Honest change only signals beat full sitemap dumps sent daily.

Crawl health still decides whether a notified URL qualifies for the index. Keep response times low, avoid redirect chains, return clear status codes, and allow anonymous GET for important resources. Use canonical tags to consolidate variants, hreflang for translated pages, and robots rules that block only low value paths such as facets and internal search. When the crawler can fetch quickly without loops, each IndexNow hint carries more weight.

In practice, create a short runbook for how bing handles indexnow load and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

For background on the protocol, see IndexNow complete guide which explains endpoints, keys and fanout across participating engines.

Diagram showing indexnow rate limits flow with key file, queue and engine fanout

How Yandex handles IndexNow load

This section covers how yandex handles indexnow load in the context of indexnow rate limits. Yandex co developed the protocol and processes IndexNow as part of its crawling signals, with its own webmaster guidance for verification and limits. Keep the same key file discipline and host pure batches as with Bing, and allow for regional network timing in fetch delays. Avoid resubmitting unchanged URLs daily, since repeated noise reduces trust. Steady, accurate batches earn faster revisits than large infrequent blasts. Treat indexnow too many requests and indexnow 429 as pacing feedback, and respect indexnow engine limits for each partner. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Response codes tell you exactly what to do next. Codes 200 and 202 mean accepted so you mark the batch done. Code 400 means malformed JSON so you fix shape locally. Code 403 means key or ownership failed so you verify the key file and host. Code 422 means invalid URLs so you clean the list. Code 429 means slow down so you back off with delay. Log code plus URL count plus response snippet for every send to make weekly triage fast.

Internal linking helps IndexNow driven crawlers find changes fast after the ping. New URLs that sit four clicks from the home page may wait longer for a visit, while URLs linked from popular categories or recent posts blocks get visited quickly. Add new pages to relevant hubs, link related items, and keep pagination crawlable with plain anchors. Avoid loading key links only through scripts that require clicks. Simple stable links support both human visitors and engine crawlers.

In practice, create a short runbook for how yandex handles indexnow load and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

For official details, see IndexNow documentation which defines fields, key handling and batch rules.

Naver Seznam and smaller engines what to expect

This section covers naver seznam and smaller engines what to expect in the context of indexnow rate limits. Naver, Seznam and other partners listed on the official page share the protocol but publish less detailed quota text, so operate conservatively. Use small batches, longer pauses and strict change only filtering. These engines allocate less crawl per small foreign site, which means clean signals matter more. One accurate ping per real change beats ten repeated pings for the same URL. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Bing Webmaster Tools gives the clearest reporting for IndexNow among Western engines, with submission views and crawl data to pair with your own logs. Yandex Webmaster provides its own verification and diagnostics for its index. Naver and Seznam publish less detailed quota text, so operate conservatively with small batches and strict change only filtering. Always re check the current participants page on the official site during planning rather than trusting a stale screenshot.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

Robots directives and meta tags can silently block indexing even after successful submission. A stray noindex in a template, an X Robots Tag header from a staging config, or a disallow that covers new paths will keep pages out. Audit headers with a fetch tool, render pages as a crawler sees them, and check webmaster coverage for excluded reasons. Fix the template once rather than patching URLs one by one. Clean permissions make each accepted ping useful.

In practice, create a short runbook for naver seznam and smaller engines what to expect and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

To compare coverage and limits, read IndexNow bulk 10000 URL rule before you commit time to one route.

429 and 422 reading engine feedback correctly

This section covers 429 and 422 reading engine feedback correctly in the context of indexnow rate limits. A 429 asks you to slow down and retry later with backoff, while 422 says URLs in the list were invalid and need cleaning rather than retrying as is. A 400 points to malformed JSON shape, and 403 points to key or host mismatch. Log code plus count plus snippet for every batch, then route each code to its fix. Correct routing prevents hammering engines with retries that can never succeed. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Step 1: Export changed URLs from CMS or build manifest with last change dates.
Step 2: Keep only canonical 200 URLs on one host, drop drafts, 404s and noindex pages.
Step 3: Confirm key file GET returns 200 with exact body from outside the network.
Step 4: Send a single test URL, confirm success code, check logs for engine fetch.
Step 5: Queue remaining URLs in small batches with pauses, log every response.

Thin or duplicated content slows indexing because engines prioritize pages likely to satisfy searchers. Short descriptions copied from suppliers, empty category pages and near duplicate articles often wait longer for inclusion. Add specific details such as dimensions, materials, compatibility, usage steps and original photos. Consolidate near duplicates into one strong page with redirects. Better content earns more frequent revisits and steadier indexing after discovery.

In practice, create a short runbook for 429 and 422 reading engine feedback correctly and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

import time, random
def indexnow_backoff(attempt, retry_after=None):
    if retry_after:
        time.sleep(float(retry_after) + 1)
        return
    time.sleep(min(2 ** attempt, 60) + random.uniform(0, 1))
# on 429 call indexnow_backoff(n), cap at 5 tries then delay queue row

Batch sizing and pacing that avoids blocks

This section covers batch sizing and pacing that avoids blocks in the context of indexnow rate limits. A practical default is a few hundred URLs per POST with 30 to 60 seconds between batches during normal operation, and slower during backfills. Split 10000 URL capacity across many requests rather than filling it every time. Deduplicate across CMS events so one edit does not queue five pings for the same URL. Calm, even pacing keeps success codes steady and logs easy to read. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Security for IndexNow stays simple because auth uses a key file rather than JWTs, but hygiene still matters. Keep the submitter config private on the server, never embed keys in browser JavaScript, and store host plus key plus endpoint outside the web root or in platform secrets. Serve the key text file at the root as plain text for engines while keeping submitter secrets separate. Rotate with overlap by hosting old and new files briefly during switches.

In practice, create a short runbook for batch sizing and pacing that avoids blocks and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

Workflow showing indexnow rate limits handling with paced queue and logging

Queue design for steady submissions

This section covers queue design for steady submissions in the context of indexnow rate limits. Use a durable queue with URL, host, change time, attempts and next retry timestamp, plus a single worker that sends at a fixed interval. On 429, push next retry forward with exponential backoff and jitter. On 403, pause for review instead of looping. On 422, mark rows as needs fix with a reason. Fixed concurrency of one plus visible backlog age keeps volume polite without manual throttles. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

Automation works best with a queue between publish events and engine endpoints. Hooks in the CMS or deploy pipeline insert rows in milliseconds while a single worker sends at a fixed pace such as one batch per minute. Filter to changed canonical indexable URLs only, dropping drafts, previews, archives and staging domains. Fixed pacing plus retry timestamps absorbs import spikes, prevents limit storms, and keeps logs readable during launches.

In practice, create a short runbook for queue design for steady submissions and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

When errors persist, review IndexNow response codes explained to isolate key, shape and pacing causes with logs.

Priority rules when volume exceeds comfort

This section covers priority rules when volume exceeds comfort in the context of indexnow rate limits. When publishes spike, serve new pages and meaningful updates first, then price and availability changes, then evergreen refreshes. Defer archives, tag pages and faceted variants to sitemap discovery until the queue drains. Score by age, change size and business value, then sort the worker pull order by that score. Explicit priority keeps important URLs moving when total volume is high. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Measurement should separate discovery speed from ranking movement. IndexNow speeds the first step from change to engine fetch, but ranking still depends on relevance, quality and competition. Track submit to fetch delay in logs, fetch to index state in webmaster tools, and index to visit in analytics as three separate intervals. When stakeholders ask about value, report each interval with dates rather than promising position gains that the protocol never claims.

Step 1: Confirm host, key, keyLocation and endpoint in server config.
Step 2: Validate JSON shape locally against the official docs before sending.
Step 3: Deduplicate URLs and split by host so each request stays host pure.
Step 4: Send at a fixed pace, handle 429 with backoff and 403 with pause for review.
Step 5: Review fetch logs daily and record submit to fetch delay per URL group.

In practice, create a short runbook for priority rules when volume exceeds comfort and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

import time, random
def indexnow_backoff(attempt, retry_after=None):
    if retry_after:
        time.sleep(float(retry_after) + 1)
        return
    time.sleep(min(2 ** attempt, 60) + random.uniform(0, 1))
# on 429 call indexnow_backoff(n), cap at 5 tries then delay queue row

Monitoring submission rate and engine fetch

This section covers monitoring submission rate and engine fetch in the context of indexnow rate limits. Track sends per hour, success rate by code, queue age, and bot fetch delay from submission to first engine visit. Chart submits versus fetches to see whether pacing or site health is the constraint. Alert when 429 rate rises or queue age passes one hour. Evidence based tuning beats guessing, and small pace changes show up clearly within a day. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Sitemaps remain the backbone of discovery even with IndexNow in place. A clean XML sitemap lists only canonical indexable URLs that return 200 and load quickly. Split large catalogs into chunks, compress with gzip, and reference each chunk from a sitemap index. Update lastmod only when content truly changes. Submit the index in Bing Webmaster Tools and keep it reachable. A tidy sitemap reduces wasted fetches and leaves room for priority pages to be visited sooner.

In practice, create a short runbook for monitoring submission rate and engine fetch and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

For engine side guidance, see Bing Webmaster help which covers submission, quotas and reporting.

Recovery after over submission

This section covers recovery after over submission in the context of indexnow rate limits. If throttling starts, pause new sends, keep order in the queue, and revalidate the backlog by dropping 404, noindex and non canonical entries. Resume at half pace after a cool down, then ramp only after an hour of clean success codes. Document cause, counts and the new pacing rule so the next import does not repeat the burst. Calm recovery restores trust faster than rapid retries. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Item	What to record	Where to check
Request	URL plus host	Worker log row
Key	Fingerprint plus location	Root file GET
Response	Status plus snippet	Engine reply body
Follow up	Next retry time	Queue next run field

In practice, create a short runbook for recovery after over submission and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

Checklist to stay polite at scale

This section covers checklist to stay polite at scale in the context of indexnow rate limits. Keep a one page routine: change only filtering, deduplication, a few hundred per batch, pauses between batches, backoff on 429, pause on 403, daily error review and weekly fetch delay check. Assign one owner for pacing and one for key health. Test pacing on staging before each large import. Short, repeated checks prevent most limit incidents before they start. We keep the advice practical for owners without a large SEO team. Each step below uses plain checks you can run with webmaster tools, server logs and a small script. The goal is steady progress you can measure in fetch reports, not a one time spike. Keep notes on what you change and when, so you can link movement to specific fixes.

Step 1: Export changed URLs from CMS or build manifest with last change dates.
Step 2: Keep only canonical 200 URLs on one host, drop drafts, 404s and noindex pages.
Step 3: Confirm key file GET returns 200 with exact body from outside the network.
Step 4: Send a single test URL, confirm success code, check logs for engine fetch.
Step 5: Queue remaining URLs in small batches with pauses, log every response.

In practice, create a short runbook for checklist to stay polite at scale and review it after each deploy. List who owns the key file, where logs live, what alert fires first, and what pace the worker uses. Test with five URLs before scaling to hourly batches. Record every response code and timestamp so patterns appear without guesswork. If errors rise, pause automation, fix the root cause, then resume at half pace. Steady documented pacing restores submissions faster than rushing to catch up in one burst.

FAQ

Is there a fixed daily IndexNow quota?

No single public number covers all partners. Engines expect reasonable change only volume with pacing. Operate with small batches, pauses and deduplication rather than chasing a fixed cap. Track indexnow quota use, watch indexnow submissions per day, and compare engine quotas before raising volume. Test with five URLs before scaling to hourly batches for safety. Steady documented pacing restores trust faster than rushing. Keep a short log of what you checked and when, so the next review starts from evidence.

What should I do on 429?

Pause, keep the queue order, and retry with backoff after a cool down. Resume slower and investigate what burst caused the block. Never retry immediately in a tight loop. Treat indexnow too many requests and indexnow 429 as the same pacing signal and apply indexnow throttle logic with jitter. Record every response code and timestamp for review daily. Steady documented pacing restores trust faster than rushing. Keep a short log of what you checked and when, so reviews start from evidence.

How many URLs per IndexNow request?

Up to 10000 is allowed, but a few hundred with pauses is safer for trust and debugging. Split large backlogs across requests and days. A practical indexnow daily limit is a few hundred changed URLs per host per day for most small sites. Deduplicate daily and keep host pure always. Steady documented pacing restores trust faster than rushing to catch up. Keep a short log of what you checked and when, so the next review starts from evidence and stays simple.

Does IndexNow affect Google quota?

No. Google does not support IndexNow, so IndexNow pacing is separate from Google Indexing API quota. Manage the two ecosystems with separate queues and alerts for clarity and ownership. Indexnow usage limits never affect Google quota, and Google quota never affects IndexNow sends. Plan two tracks from the start to avoid confusion across teams and stakeholders. Steady documented pacing keeps both tracks calm and readable. Keep a short log of what you checked and when, so reviews start from evidence.

Should low value URLs use IndexNow?

No. Reserve pings for new and meaningfully changed canonicals. Leave archives and variants to sitemaps for discovery. Priority rules protect important URLs when volume spikes and queues grow long. Respect indexnow engine limits and tune indexnow frequency to real edits rather than schedules. Document priority scores clearly for the team each month without fail. Test with five URLs before scaling to hourly batches for safety. Keep a short log of what you checked and when, so reviews start from evidence.

How do I know pacing works?

Watch success rate by code, queue age and submit to fetch delay in logs daily. Steady success plus short fetch delays means pacing fits well for your host. Rising 429 means slow down and extend pauses between batches calmly. Track indexnow frequency weekly and review indexnow usage limits against fetch uplift honestly. Compare submitted versus control groups monthly for proof of value. Test with five URLs before scaling to hourly batches for safety. Keep a short log of what you checked and when.

Sources

https://www.indexnow.org/documentation
https://www.bing.com/webmasters/help
https://yandex.com/support/webmaster/robot-workings/indexnow.html

IndexNow Rate Limits and Quotas by Search Engine