IndexNow in Practice: Manual Submissions Stay Invisible While Cloudflare Crawler Hints Appear Quickly in Bing Webmaster Tools

Recently, while handling search engine closeout for the A Tour of Go multilingual project, I officially integrated IndexNow.

At first, my idea was simple: for every new language added, besides submitting the Sitemap to Google Search Console and Bing Webmaster Tools, I also wanted to actively notify IndexNow-supported search engines about all site URLs.

But after actually tinkering with it, the process was far from smooth.

What confused me the most was:

The IndexNow API had clearly returned HTTP 200, but Bing Webmaster Tools only showed Get Started for a long time.

And this wasn’t even a matter of waiting an hour or two.

Earlier on, I had already tried submitting via the IndexNow API and received HTTP 200, but the Bing backend showed no submission records at all. Later, to figure out exactly which step went wrong, I regenerated the Key, tested different subdomains separately, tried the global IndexNow endpoint, and even directly called Bing’s own IndexNow endpoint.

Everything succeeded at the API level, but the Dashboard remained unchanged.

It wasn’t until I later enabled Cloudflare Crawler Hints and checked Bing Webmaster Tools again after a while that things started to get interesting.

My current intuitive impression is actually:

In terms of the actual visible effect in Bing Webmaster Tools, Cloudflare Crawler Hints is much more obvious than my own direct calls to the IndexNow API.

Of course, this doesn’t prove that direct self-submission is useless. I can only say that based on the currently visible evidence, the Cloudflare pathway performs much more noticeably.

1. Why IndexNow is still needed

The A Tour of Go multilingual project has now launched several language sites.

For each language added, there are about a hundred new pages.

Post-launch search engine closeout usually involves:

Google Search Console
→ Bing Webmaster Tools
→ locale-specific search engine

Google Search Console
→ Bing Webmaster Tools
→ locale-specific search engine

Along with submitting the corresponding site’s Sitemap.

But what a Sitemap mainly does is:

Tell the search engine what URLs exist on this site.

When to actually crawl and when to index is still decided by the search engine itself.

IndexNow provides an alternative approach:

Actively notify IndexNow-supported search engines of URL changes after pages are added, updated, or deleted.

This is quite suitable for my multilingual project.

Because adding a new locale means a concentrated launch of a large number of new pages at once.

There is also another aspect I value:

IndexNow doesn’t only serve Bing.

As long as a search engine participates in the IndexNow ecosystem, it theoretically has the chance to receive URL update notifications through this protocol.

For niche search engines that I wouldn’t normally bother registering for Webmaster Tools or maintaining separate Sitemap submission processes, this adds another channel for page discovery.

It certainly doesn’t guarantee indexing, but it can at least increase the chances of:

Being discovered by more search engines
→ Being crawled
→ Eventually gaining index and traffic

Being discovered by more search engines
→ Being crawled
→ Eventually gaining index and traffic

For multilingual sites, this is still valuable.

2. The initial IndexNow submission didn’t go smoothly

Basic IndexNow integration isn’t complicated.

First, generate a Key, and then:

<key>.txt

<key>.txt

Deploy it to the site’s root directory.

For example:

https://example.com/<key>.txt

https://example.com/<key>.txt

When accessing this URL, the content must correctly return the corresponding Key.

Then you can submit URLs to the IndexNow endpoint.

But on my first test, I got:

HTTP 202

HTTP 202

When I first saw 202, I wondered if there was an issue with my submission method.

Later, I confirmed that 202 here doesn’t mean “submission complete” in the usual sense, but rather:

Request received
But Key validation is still pending

Request received
But Key validation is still pending

So the handling approach I settled on was:

202
→ Do not change the Key
→ Do not bulk submit
→ Wait a while
→ Retry using the same Key

202
→ Do not change the Key
→ Do not bulk submit
→ Wait a while
→ Retry using the same Key

Then check if it has changed to:

HTTP 200

HTTP 200

3. Key validation time is not fixed

I then tested this process continuously across multiple sites.

I found that the wait times varied significantly.

For some new Keys, going from:

202

202

to:

200

200

took over two hours.

But later, when creating new Keys for www.shuijingwanwq.com and en.shuijingwanwq.com, testing again after about twenty minutes already returned 200.

So I stopped setting a fixed wait time for it.

The current rule is simple:

HTTP 202
→ pending
→ pause

re-run later
→ HTTP 200
→ start bulk submission

HTTP 202
→ pending
→ pause

re-run later
→ HTTP 200
→ start bulk submission

This is more reliable than arbitrarily deciding to “wait 10 minutes” or “wait 30 minutes”.

4. What really confused me: after HTTP 200, Bing still showed Get Started

If I had only encountered 202, it would have been relatively easy to understand.

What really made me struggle for a long time was:

The API had clearly returned HTTP 200, but nothing was visible in Bing Webmaster Tools.

Chinese A Tour of Go site:

go-dev.shuijingwanwq.com

go-dev.shuijingwanwq.com

Opening the IndexNow page for a long time always showed the following interface.

This wasn’t the result I saw immediately after submitting.

I had already made API submissions earlier and encountered successful 200s, but the backend never changed.

Later, when redoing the multilingual IndexNow, I specifically performed a more rigorous validation.

5. To troubleshoot the Dashboard, I even redesigned a complete experiment

I suspected many possibilities at the time:

Is there an issue with the Key?
Can one Key not be used for multiple subdomains?
Was the Bing property created too late?
Does Bing Webmaster Tools not recognize submissions to api.indexnow.org?
Is it necessary to directly request Bing's own endpoint?

Is there an issue with the Key?
Can one Key not be used for multiple subdomains?
Was the Bing property created too late?
Does Bing Webmaster Tools not recognize submissions to api.indexnow.org?
Is it necessary to directly request Bing's own endpoint?

So I did another round later.

First, every hostname was changed to use an independent Key.

Then I ensured that:

https://<hostname>/<key>.txt

https://<hostname>/<key>.txt

could return:

HTTP 200

HTTP 200

and the content was completely correct.

Then I submitted a single URL.

Initially:

HTTP 202

HTTP 202

After waiting for Key validation to complete:

HTTP 200

HTTP 200

Then I submitted all the Sitemap’s URLs at once.

Multiple sites eventually all successfully returned:

HTTP 200

HTTP 200

6. The Italian site underwent an even cleaner experiment

Later, the Italian site went live:

it-go-dev.shuijingwanwq.com

it-go-dev.shuijingwanwq.com

I felt this was a good opportunity to troubleshoot this issue one last time.

Because there was one variable that hadn’t been completely ruled out before:

Could it be that the IndexNow submission happened before the Bing Webmaster Tools property was created, so the Dashboard didn’t record historical data?

So this time, I specifically did the reverse:

Create Bing Webmaster Tools property first
→ Then deploy a brand new IndexNow Key
→ Then start the first IndexNow submission

Create Bing Webmaster Tools property first
→ Then deploy a brand new IndexNow Key
→ Then start the first IndexNow submission

First time:

HTTP 202

HTTP 202

After waiting:

api.indexnow.org
→ HTTP 200

api.indexnow.org
→ HTTP 200

To rule out the last variable, I didn’t even use the global endpoint; I directly called Bing’s own IndexNow endpoint.

Result:

HTTP 200

HTTP 200

But back in Bing Webmaster Tools:

Still Get Started

Still Get Started

At this point, I basically didn’t want to keep struggling with the Dashboard anymore.

Because from the protocol and API level:

Public Key: normal
Sitemap: normal
global endpoint: 200
Bing direct endpoint: 200

Public Key: normal
Sitemap: normal
global endpoint: 200
Bing direct endpoint: 200

There was very little left to suspect.

So the final rule formed in the project was:

HTTP 200 serves as machine evidence of IndexNow submission success; the Bing Webmaster Tools Dashboard is not used as a gate.

7. But checking again the next day, things suddenly changed

The next day, I happened to open Bing Webmaster Tools again.

That’s when I discovered:

The IndexNow page had actually started showing data.

This is also why I felt I had to write the previous process in more detail.

If I only wrote:

Submitted yesterday
→ Appeared today

Submitted yesterday
→ Appeared today

It would look like just a normal one-day wait.

The actual situation was not like that at all.

Before this, I had already gone through:

Early IndexNow submissions
→ HTTP 200 appeared
→ Bing showed Get Started for a long time

Redeployed independent Key
→ 202
→ waited
→ 200
→ Bing still Get Started

Created independent Bing property
→ submitted again
→ 200
→ still Get Started

Italian site property created first
→ new Key
→ 202
→ global endpoint 200
→ Bing direct endpoint 200
→ still Get Started

Early IndexNow submissions
→ HTTP 200 appeared
→ Bing showed Get Started for a long time

Redeployed independent Key
→ 202
→ waited
→ 200
→ Bing still Get Started

Created independent Bing property
→ submitted again
→ 200
→ still Get Started

Italian site property created first
→ new Key
→ 202
→ global endpoint 200
→ Bing direct endpoint 200
→ still Get Started

In the end, I had actually given up on using the Dashboard to judge success.

As a result, when I opened it again the next day, it started showing data on its own.

8. The main site finally showed a Self record

The main site can now show a submission record.

The most interesting part is this URL:

https://www.shuijingwanwq.com/2026/07/05/18875/

https://www.shuijingwanwq.com/2026/07/05/18875/

It is exactly the one I used the previous day to test:

whether the new Key had changed from 202 to 200

whether the new Key had changed from 202 to 200

And now Bing Webmaster Tools shows:

Source: Self

Source: Self

So this record can be clearly mapped to my own direct submission.

In other words:

Call IndexNow myself
→ API HTTP 200
→ Dashboard eventually appeared later
→ Source = Self

Call IndexNow myself
→ API HTTP 200
→ Dashboard eventually appeared later
→ Source = Self

At least this one definitely matched up.

9. But I’m still not sure how much “direct bulk submission myself” actually helped

This is also where I’m quite conflicted right now.

Because the previous day, I didn’t just submit one URL.

I had already performed a complete IndexNow bulk submission for:

www.shuijingwanwq.com
3347 URLs

www.shuijingwanwq.com
3347 URLs

and:

en.shuijingwanwq.com
3348 URLs

en.shuijingwanwq.com
3348 URLs

The API result was also:

HTTP 200

HTTP 200

But in Bing Webmaster Tools, the Self evidence I can clearly see right now is, ironically, only that previous test URL.

This makes me unsure:

Did the thousands of URLs from the bulk submission actually all enter Bing’s processing pipeline?

From the API protocol perspective, they returned success.

But based on the visible data in the Bing Webmaster Tools Dashboard, it’s currently impossible to map those thousands of URLs one by one through the backend.

So now I separate the two conclusions.

API level:

HTTP 200
= IndexNow endpoint has accepted this submission

HTTP 200
= IndexNow endpoint has accepted this submission

Dashboard level:

No guarantee of real-time display
And no guarantee of immediately showing all bulk submissions

No guarantee of real-time display
And no guarantee of immediately showing all bulk submissions

Therefore, I will still keep direct submissions, but I will no longer assume:

Once I get a 200, Bing Webmaster Tools should immediately show thousands of records.

The actual situation this time proved that this isn’t the case.

10. Cloudflare Crawler Hints performed noticeably well instead

What really made me feel “this thing is actually working” was the English site.

Open:

en.shuijingwanwq.com

en.shuijingwanwq.com

You can see:

URLs submitted in the past 3 hours: 565
Source: Cloudflare

URLs submitted in the past 3 hours: 565
Source: Cloudflare

This forms a very stark contrast with direct self-submission.

Self-submission:

API 200
→ Dashboard doesn't show for a long time
→ Later only a small amount of Self evidence is clearly visible

API 200
→ Dashboard doesn't show for a long time
→ Later only a small amount of Self evidence is clearly visible

Cloudflare:

Crawler Hints enabled
→ Quickly starts showing a large number of records
→ Source directly shows Cloudflare

Crawler Hints enabled
→ Quickly starts showing a large number of records
→ Source directly shows Cloudflare

At least based on the observable results in Bing Webmaster Tools:

Cloudflare Crawler Hints is much more obviously effective.

11. Configuring Cloudflare Crawler Hints is actually very simple

On the Cloudflare side, what I did wasn’t complicated.

Simply enable it in the corresponding Zone:

Crawler Hints

Crawler Hints

and that’s it.

Once enabled, Cloudflare will provide URL update hints to search engines based on the page changes it observes at the CDN layer.

And Bing Webmaster Tools now directly marks these records as:

Cloudflare

Cloudflare

So at least in terms of results:

Cloudflare Crawler Hints
→ IndexNow ecosystem
→ Bing Webmaster Tools

Cloudflare Crawler Hints
→ IndexNow ecosystem
→ Bing Webmaster Tools

This pathway is truly up and running.

12. The Japanese site also started continuously showing Cloudflare submissions

This phenomenon didn’t only appear on the English site.

Japanese:

ja-go-dev.shuijingwanwq.com

ja-go-dev.shuijingwanwq.com

has also started showing:

Source: Cloudflare

Source: Cloudflare

For example, these have already appeared:

/pkg/io/
/tour/basics/16
/tour/methods/17
/tour/flowcontrol/7
/tour/concurrency/6

/pkg/io/
/tour/basics/16
/tour/methods/17
/tour/flowcontrol/7
/tour/concurrency/6

And the times are constantly updating.

This shows that Cloudflare doesn’t just submit a few fixed URLs once and stop.

It will continuously generate new hints based on site changes.

13. The German site is the same

German:

de-go-dev.shuijingwanwq.com

de-go-dev.shuijingwanwq.com

has also started showing Cloudflare as the source.

You can see:

/pkg/fmt/
/doc/
/tour/methods/13
/tour/methods/21
/tour/

/pkg/fmt/
/doc/
/tour/methods/13
/tour/methods/21
/tour/

and other different pages.

Therefore, it can at least be confirmed now that:

en
ja
de

en
ja
de

multiple sites going through Cloudflare have all shown real Cloudflare IndexNow activity.

This is already hard to explain as an isolated, sporadic occurrence on a single site.

14. Looking back at the Chinese Go Tour, it still shows Get Started

This contrast is particularly interesting.

English, Japanese, and German have already seen a large number of:

Source = Cloudflare

Source = Cloudflare

But the Chinese A Tour of Go:

go-dev.shuijingwanwq.com

go-dev.shuijingwanwq.com

currently still shows:

Get Started

Get Started

There is an important difference between the Chinese Go Tour and other language sites:

Chinese:
EdgeOne

Non-Chinese multiple locales:
Cloudflare

Chinese:
EdgeOne

Non-Chinese multiple locales:
Cloudflare

So the Chinese site itself doesn’t go through the Cloudflare Crawler Hints pathway.

This at least explains:

Why other language sites are continuously showing Cloudflare as a source, while the Chinese site has absolutely no such records.

But this still doesn’t mean:

The Chinese site’s previous direct IndexNow submissions had no effect.

Because the direct submission API did successfully return 200.

It’s just that Bing Webmaster Tools hasn’t provided obvious Dashboard evidence yet.

15. So how do I view “direct submission” vs “Cloudflare Crawler Hints” now

After this hands-on test, I now view them as two different layers.

First launch: do a complete bootstrap yourself

For new language sites, I will still proactively do a full-site IndexNow bootstrap.

The reason is that it can clearly and proactively notify the URLs currently in the official Sitemap.

The process is:

production_state=live
→ verify Key
→ fetch sitemap
→ homepage probe
→ if 202, wait
→ after 200, bulk submit

production_state=live
→ verify Key
→ fetch sitemap
→ homepage probe
→ if 202, wait
→ after 200, bulk submit

This is equivalent to:

Actively telling the IndexNow ecosystem “these pages all exist now” when a new site goes live.

Subsequent normal changes: leave it to Cloudflare Crawler Hints

After the first bootstrap of a new site is completed, I won’t periodically resubmit the entire website.

For language sites going through Cloudflare, subsequent updates rely more on:

Sitemap
+
Cloudflare Crawler Hints

Sitemap
+
Cloudflare Crawler Hints

Based on the actual performance in Bing Webmaster Tools right now, Crawler Hints is even much more visible than my manual bulk submit.

16. Finally turned IndexNow bootstrap into an official Go CLI

After a few rounds of manual testing, repeating this for every new language added:

find hostname
→ generate Key
→ verify Key
→ read Sitemap
→ validate URLs
→ probe
→ wait for 202
→ probe again
→ bulk submit

find hostname
→ generate Key
→ verify Key
→ read Sitemap
→ validate URLs
→ probe
→ wait for 202
→ probe again
→ bulk submit

was just too tedious.

So I ended up integrating the IndexNow bootstrap directly into the official Go CLI for the A Tour of Go multilingual project.

Now, a new locale only requires executing:

go run -mod=readonly ./cmd/tour-i18n indexnow bootstrap \
  --locale <locale> \
  --key-file /secure/path/<key>.txt

go run -mod=readonly ./cmd/tour-i18n indexnow bootstrap \
  --locale <locale> \
  --key-file /secure/path/<key>.txt

The program will automatically:

read production/identity.json
→ only accept production_state=live
→ verify public root key
→ fetch official /sitemap.xml
→ validate HTTPS
→ validate hostname
→ reject duplicate URLs
→ sitemap URL count 1..10000
→ homepage probe
→ stop and wait on 202
→ submit remaining N-1 after 200
→ submitted_urls=N

read production/identity.json
→ only accept production_state=live
→ verify public root key
→ fetch official /sitemap.xml
→ validate HTTPS
→ validate hostname
→ reject duplicate URLs
→ sitemap URL count 1..10000
→ homepage probe
→ stop and wait on 202
→ submit remaining N-1 after 200
→ submitted_urls=N

Finally, I did a real production smoke test on the Italian site:

IndexNow bootstrap: PASS
locale=it-IT
sitemap_urls=105
submitted_urls=105

IndexNow bootstrap: PASS
locale=it-IT
sitemap_urls=105
submitted_urls=105

From then on, the final search engine closeout for adding a new language is also standardized:

Google Search Console
→ Bing Webmaster Tools
→ locale-specific search engine
→ IndexNow bootstrap

Google Search Console
→ Bing Webmaster Tools
→ locale-specific search engine
→ IndexNow bootstrap

17. Why I will still keep my own IndexNow bootstrap

Seeing how fast Cloudflare was, it’s easy to come up with a question:

Since Cloudflare Crawler Hints is already so proactive, is it still necessary to do a full-site submission myself?

My current answer is still:

Yes, but only once.

Because the responsibilities of the two aren’t exactly the same.

Doing the bootstrap myself:

New site launch
→ all official URLs in the current Sitemap
→ one-time proactive notification

New site launch
→ all official URLs in the current Sitemap
→ one-time proactive notification

Crawler Hints:

Subsequent site operation
→ Cloudflare observes changes
→ continuously provides URL hints

Subsequent site operation
→ Cloudflare observes changes
→ continuously provides URL hints

And not all sites necessarily use Cloudflare.

For instance, the Chinese A Tour of Go currently uses EdgeOne.

Therefore, it still makes sense for the project itself to have a standard IndexNow bootstrap that doesn’t depend on a specific CDN.

18. IndexNow’s biggest value to me isn’t just Bing

When I first started looking into IndexNow, I was mostly focused on Bing.

But after finishing, I feel that what really attracts me about it is:

A single submission can increase the chances of being discovered by multiple IndexNow-supported search engines.

Google and Baidu currently still run their own discovery, crawling, and submission processes.

But besides them, there are many smaller search engines on the internet.

If they support IndexNow, I don’t need to do the following for every single one:

register a separate webmaster platform
→ verify the domain separately
→ submit a Sitemap separately
→ maintain it separately

register a separate webmaster platform
→ verify the domain separately
→ submit a Sitemap separately
→ maintain it separately

My multilingual sites can still gain extra URL discovery opportunities through IndexNow.

For a scale of dozens of languages, the value of this “standardize once, cover more search channels” approach will become increasingly apparent.

Even if it only brings in a small portion of long-tail traffic in the end, it’s an extra gain.

19. A few conclusions I reached after this ordeal

First, a new Key’s first appearance of:

HTTP 202

HTTP 202

Don’t rush to change the Key.

Just wait for validation and try again.

Second:

HTTP 200

HTTP 200

is still my primary machine evidence for judging IndexNow API submission success.

Third, don’t expect the Bing Webmaster Tools Dashboard to reflect API results in real time.

I have actually experienced:

API returned 200 long ago
→ Dashboard stuck on Get Started

API returned 200 long ago
→ Dashboard stuck on Get Started

Even after specifically redoing a clean experiment, it was still the same.

Fourth, the Dashboard later did start showing Self records, so direct self-submission isn’t completely without evidence.

But I still can’t prove from the Dashboard that:

All the thousands of URLs I bulk submitted the previous day have been displayed one by one.

Fifth, Cloudflare Crawler Hints’ effect is very intuitive.

The English site showed at one point:

Past 3 hours: 565
Source: Cloudflare

Past 3 hours: 565
Source: Cloudflare

The Japanese and German sites are also continuously generating Cloudflare-sourced records.

Sixth, based on the “visible results” in Bing Webmaster Tools right now:

Cloudflare Crawler Hints is much more obvious than direct self-submission.

As to whether Cloudflare actually processes faster, or Bing Dashboard reports Cloudflare sources more promptly, there isn’t enough evidence to draw a conclusion right now.

Seventh, IndexNow doesn’t guarantee indexing.

What it solves is:

proactive notification
→ increases discovery chances
→ increases crawl chances

proactive notification
→ increases discovery chances
→ increases crawl chances

Whether it ultimately gets indexed is still the search engine’s own decision.

But for my multilingual project, there’s another layer of significance:

The more IndexNow-supported search engines can discover these pages, the more chances there are to gain some long-tail traffic from different countries and different search engines.

This is also one of the main reasons I ultimately decided to officially add IndexNow to the new locale launch process.