What is Magento IndexNow ?

No — not in production as of 2026. Google announced in November 2021 that they would test the IndexNow protocol, then announced again in 2024 that testing was still ongoing, but as of this writing there is no Google IndexNow endpoint and Google does not honour pings to api.indexnow.org for crawl-priority. For Google, use the standard channels: an up-to-date XML sitemap submitted in Google Search Console, the URL Inspection tool for one-off urgent submissions, and (where available) the Indexing API for job-posting and live-stream URL types. IndexNow remains the right tool for Bing, Yandex, Seznam, Yep, and Naver — just not Google.

Yes, completely free — no cost, no paid tier, no API-key fees. The only quota is the rate limit, which sits at roughly 10,000 URLs per day per unverified key for the public endpoint. Verified sites (those with a Bing Webmaster Tools account linked to the same domain as the IndexNow key) get a higher effective ceiling. Bursts are rate-limited regardless of verification status — if you push 20,000 URLs in a single minute you will see 429 responses. That is why cron-deferred batching is the recommended pattern: queue the pings, batch them up to 10,000 per request, and POST one batch per cron tick.

For established sites with healthy crawl budget, the typical IndexNow-to-crawl latency is hours, sometimes minutes for top-priority URLs (recent content from a domain Bing trusts). New domains and low-authority sites can wait 12 – 48 hours even with IndexNow, because the protocol guarantees crawl scheduling, not crawl-rate priority — Bing still applies its normal crawl-budget heuristics. The headline win is the comparison against organic discovery: without IndexNow, a brand-new URL waits a median of 4 – 14 days for Bing to find it via sitemap re-fetch or link-following. With IndexNow, the median drops to under 24 hours.

No harm done — Bing returns 200 (accepted) and schedules the URL for re-evaluation. Whether it actually re-crawls depends on its own freshness heuristics: a CMS page that hasn’t changed since the last crawl might be skipped, while a product page with a price change in the meta will be re-fetched. There is no penalty for over-pinging a URL within reason — the rate limit is a per-key, per-day ceiling on the count of submitted URLs, not on duplicates. The mage2kishan module deduplicates within a 24-hour window by default to avoid wasting quota on no-op re-pings, but you can override that in admin.

Yes — the protocol explicitly supports this. The key is a credential proving you control <em>at least one</em> host. The verification file must be served at every host you ping for, and each ping sets the <code>host</code> parameter explicitly so Bing knows which site the URLs belong to. This is convenient for agencies and multi-store Magento setups where one key serves five or six storefronts — rotate the key in one admin, re-publish the verification file via the controller route on every storefront, and you’re done. The mage2kishan module supports multi-store setups out of the box and writes the same key + per-store host into each ping.

Yes. Rotating the key from admin (<code>Stores → Configuration → Panth → IndexNow → Regenerate Key</code>) does three things atomically: it updates the stored key in <code>panth_indexnow/indexnow/api_key</code>, it invalidates the old verification file served via the controller route (now 404), and it begins serving the new verification file at <code>/<newkey>.txt</code>. Subsequent pings include the new key in the JSON body and the new <code>keyLocation</code> URL, so Bing re-validates within minutes. Old pings that were already queued at rotation time are re-keyed before being POSTed to avoid 422 mismatches. Verify with <code>curl https://yoursite.com/<newkey>.txt</code> immediately after rotation and check <code>var/log/panth_indexnow.log</code> for the first post-rotation ping response code — you want a clean <code>200</code>.