How to Submit Your Site to Bing with IndexNow (2026 Guide)

If you want to submit your site to Bing, there are two separate jobs. First, prove to Bing that you own the site and give it a sitemap, so it knows every page you want indexed. Second, tell Bing quickly whenever a page is added or changed. Bing Webmaster Tools handles the first job. IndexNow handles the second.

In this guide I walk through both, using the setup I run on this portfolio site: a static site on Netlify that sends an IndexNow ping automatically after every production deploy. I also cover the response codes you will see, the mistakes that waste effort, and one thing IndexNow does not do at all: it does not notify Google.

What IndexNow is and why it matters for Bing

Search engines normally find changes by crawling: a bot visits your pages on its own schedule and checks what is new. On a small or young site, that schedule can be slow.

IndexNow reverses the direction. Your site sends a short message that says "these exact URLs changed." According to the IndexNow FAQ, the participating engines include Bing, Yandex, Naver, Seznam.cz, Yep and Amazon, and the IndexNow documentation says a submission is shared with all of them. You only submit once.

Google is not on that list. For Google, you still rely on your sitemap and Google Search Console. This is the most common misunderstanding I see.

There is also a newer reason to care. In February 2026, Microsoft introduced AI Performance in Bing Webmaster Tools, a report showing how often your pages are cited in Microsoft Copilot and AI-generated summaries in Bing. The same announcement recommends IndexNow so AI systems can reference the current version of your content.

One honest limit: submitting a URL does not guarantee indexing. Each engine still decides whether to crawl and index the page.

Step 1: Add and verify your site in Bing Webmaster Tools

Verification proves you control the site, and the sitemap gives Bing a complete list of pages to start from.

1. Sign in to Bing Webmaster Tools.
2. Import from Google Search Console if you can. If your site is already verified there, the Import option lets Bing read your verified sites and their sitemaps, so you skip a second verification. Bing's import guide notes that Bing re-checks ownership through that connection from time to time. If you later revoke access, you will need another verification method.
3. Otherwise, add the URL manually and verify it with an XML file, a meta tag or a DNS record, as described in Bing's add and verify guide.
4. Submit your sitemap in the Sitemaps section, for example https://example.com/sitemap.xml.
5. Check that Bing read it. The sitemap status should show success and a discovered URL count close to the number of pages you expect.

Keep the sitemap clean. Mine lists only pages I want in search results, so drafts and the contact form's thank-you page are left out. This matters later, because my IndexNow automation uses the sitemap as its allow-list.

Expect quiet reports at first. On a young domain some Bing reports stay empty for a while. When I wrote this, my own site still showed no backlink data in Bing, which is normal for a new domain and not a setup error.

Step 2: Create an IndexNow key and host the key file

The key is how IndexNow checks that the person sending URLs controls the website. You choose it yourself.

1. Create a key between 8 and 128 characters, using letters, numbers and dashes. A random 32-character hexadecimal string works well.
2. Create a text file named after the key, such as a1b2c3d4e5f6a7b8.txt. It should contain only the key and be saved as UTF-8.
3. Upload it to your site root, so it loads at https://example.com/a1b2c3d4e5f6a7b8.txt.
4. Open that URL in a browser and confirm you see the key and nothing else.

The root location matters. A key file at the root covers every URL on that host. In a subfolder, you must send its address as keyLocation, and it only covers URLs inside that folder. Each subdomain also needs its own key file.

The key is not a password. Anyone can read the file by design; it only proves that whoever submits URLs can also place files on your site.

Two details came up while I built the key check for my IndexNow Submitter tool. Some Windows editors add an invisible byte order mark (BOM) to the start of UTF-8 files, so a file that looks correct can fail an exact comparison. My checker removes it before comparing. I also made the checker reject redirects. If your host redirects the key file, fix the file location instead of hoping every engine follows the redirect.

Step 3: Submit changed URLs and read the response

For a single URL, a GET request is enough. The url value should be URL-encoded:

https://api.indexnow.org/indexnow?url=https%3A%2F%2Fexample.com%2Fblog%2Fnew-post.html&key=a1b2c3d4e5f6a7b8

For several URLs, send one POST request with JSON. The documentation allows up to 10,000 URLs in a single request.

const response = await fetch("https://api.indexnow.org/indexnow", {
  method: "POST",
  headers: { "Content-Type": "application/json; charset=utf-8" },
  body: JSON.stringify({
    host: "example.com",
    key: "a1b2c3d4e5f6a7b8",
    keyLocation: "https://example.com/a1b2c3d4e5f6a7b8.txt",
    urlList: [
      "https://example.com/blog/new-post.html",
      "https://example.com/pricing.html",
    ],
  }),
});

console.log(response.status);

The HTTP status code tells you what happened:

If you would rather not write code, I built a free IndexNow Submitter that generates a key, checks your key file and sends your URLs from the browser. It uses a small server function because the IndexNow API does not accept direct calls from web pages on other sites. It sits alongside my other free developer tools.

How I automated IndexNow on a Netlify static site

Manual submission works until someone forgets it. I update this site several times a week, so I wanted the ping to happen inside the deploy, without ever sending unchanged pages.

The IndexNow FAQ asks you to submit only meaningful changes, so sending the whole sitemap on every deploy was not an option. Instead, I wrote a small local Netlify build plugin that runs on the onSuccess event, after the deploy is live. Netlify's build plugin documentation notes that this event cannot stop a deploy, which is what I want: a failed ping should never block a release.

The plugin follows four rules:

1. Run only in the production context, so branch previews and draft deploys never send a ping.
2. Compare the previous production commit with the new one, using the CACHED_COMMIT_REF and COMMIT_REF values from Netlify's build environment variables.
3. Turn changed HTML files into URLs and keep only the ones listed in sitemap.xml.
4. Catch every error, show it in the deploy summary and let the deploy finish.

The core is short. This is a simplified version of the real code:

# netlify.toml
[[plugins]]
  package = "/netlify/plugins/indexnow"

// netlify/plugins/indexnow/changed-urls.js (simplified)
if (process.env.CONTEXT !== "production") return skip("not production");
const { CACHED_COMMIT_REF: from, COMMIT_REF: to } = process.env;
if (!from || from === to) return skip("no new commit");
const changedFiles = git(["diff", "--name-only", "--diff-filter=AMR", from, to]);
const urls = toUrls(changedFiles).filter((url) => sitemapUrls.has(url));

The whole handler sits in a try/catch, and errors go to the deploy summary through utils.status.show. After the first deploy with the plugin, that summary showed "IndexNow: Submitted 2 changed URL(s), HTTP 200." Each production deploy now reports the URLs it sent or the reason it skipped.

Trade-offs I accepted

The plugin only looks at HTML files. A shared stylesheet change sends nothing, because the content did not change. That matches the purpose of IndexNow.

It also ignores deleted files. The protocol lets you submit removed URLs, but I rarely delete pages. When I retire one, I add a 301 redirect and send the old address manually.

One Netlify detail is easy to miss. When a build runs without cache, CACHED_COMMIT_REF equals COMMIT_REF, so the plugin skips. For those cases I keep npm run indexnow:submit as a manual fallback.

Mistakes that waste your IndexNow effort

Most IndexNow problems are not technical. They come from expecting the protocol to do something it was not built for.

• Expecting Google to react. Google is not a participant. Use Search Console and an accurate sitemap for Google.
• Resubmitting everything on every deploy. Send only pages whose content changed. A 429 response is a clear sign that you are sending too much.
• Using IndexNow as a backfill. It is for changes from now on. Your sitemap covers older pages.
• Sending pages that should not be indexed. Drafts, preview links and noindex pages do not belong in a submission. A sitemap filter prevents this.
• Mixing hosts. If the key file is on example.com but the URLs use www.example.com, expect a 422. Pick one main host and redirect the other to it.
• Treating 202 as an error. It usually means the key is still being checked. Confirm the key file loads and wait, instead of generating a new key.

After setup, check Bing Webmaster Tools. URL Inspection shows whether a page is indexed, and AI Performance shows whether your pages are cited in Copilot answers. The reports a few days later tell you more than a single submission response.

Practical takeaway

To submit your site to Bing properly, treat it as two layers. Verify the site in Bing Webmaster Tools and submit a clean sitemap once. Then use IndexNow for every meaningful change after that, ideally from your deploy pipeline so nobody has to remember it. Keep Google on its own track through Search Console.

If you only want to test the protocol, start with the IndexNow Submitter and one URL. If you want the same automation added to your website or SaaS deploy pipeline, get in touch and tell me how your site is built and deployed.