How to notify Bing of your new pages with IndexNow

“Eighty percent of success is showing up.”
— Woody Allen, 1977

On October 20, I open the URL Inspection tool in Search Console on my SEO service page, the one meant to carry my commercial queries in Valais. Verdict: “Discovered – currently not indexed”. Google knows the address from the sitemap and from four other pages on the site, but it has never crawled it. I did what everyone does in that situation: I clicked “Request indexing”, then clicked again the next day, just in case.

There is no button to force Google's hand. The indexing request is logged, then the page waits until its crawler sees fit to come by, according to its own priorities. Meanwhile, the most important page of my offer stays absent from the results, and from every answer built on them.

So what I set up that day wasn't about Google. I can't rush it, but I can give Bing notice, and through it other engines. The protocol is called IndexNow, it fits in one text file and one command, and it replaces nothing you're already doing.

Why waiting for the crawlers to come by is no longer enough

By default, a search engine discovers your changes by coming back to crawl your site, at its own pace. The sitemap helps it find the addresses, the last-modified date hints at where to look, but the decision to visit remains its own. On a small, recent site, that pace can be measured in weeks.

Google pulls, it won't be pushed

Google works entirely in “pull” mode: it comes to fetch your pages when it has decided to, and it doesn't take part in IndexNow. Search Console lets you request indexing, one address at a time and in limited numbers each day, but it's a request, not an order. I've described elsewhere what really blocks indexing on Google's side , and IndexNow changes nothing about that part.

Bing feeds part of the AI answers

Bing works differently. With IndexNow, you are the one announcing that a page has changed, and the engine can come and fetch it without waiting for its next round. Bing is also one of the sources ChatGPT relies on for its searches, alongside its own crawler: being up to date in Bing is one more chance of being up to date in its answers.

A single notification covers several engines, too. The protocol's participants, including Bing, Yandex, Seznam, Naver and Yep, share the addresses they're notified of with each other, so one submission reaches them all.

Publish a key that proves the site is yours

IndexNow relies on a key: a string of characters you choose and publish in a text file at the root of your site. When you submit a page, the engine checks that this file really exists on the same domain. That's the proof the notification comes from the site's owner, and not from a third party.

Generate the key and create the file

A 32-character hexadecimal key does the job, and a single command generates it. On an Astro site like mine, the file goes in the public/ folder, served as is at the root of the domain:

KEY=$(openssl rand -hex 16)
printf "%s" "$KEY" > web/public/$KEY.txt

Once the site is deployed, check that the file responds at its public address and contains only the key, with no tag or text around it. If it returns an HTML page instead, the engine will reject your notifications with a 403 error.

curl https://tonytony.ch/YOUR_KEY.txt

Submit every changed page with a single command

For a single address, a GET request is enough, and it's the simplest way to check that everything works. Replace the key with yours and the address with the page that has just changed:

curl "https://api.indexnow.org/indexnow?url=https://tonytony.ch/fr/services/seo&key=YOUR_KEY"

Batch several addresses in one submission

For several pages, you send a list in JSON, up to 10,000 addresses per request. I've added a small script to my site's repository that handles it, called from the terminal with the addresses to submit listed after it:

npm run indexnow -- https://tonytony.ch/fr/services/seo https://tonytony.ch/fr/villes/sion

The script sends nothing more than the request below, which you can also run as is. It's the kind of tooling you set up once in web development , then forget until the next release.

curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"host":"tonytony.ch","key":"YOUR_KEY","keyLocation":"https://tonytony.ch/YOUR_KEY.txt","urlList":["https://tonytony.ch/fr/services/seo","https://tonytony.ch/fr/villes/sion"]}'

The response code tells you how the submission went:

• 200 or 202: notification accepted, the second meaning the key is still being verified;
• 403: key not found;
• 422: address that doesn't belong to the declared domain;
• 429: submissions too frequent.

Trigger the notification on every deploy

A tool you run when you remember ends up not being run at all. So I first added the command to my publishing procedure, on the same footing as the indexing request in Search Console. In early November, on two releases in a row, it failed: the environment that publishes my articles automatically wasn't allowed to reach the IndexNow service, and the submission came back to me, to run by hand from my Mac. A step that waits for me to be around is anything but automatic.

Let the host notify the engines

My site is hosted on Netlify, which can run a small function at the end of every successful deploy. I moved the notification there, so it now leaves from the server that has just put the page online, and no longer from my machine. On every deploy, the function follows three steps:

1. it reads the published sitemap;
2. it keeps the addresses that are new or whose last-modified date has changed since the last submission;
3. it sends them to IndexNow in a single request, then stores the accepted dates.

Test previews trigger nothing; only the production site is submitted. And if the submission fails, the dates aren't stored: the same addresses go out again on the next deploy.

Submit what changes, and nothing else

Discipline matters as much as the tool. You submit a page when its content really changes: a new article, a rewritten section, a corrected service page. Resending the whole site every day doesn't get it crawled any faster, and an engine that receives too many pointless notifications ends up treating them as noise. That's why the function relies on the sitemap: the date of one of my articles only moves when I declare it revised, not when I fix a typo.

The day I expanded nine articles in their three languages and added an articles block to three city pages, the list to submit came to thirty addresses, grouped in a single command. Bing Webmaster Tools then lets you check, in its IndexNow section, that the notifications are arriving.

Indexing isn't ranking: what IndexNow won't do for you

Let's be clear about the limit. IndexNow speeds up discovery; it guarantees neither indexing nor ranking. Bing still decides whether to keep your page, and Google ignores it completely: on the day this setup went live, my SEO service page was still waiting for its first visit from Googlebot.

Links and content still decide

What pushes an engine to crawl and then keep a page hasn't changed: content that brings something new, and links, internal and external, saying this page matters. IndexNow shortens the delay between your publication and the moment an engine learns about it. The rest of the work happens elsewhere.

That's why I file it among the execution details of an SEO and AEO strategy, never in its place. First pages that deserve to be indexed, only then the means to make it known fast, and in that order only.

Ready to tell Bing every time your site changes?

You can't rush Google, and that's fine. You can, however, tell Bing that a page has just changed, and let the engines that share its data follow. It's a one-time setup, and once it's wired into your deploys, you don't have to think about it any more.

👉 Want every release of your site reported to the search engines the same day? Contact me