What is IndexNow and who supports it?

An open protocol for instantly notifying search engines about changed URLs: you put a text key in the site root and POST a list of URLs to api.indexnow.org. Supported by Bing and Yandex (plus Seznam, Naver). Google does not support IndexNow - the protocol tells it nothing. One ping propagates to all protocol participants.

Does IndexNow guarantee indexing?

No. It's a signal 'the page changed, come look' - the search engine decides whether to come and whether to include the page in the index. My example: pings went out with code 200 all May, and on June 22 Bing had 1-3 of 77 pages in its index with zero crawl errors. Bing saw everything - and didn't index. Only a direct SubmitUrlBatch of all 77 URLs helped; three days later the index grew to 26-29 pages.

How do I speed up recrawl in Google?

Two working channels. First - the sitemap: Google picked up my fresh articles within a day without any pings. Second - manual Request Indexing in Search Console, roughly 10 URLs a day, reaction from a few hours to three days. The Indexing API officially isn't meant for regular pages (only job postings and livestreams): in my test it answered 200 on submission but returned no metadata - nothing to confirm an actual recrawl with.

What are the quotas of the recrawl tools?

From my experience, per site: Yandex Webmaster - 150 URLs a day for recrawl via API or the interface; Bing SubmitUrlBatch - 100 URLs a day; Google Request Indexing in GSC - about 10 URLs a day. IndexNow showed no formal quotas at these volumes. For a 77-page site any of these limits has plenty of headroom.

Why does IndexNow return 503 or 502?

The api.indexnow.org endpoint lives on Bing's side and sometimes goes down itself. On May 29 my deploy ping got a 503, the retry - a 502, a manual retry later - 503 again. Two days later everything was back to 200 with no action on my part. Takeaway for automation: build in retries with pauses and don't fail the deploy over an unavailable ping - it's a non-critical step.

Why speed up recrawl at all?

Two reasons. First - fixes should reach the search results faster: you rewrite a title for CTR, and the search engine keeps the old snippet for weeks. Second - AI search: Copilot pulls answers from the Bing index, and while a page isn't there, you don't exist in the answers either. My cleaning project got 40 citations in Copilot exactly after I sorted out the Bing index - covered in a separate article about GEO.

IndexNow, GSC and Yandex: What Actually Speeds Up Recrawl

Writing about IndexNow tends to be either ‘plug it in and search engines learn about changes instantly’ or nothing. I ran it on a live site for a month alongside the other recrawl tools - the Yandex Webmaster API, Bing submissions, manual Request Indexing in Google - and put together an honest picture: what actually moves indexing and what just blinks a pleasant 200.

In brief

IndexNow pings fire automatically after every deploy - free and cheap, plug it in.

But a ping ≠ indexing: Bing accepted pings and kept 1-3 of 77 pages in its index.

The IndexNow endpoint itself goes down: May 29 - 503 and 502 on retries, two days later - 200 again.

Yandex: the working lever is recrawl via the Webmaster API, 150 URLs/day, processed within hours.

Bing: SubmitUrlBatch, 100 URLs/day - that’s what pulled the index from 1-3 to 26-29 pages.

Google: sitemap + manual Request Indexing (~10 URLs/day). The Indexing API for regular pages - unconfirmable.

How my auto-ping is set up

The site is static on Astro, deployed via GitHub Actions: push to main, files are on the hosting in 1-2 minutes. Then a separate workflow collects the list of changed URLs and sends a POST to api.indexnow.org with a key that sits as a text file in the site root. One ping propagates to all search engines in the protocol - for me that’s Bing and Yandex.

Two details that only surfaced in practice:

Retries are mandatory. The workflow has retries on 503/504/429 with pauses. Came in handy sooner than expected.

A ping must not fail the deploy. If IndexNow is unavailable - the workflow logs a warning and finishes successfully. An undelivered ping is a non-critical loss: the search engine will come via the sitemap anyway, just later.

Chronicle of one month of pings

Actual endpoint responses from the deploy logs:

Date	Event	Response
May 28	Deploy, auto-ping	200, accepted
May 29	Deploy, auto-ping	503, retry - 502
May 29	Manual retry later	503/502 again
May 31	Deploy, auto-ping	200
June 1	Manual ping, 5 URLs	200

On May 29 the endpoint was down on Bing’s side - my infrastructure was fine. Two days later it came back on its own. If the deploy failed because of the ping, I wouldn’t have shipped a single fix on May 29.

The conclusion from the table is boring but important: IndexNow is a cheap postcard, not registered mail. Sending guarantees nothing, non-delivery breaks nothing.

Bing: accepts pings, doesn’t owe you indexing

The most telling story of the month. On June 22 I check Bing Webmaster Tools: 1-3 pages in the index out of 77 in the sitemap. Meanwhile zero crawl errors - no 4xx or 5xx, the crawler visits, pings went out with code 200 all month. Bing saw everything. And didn’t index.

Why this hurts is a separate topic: Copilot assembles answers from the Bing index, and while your site isn’t there, you don’t exist for Microsoft’s AI search. On my cleaning project it was the Bing index that produced 40 citations in Copilot - so I noticed the failure fast.

What I did: via the Bing Webmaster API I sent a SubmitFeed (sitemap resubmission) and a SubmitUrlBatch of all 77 URLs - both requests accepted with code 200. The URL submission quota is 100 a day; after the batch 23 remained.

Three days later, on June 25, the index grew to 26-29 pages. Not all 77, but from 1-3 that’s the difference between ‘the site doesn’t exist’ and ‘the site exists’. Bing filled in the rest on its own.

The moral: for Bing, a direct submission via the Webmaster API is a stronger signal than an IndexNow ping. Keep both: the ping as background routine, the submission as a manual lever in case of a failure.

Yandex: recrawl works like clockwork

Yandex has two channels. It accepts IndexNow - but my workhorse is different: recrawl via the Webmaster API (the same limit shows up in the interface: ‘Page recrawl’).

Numbers from a single day, June 23: submitted 5 changed URLs - all accepted with code 202 and a task_id. By eight in the evening that same day the logs showed 9 crawls with 2xx responses: the robot visited every URL, some twice. The quota is 150 URLs a day per site - for my volumes that’s infinity.

An automation nuance: undocumented wrappers around this API live their own lives (my MCP tool for recrawl consistently returns ‘Resource not found’), so it’s more reliable to hit the Webmaster API directly - a plain HTTP request with an OAuth token.

Important not to confuse recrawl with indexing here either: that same Yandex on June 23 dropped 5 of my pages from the index as ‘low-demand’ - with recrawl working perfectly. The robot comes on request; whether the page stays in the index is decided by quality and demand.

Google: the most closed of the three

With Google the picture is this:

The sitemap works. Google picked up fresh blog articles within a day without any pings - verified on four articles published on the same day: by the next day all had the ‘indexed’ status.

Request Indexing in GSC works, but by hand. URL Inspection → Request Indexing, a limit of around 10 URLs a day, reaction from a few hours to three days. For targeted fixes (rewrote a title, updated a key page) - a decent tool.

The Indexing API is a black box. Officially it’s meant only for job postings (JobPosting) and livestreams (BroadcastEvent). I tested it on regular pages twice. First attempt: POST urlNotifications:publish returns 200 - but without the latestUpdate field, and GetMetadata on the same URLs returns 404. So ‘accepted’ and ‘done’ are different things: nothing to confirm a recrawl with, I rolled the integration back. Second attempt, later: submission via a service account with owner rights in GSC - all 5 URLs accepted with code 200 again. Accepted - yes; what happens next, Google doesn’t show. I wouldn’t build a process on this.

Google doesn’t support IndexNow at all. Pings never reach it, by design.

The main takeaway: recrawl is not indexing

Over that same month my GSC stats piled up: 58 pages in the index, 49 - not. Of those 49 the majority are ‘crawled - currently not indexed’ and ‘discovered - currently not indexed’. Google already visited those pages. No ping, submission or Request Indexing will make it change its mind - that’s a question of authority: content, internal linking, external links.

Recrawl tools solve exactly one problem - cutting the time between ‘I changed the page’ and ‘the robot saw it’. That problem they solve: Yandex comes within hours, Bing after a submission - within days, Google via the sitemap - within a day. Everything else is regular content and links; no shortcuts found there.

What to set up on your end: a short plan

IndexNow - key in the root, auto-ping after deploy, retries on 5xx, don’t fail the deploy.
Sitemap - up to date, submitted to GSC, Yandex Webmaster and Bing WMT. This is the foundation; without it the rest is cosmetics.
Yandex - for important fixes, trigger recrawl via the API or the button in Webmaster (150/day).
Bing - check the index every couple of weeks; on a failure - SubmitUrlBatch (100/day).
Google - run targeted fixes through Request Indexing (~10/day), trust the sitemap with the rest.
Don’t mix up the metrics: ‘crawled’ is verified in logs and Webmaster, ‘indexed’ - only in the search engines’ consoles.

Useful links

GEO in real numbers: 40 citations vs 0 - why fight for the Bing index at all.
50 days of SEO in B2B cleaning - 194 pages in Yandex: what indexing looks like when it’s about content.
Beget CDN on shared: what it actually does - the same site’s infrastructure.
Cloudflare in Russia in 2026 - where this infrastructure series started.

If search engines ignore your fixes for weeks or the site won’t get into the index - I’ll dig into it in a one-off audit or as part of SEO services. Quick questions - in Telegram @dimik90.