Get Indexed by Bing, ChatGPT & Copilot

ChatGPT search and Microsoft Copilot both read from the Bing index. Getting into Bing quickly is therefore the same job as getting into both of them, and it is the cheapest thing you can do for AI visibility: it is free, there is no daily limit, and setup takes about two minutes.

The same setup also reaches Yandex, Naver, Seznam and Yep, which share the protocol Bing uses.

Google does not take part in this. It needs its own connection.

What actually happens#

Bing accepts a direct notification that a URL is new or changed, through an open protocol called IndexNow. To stop anyone from submitting URLs for a site they do not own, the protocol asks you to publish a key file at your domain. Anyone submitting for your domain has to name that key, and Bing checks it is really there.

That is the whole mechanism: publish one small text file once, and after that any change to your site can be announced instantly.

Setup with CrawlReady#

1. Open Indexing → Settings for your site and turn indexing on.
2. Open the Bing, ChatGPT & Copilot card and choose Set this up.
3. Publish your key, one of two ways:

   • If you use our SDK, set indexNowKey in your @crawlready/middleware config (0.3.0 or later). The middleware answers the request itself, so nothing is lost in a rebuild.

     export default withCrawlReady({
       siteKey: process.env.CRAWLREADY_SITE_KEY!,
       indexNowKey: process.env.CRAWLREADY_INDEXNOW_KEY!,
     });
     

   • Otherwise, download the {key}.txt file and put it where your site serves static files from. It must end up reachable at https://yourdomain.com/{key}.txt.

4. Click Check now. We fetch the file and confirm it reads back correctly.

Once verified, new and changed pages go out automatically. Nothing else to do.

Where the static file goes, by framework:

Doing it without CrawlReady#

The protocol is open and nothing here is proprietary. If you want to run this yourself:

1. Make a key. Any string of 8–128 characters using A–Z, a–z, 0–9 and -. A UUID with the dashes removed is a fine choice.

openssl rand -hex 16

2. Publish it. Create a file named {your-key}.txt whose entire contents are the key, served at your domain root:

https://yourdomain.com/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6.txt

The file must return HTTP 200 as text/plain, and its body must be exactly the key. This is where most setups fail — see the pitfalls below.

3. Submit. One POST, up to 10,000 URLs, all on the same host:

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json" \
  -d '{
    "host": "yourdomain.com",
    "key": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
    "urlList": [
      "https://yourdomain.com/blog/new-post",
      "https://yourdomain.com/pricing"
    ]
  }'

Submit to api.indexnow.org rather than to a specific engine's endpoint. Participating engines share notifications between themselves, so one request reaches all of them; per-engine endpoints exist but using them means several requests for the same result.

What the response means:

Three pitfalls worth knowing about#

A single-page app that serves index.html for unknown paths will fail verification. Your key file request returns 200 with a page of HTML, which is not the key. Make sure the static file is served before your app's catch-all route.

Do not resubmit unchanged pages. This is the mistake that quietly costs you. Engines throttle and eventually ignore hosts that announce changes to pages that did not change. If you script this yourself, track what you last submitted and skip anything whose content is identical.

Rotating the key stops submissions immediately. The old key stops working the moment you generate a new one, and nothing goes out until the new file is published. Only rotate if you have a reason to.

What you cannot see#

Bing and the other engines here accept submissions but expose no way to ask did you index it. There is no read-back. In your dashboard, pages sent only through this route show as not checked rather than as indexed or not — because we genuinely do not know, and a guess would be worse than an honest gap.

If you want coverage data, that comes from connecting Google, which does report back.

Decisions#

• Submit to the shared endpoint, not per-engine ones. Participating engines fan notifications out among themselves; several requests would reach the same crawlers.
• The key is public by design. It has to be readable at your domain for the protocol to work. It grants nothing except the right to say pages on a domain you already control have changed.
• Verification is a gate, not a diagnostic. CrawlReady submits nothing until it can read your key file. Submitting under an unverifiable key earns rejections and eventually gets a domain deprioritised, which takes weeks to undo.