Google ignores IndexNow, which is exactly why it is worth setting up.

IndexNow gets dismissed for one reason. Google does not support it. That is true, and it is the wrong place to stop reading, because Google is not the only index that matters anymore. IndexNow is a simple protocol that lets you tell a search engine the moment a URL is created, updated, or deleted, instead of waiting for a crawler to rediscover it. It is supported by Bing, Yandex, Naver, Seznam, and Yep. And Bing's index is the one that feeds Microsoft Copilot, DuckDuckGo, and the web search behind ChatGPT. So the question is not whether IndexNow helps you in Google. It is whether you want your freshest content reaching AI answer engines in minutes instead of days.
The adoption numbers say this is not a fringe protocol. As of 2026, more than 5 billion URLs are submitted through IndexNow every day, up from 3.5 billion in 2024, and Bing reported in December 2025 that 22% of all clicked URLs in its results came from IndexNow submissions, up from 18% a year earlier. Google has been testing IndexNow since October 2021 and still has not adopted it, so the right mental model is two pipelines. Sitemaps and Search Console for Google, IndexNow for everyone else, including the AI surfaces.
Why this is an AI visibility lever
When you change a page, a normal crawler finds out whenever it next happens to crawl you, which on a mid-authority site can be days. IndexNow collapses that to a push. You tell Bing the URL changed, Bing re-crawls and re-indexes it quickly, and because Copilot, DuckDuckGo, and ChatGPT's web search draw on the Bing index, your updated content becomes eligible to be cited in those answers far sooner. For anything time-sensitive, a price change, a new article, a corrected fact, a product going out of stock, that speed gap is the difference between being the answer and being last quarter's answer. Framed that way, IndexNow is a freshness pipe into the AI answer engines, not the Google indexing hack most people assume it is.
The implementation, end to end
The protocol is genuinely small. Three moving parts, and then you automate it.
Step 1, generate a key
You need a key that is 8 to 128 characters, using only letters, numbers, and dashes. A hex string is the convention. This key is how a search engine confirms you actually control the domain you are submitting URLs for.
a3f5c9e1b27d44708e6f1c0***********
Step 2, host the key file
Create a UTF-8 text file named {your-key}.txt whose only contents are the key itself, and place it at the root of your site.
https://example.com/a3f5c9e1b27d44708e6f1c0ad9b3e5f2.txt
When you submit URLs, the search engine fetches this file and checks that the key inside matches the key you submitted. Root placement matters. Per the IndexNow documentation, a key hosted at the root can authorize any URL on the host, while a key file placed in a subfolder can only authorize URLs under that subfolder. Put it at the root unless you have a specific reason not to.
Step 3, ping on change
Two ways to submit. For a single URL, a GET request.
https://api.indexnow.org/indexnow?url=https://example.com/blog/new-post&key=a3f5c9e1b27d44708e6f1c0ad9b3e5f2
For many URLs at once, a POST with a JSON body, up to 10,000 URLs per request.
POST /indexnow HTTP/1.1
Content-Type: application/json; charset=utf-8
Host: api.indexnow.org
{
"host": "example.com",
"key": "a3f5c9e1b27d44708e6f1c0***********",
"keyLocation": "https://example.com/a3f5c9e1b27d44708e6f1c0ad9b3e5f2.txt",
"urlList": [
"https://example.com/blog/new-post",
"https://example.com/products/sku-123",
"https://example.com/retired-page"
]
}
Submit to api.indexnow.org and the submission is shared with every participating engine at once, so you do not need to ping Bing, Yandex, and the rest separately. You can also submit to a specific engine endpoint like bing.com/indexnow if you want to, but the shared endpoint is simpler.
Reading the response
A 200 means received. The other codes tell you exactly what to fix, and you should log them rather than fire and forget.
| Code | Meaning | What it tells you |
|---|---|---|
200 | OK | URL submitted successfully |
202 | Accepted | Received, key validation still pending |
400 | Bad request | Invalid format in your submission |
403 | Forbidden | Key not valid, file missing or key not in the file |
422 | Unprocessable | URL does not belong to the host, or key schema mismatch |
429 | Too many requests | You are submitting too often, treated as potential spam |
The one rule that keeps you out of trouble
Only submit URLs that actually changed. IndexNow is an event signal, not a sitemap you resubmit on a schedule. Pushing your whole URL set every night, or re-pinging unchanged pages, is how you earn 429 responses and train the engine to ignore you. New URL, updated URL, deleted URL. Those three events, nothing else.
Wiring it into your platform
Knowing the API is not the same as having it fire on its own. What you want is the ping going out automatically every time you publish, and how you get there depends on your stack.
On WordPress, you do not write any code. The Bing-built IndexNow plugin, plus Yoast SEO and Rank Math, all submit URLs automatically on publish and update, and they generate and host the key file for you. Turn it on and move on.
On Cloudflare, there is a one-click IndexNow integration in the dashboard that generates a key, hosts it, and submits URLs Cloudflare sees changing through its network. If you are already on Cloudflare, this is the lowest-effort option available and it works regardless of your CMS.
On Shopify, there is no native support, so you either install an app that handles IndexNow submission or wire a webhook. Shopify can fire a webhook on product create, update, and delete, which you point at a small serverless function that calls the IndexNow API with the affected URL.
On a headless or custom stack, you submit from your publish webhook. A CMS like Sanity, Contentful, or Strapi can call a serverless function whenever a document is published or unpublished, and that function pushes the affected URL to IndexNow. A Node handler looks like this.
// Serverless handler triggered by a CMS publish webhook
export default async function handler(req, res) {
const { slug, deleted } = req.body; // from your CMS payload
const url = `https://example.com/blog/${slug}`;
const r = await fetch("https://api.indexnow.org/indexnow", {
method: "POST",
headers: { "Content-Type": "application/json; charset=utf-8" },
body: JSON.stringify({
host: "example.com",
key: process.env.INDEXNOW_KEY,
keyLocation: `https://example.com/${process.env.INDEXNOW_KEY}.txt`,
urlList: [url]
})
});
return res.status(200).json({ submitted: url, indexnow: r.status });
}
For a static site or a Jamstack build, do it in CI. On deploy, diff which pages changed in the build, collect their URLs, and POST the list to IndexNow as the last step of your pipeline. The build already knows what changed, so you are just forwarding that knowledge to Bing.
Measuring whether it works
Bing Webmaster Tools turns IndexNow from an act of faith into a reported win, and the first thing we check after switching it on for a client is whether submissions are actually being accepted, because a wrong key or a host mismatch fails without any visible error on your end. Its IndexNow section shows the URLs you have submitted and their status, so you can confirm submissions are landing rather than bouncing.

Pair that with URL Inspection in Bing Webmaster Tools to watch how quickly a submitted URL moves to indexed. The clean test is a before-and-after. Publish a batch of pages without IndexNow and note how long they take to appear in Bing, then turn IndexNow on and publish a comparable batch, and compare the indexing timelines. On most sites the submitted pages index materially faster, and that is the number you put in front of whoever needs convincing.

The traps to avoid
A few things break IndexNow without an obvious error. Submitting a URL that is blocked by robots.txt or carries a noindex is wasted effort and noise, so only push pages you actually want indexed. The submitted host has to match the key file's host exactly, including the www or non-www form, or you get a 422. Do not submit on a timer. And do not expect any of this to move Google, because it will not. IndexNow is the Bing-and-AI pipeline, which is why you run it alongside your Google setup rather than instead of it.
It is not worth the effort everywhere. If you publish rarely, or your audience never touches Bing-powered or AI search, the indexing speed you gain rounds to nothing and your time goes further elsewhere. The sites that get paid back are the ones changing pages often, where freshness is a real edge, ecommerce inventory, news, fast-moving editorial, anything where being a day late means being wrong. For those, wiring IndexNow to your publish event is an afternoon of work that pays out on every change you ship, long after you have forgotten it is running.
See where your brand stands in AI answers today, benchmarked against your competitors, no pitch required.

Updating your page does nothing until the freshness signals move with it
You can rewrite half an article and to a machine the page looks untouched. Freshness is a technical claim carried by dateModified, sitemap lastmod, and the visible date. How to signal real updates without faking the dates.
read_post →
Google recrawls your 404s far more than your 410s, and at scale that is real budget
The 410 deindexation-speed gap is smaller than people claim. But a controlled experiment found Google recrawls 404s 49.6% more than 410s, and on a large site that is real crawl budget. Here is when to use each and how to deploy 410 at scale.
read_post →
Blocking every AI bot with one line costs you the citations you actually want
AI crawlers do three different jobs, training, retrieval for citation, and user-triggered fetches. A blanket Disallow blocks them all and can delete you from ChatGPT and Perplexity answers. Here is how to segment robots.txt instead.
read_post →