最近在给 A Tour of Go 多语言项目做搜索引擎收口时，我开始正式接入 IndexNow。
一开始我的想法很简单：每增加一门语言，除了在 Google Search Console、Bing Webmaster Tools 中提交 Sitemap，还希望主动把整站 URL 通知给支持 IndexNow 的搜索引擎。
但实际折腾下来，过程远没有想象中顺利。
最让我困惑的是：
IndexNow API 明明已经返回了 HTTP 200，Bing Webmaster Tools 却长期只显示
Get Started。
甚至这并不是等一两个小时的问题。
更早之前，我就已经尝试过 IndexNow 接口提交，也出现过 HTTP 200，但 Bing 后台一直没有任何提交记录。后来为了确认到底是哪一步出了问题，我又重新生成 Key、分别测试不同子域名、尝试全局 IndexNow endpoint，甚至直接调用 Bing 自己的 IndexNow endpoint。
接口层面都已经成功了，Dashboard 还是没有变化。
直到后来开启 Cloudflare Crawler Hints，再过一段时间重新查看 Bing Webmaster Tools，事情才开始变得有意思起来。
目前我的直观感受甚至是：
在 Bing Webmaster Tools 能看到的实际效果上，Cloudflare Crawler Hints 比我自己直接调用 IndexNow API 明显得多。
当然，这并不能证明自己直接提交没有作用。只能说从目前能够看到的 evidence 来看，Cloudflare 这一条链路表现得更加明显。
一、为什么还需要 IndexNow
A Tour of Go 多语言项目现在已经上线了多个语言站。
每增加一门语言，大约都会新增一百多个页面。
上线以后的搜索引擎收口通常包括：
Google Search Console
→ Bing Webmaster Tools
→ locale-specific search engine同时提交对应站点的 Sitemap。
但 Sitemap 解决的主要是：
告诉搜索引擎，这个站有哪些 URL。
什么时候真正抓取、什么时候建立索引，还是由搜索引擎自己决定。
IndexNow 则提供了另一种方式：
页面新增、更新或删除以后，主动把 URL 变化通知给支持 IndexNow 的搜索引擎。
这对我的多语言项目比较合适。
因为每增加一个 locale，都是一次集中上线大量新页面。
另外还有一个我比较看重的地方：
IndexNow 并不只服务于 Bing。
只要搜索引擎参与 IndexNow 生态，理论上就有机会通过这套协议收到 URL 更新通知。
对于一些平时我根本不会专门去注册 Webmaster Tools、也不会单独维护 Sitemap 提交流程的小众搜索引擎来说，这相当于多了一条发现页面的渠道。
它当然不能保证收录，但至少能够增加：
被更多搜索引擎发现
→ 被抓取
→ 最终获得索引和流量的机会。
对于多语言站来说，这一点还是有价值的。
二、最开始的 IndexNow 提交并不顺利
IndexNow 的基本接入并不复杂。
先生成 Key，然后把：
<key>.txt部署到网站根目录。
例如：
https://example.com/<key>.txt访问这个地址时，内容必须能够正确返回对应的 Key。
随后就可以向 IndexNow endpoint 提交 URL。
但第一次测试时，我得到的是：
HTTP 202刚开始看到 202 时，我一度怀疑是不是提交方式有问题。
后来确认，202 在这里代表的不是普通意义上的“提交完成”，而是：
请求已经收到
但 Key validation 仍然 pending所以后来形成的处理方式是：
202
→ 不换 Key
→ 不全量提交
→ 等一段时间
→ 使用同一个 Key 再试然后再判断是否已经变成：
HTTP 200三、Key validation 的时间并不固定
这个过程后来我连续测试了多个站。
结果发现等待时间差异非常明显。
有的新 Key 从：
202变成：
200用了两个多小时。
而后来给 www.shuijingwanwq.com 和 en.shuijingwanwq.com 创建的新 Key，大约二十分钟以后再次测试，就已经返回 200。
所以我后来不再给它设置什么固定等待时间。
现在的规则很简单：
HTTP 202
→ pending
→ 暂停
稍后重新执行
→ HTTP 200
→ 再开始全量提交这样比人为规定“等 10 分钟”“等 30 分钟”更可靠。
四、真正让我困惑的是：HTTP 200 以后，Bing 还是 Get Started
如果只是遇到 202，其实还比较容易理解。
真正让我折腾很久的是：
API 已经明确返回 HTTP 200，但 Bing Webmaster Tools 里面完全看不到。
中文 A Tour of Go 站：
go-dev.shuijingwanwq.com长期打开 IndexNow 页面，看到的都是下面这个界面。
这并不是我刚提交完马上去看的结果。
更早之前我就已经做过接口提交，也遇到过成功的 200，但后台一直没有变。
后来重新做多语言 IndexNow 时，我又专门进行了更严格的验证。
五、为了排查 Dashboard，我甚至重新设计了一次完整实验
我当时怀疑过很多可能：
是不是 Key 有问题？
是不是一个 Key 不能给多个子域使用？
是不是 Bing property 创建得太晚？
是不是 api.indexnow.org 提交以后，Bing Webmaster Tools 不认？
是不是必须直接请求 Bing 自己的 endpoint？所以后来重新做了一轮。
首先，每个 hostname 都改为使用独立 Key。
然后保证：
https://<hostname>/<key>.txt能够返回：
HTTP 200并且内容完全正确。
再提交一个单独 URL。
最开始：
HTTP 202等待 Key validation 完成以后：
HTTP 200随后再把整个 Sitemap 的 URL 一次性提交。
多个站点最终都成功返回：
HTTP 200六、意大利语站又做了一次更干净的实验
后来新上线了意大利语：
it-go-dev.shuijingwanwq.com我觉得这是最后一次排查这个问题的好机会。
因为之前有一个变量一直没完全排除：
会不会是因为 IndexNow 提交发生在 Bing Webmaster Tools property 创建之前，所以 Dashboard 没有记录历史数据？
于是这一次专门反过来：
先创建 Bing Webmaster Tools property
→ 再部署全新的 IndexNow Key
→ 再开始第一次 IndexNow 提交第一次：
HTTP 202等待以后：
api.indexnow.org
→ HTTP 200为了再排除最后一个变量，我甚至不用全局 endpoint，而是直接调用 Bing 自己的 IndexNow endpoint。
结果：
HTTP 200但回到 Bing Webmaster Tools：
仍然是 Get Started到这里我基本不想继续折腾 Dashboard 了。
因为从协议和接口层面看：
公网 Key：正常
Sitemap：正常
global endpoint：200
Bing direct endpoint：200还能继续怀疑的东西已经非常少。
所以项目里最后形成的规则是：
HTTP 200 作为 IndexNow submission success 的机器 evidence，Bing Webmaster Tools Dashboard 不作为 gate。
七、但是第二天再看，事情突然变了
到了第二天，我无意中再次打开 Bing Webmaster Tools。
这时候才发现：
IndexNow 页面竟然开始显示数据了。
这也是为什么我觉得必须把前面的过程写详细一点。
如果只写：
昨天提交
→ 今天出现看起来好像只是正常等待了一天。
实际情况完全不是这样。
在这之前，我已经经历过：
早期 IndexNow 提交
→ 出现 HTTP 200
→ Bing 长期 Get Started
重新部署独立 Key
→ 202
→ 等待
→ 200
→ Bing 仍 Get Started
创建独立 Bing property
→ 再提交
→ 200
→ 仍 Get Started
意大利语站 property 先建
→ 新 Key
→ 202
→ global endpoint 200
→ Bing direct endpoint 200
→ 仍 Get Started最后我实际上已经放弃继续用 Dashboard 判断成功与否。
结果第二天再打开的时候，它自己开始显示数据了。
八、主站终于出现了一条 Self 记录
主站现在已经能够看到一条提交记录。
最有意思的是这个 URL：
https://www.shuijingwanwq.com/2026/07/05/18875/它正好就是前一天我用来测试：
新 Key 是否已经从 202 变成 200的那个 URL。
而现在 Bing Webmaster Tools 中显示：
来源：Self所以这条记录可以比较明确地对应到我自己的直接提交。
也就是说：
自己调用 IndexNow
→ API HTTP 200
→ 后来 Dashboard 最终出现
→ Source = Self至少这一条确实对应上了。
九、但我现在仍然不确定“自己直接全量提交”到底起了多大作用
这里也是我现在比较纠结的地方。
因为前一天我并不是只提交了一个 URL。
后来已经把：
www.shuijingwanwq.com
3347 个 URL和：
en.shuijingwanwq.com
3348 个 URL都做过完整的 IndexNow bulk submission。
接口结果也是：
HTTP 200但到了 Bing Webmaster Tools 中，目前我能够非常明确看到的 Self evidence，反而只有前面那个测试 URL。
这就让我不太确定：
Bulk submission 的几千个 URL 到底有没有全部进入 Bing 的处理链？
从 API 协议角度看，它们已经返回成功。
但从 Bing Webmaster Tools Dashboard 的可见数据来看，目前还无法通过后台把这几千个 URL 一一对应出来。
所以现在我会把两个结论分开。
接口层：
HTTP 200
= IndexNow endpoint 已接受这次提交Dashboard 层：
不保证实时显示
也不保证马上把 bulk submission 全部展示出来因此直接提交我仍然会保留，但不会再认为：
一旦得到 200，Bing Webmaster Tools 马上就应该出现几千条记录。
这次实际情况证明不是这样。
十、Cloudflare Crawler Hints 的表现反而非常明显
真正让我觉得“这东西确实开始工作了”的，是英文站。
打开：
en.shuijingwanwq.com可以看到：
过去 3 小时提交的 URL：565
来源：Cloudflare
这和自己直接提交形成了非常明显的反差。
自己提交：
API 200
→ Dashboard 很久不显示
→ 后来只明确看到少量 Self evidenceCloudflare：
Crawler Hints 开启
→ 很快开始出现大量记录
→ Source 直接显示 Cloudflare至少从 Bing Webmaster Tools 的可观察结果来看：
Cloudflare Crawler Hints 的效果明显得多。
十一、Cloudflare Crawler Hints 的配置其实非常简单
Cloudflare 这一边，我做的事情并不复杂。
直接在对应 Zone 中开启：
Crawler Hints即可。
开启以后，Cloudflare 会根据它在 CDN 层观察到的页面变化，向搜索引擎提供 URL 更新提示。
而 Bing Webmaster Tools 现在直接把这些记录标记成：
Cloudflare所以至少从结果上看：
Cloudflare Crawler Hints
→ IndexNow ecosystem
→ Bing Webmaster Tools这一条链路已经真正跑起来了。
十二、日语站也开始不断出现 Cloudflare 提交
这种现象并不是只出现在英文站。
日语：
ja-go-dev.shuijingwanwq.com同样已经开始显示：
来源：Cloudflare
例如已经出现：
/pkg/io/
/tour/basics/16
/tour/methods/17
/tour/flowcontrol/7
/tour/concurrency/6而且时间还在不断更新。
这说明 Cloudflare 并不是一次性把几个固定 URL 提交以后就结束了。
它会持续根据站点变化产生新的 hints。
十三、德语站同样如此
德语：
de-go-dev.shuijingwanwq.com也开始显示 Cloudflare 来源。
能看到：
/pkg/fmt/
/doc/
/tour/methods/13
/tour/methods/21
/tour/等不同页面。
因此目前至少可以确认：
en
ja
de多个经过 Cloudflare 的站点，都已经出现真实的 Cloudflare IndexNow activity。
这已经很难用单站偶发现象解释了。
十四、反过来看中文 Go Tour，仍然还是 Get Started
这个对比特别有意思。
英文、日语、德语已经大量出现：
Source = Cloudflare但中文 A Tour of Go：
go-dev.shuijingwanwq.com目前依然还是：
Get Started中文 Go Tour 和其他语言站有一个重要区别：
中文：
EdgeOne
非中文多个 locale：
Cloudflare所以中文站本身不会经过 Cloudflare Crawler Hints 这条链路。
这至少可以解释：
为什么其他语言站已经不断出现 Cloudflare 来源，而中文站完全没有这种记录。
但这仍然不能说明：
中文站之前的直接 IndexNow 提交没有作用。
因为直接提交接口确实成功返回过 200。
只是目前 Bing Webmaster Tools 还没有提供足够明显的 Dashboard evidence。
十五、所以现在我怎么看“直接提交”和“Cloudflare Crawler Hints”
经过这次实测以后，我现在会把它们看成两个层次。
第一次上线：自己做完整 bootstrap
对于新语言站，我仍然会主动做一次全站 IndexNow bootstrap。
原因是它能明确把当前正式 Sitemap 中的 URL 主动通知出去。
流程是：
production_state=live
→ 验证 Key
→ 获取 sitemap
→ homepage probe
→ 202 则等待
→ 200 后 bulk submit这相当于：
新站刚上线时，主动告诉 IndexNow 生态“这些页面现在都存在”。
后续正常变化：交给 Cloudflare Crawler Hints
新站第一次 bootstrap 完成以后，我不会周期性地把整个网站重新提交一遍。
对于走 Cloudflare 的语言站，后续更多依靠：
Sitemap
+
Cloudflare Crawler Hints目前从 Bing Webmaster Tools 的实际表现来看，Crawler Hints 的存在感甚至比我的手工 bulk submit 强很多。
十六、最后把 IndexNow bootstrap 做成了正式 Go CLI
手工测试几轮以后，每增加一门语言都重复执行：
找 hostname
→ 生成 Key
→ 验证 Key
→ 读取 Sitemap
→ 校验 URL
→ probe
→ 等 202
→ 再 probe
→ bulk submit实在比较繁琐。
所以最后直接把 IndexNow bootstrap 做进了 A Tour of Go 多语言项目的正式 Go CLI。
现在新 locale 最后只需要执行：
go run -mod=readonly ./cmd/tour-i18n indexnow bootstrap \
--locale <locale> \
--key-file /secure/path/<key>.txt程序会自动：
读取 production/identity.json
→ 只接受 production_state=live
→ 验证公网 root key
→ 获取正式 /sitemap.xml
→ 校验 HTTPS
→ 校验 hostname
→ 拒绝重复 URL
→ sitemap URL 数量 1..10000
→ homepage probe
→ 202 时停止等待
→ 200 后提交剩余 N-1
→ submitted_urls=N最后还拿意大利语站做了真实 production smoke：
IndexNow bootstrap: PASS
locale=it-IT
sitemap_urls=105
submitted_urls=105从此以后，新增加一门语言的最终搜索引擎 closeout 也固定下来：
Google Search Console
→ Bing Webmaster Tools
→ locale-specific search engine
→ IndexNow bootstrap十七、为什么我还是会保留自己的 IndexNow bootstrap
看到 Cloudflare 这么快以后，其实很容易产生一个问题：
既然 Cloudflare Crawler Hints 已经这么积极，还有没有必要自己做一次全站提交？
我现在的答案仍然是：
有必要，但只做一次。
因为两者职责并不完全一样。
自己做 bootstrap：
新站上线
→ 当前 Sitemap 的全部正式 URL
→ 一次性主动通知Crawler Hints：
网站后续运行
→ Cloudflare 观察到变化
→ 持续提供 URL hints而且不是所有站都一定使用 Cloudflare。
像中文 A Tour of Go 目前走的就是 EdgeOne。
因此项目自身拥有一个不依赖特定 CDN 的标准 IndexNow bootstrap，还是有意义的。
十八、IndexNow 对我最大的价值，并不只是 Bing
一开始研究 IndexNow，我主要看的还是 Bing。
但做完以后，我觉得它真正吸引我的地方其实是：
一次提交，可以增加被多个支持 IndexNow 的搜索引擎发现的机会。
Google 和百度目前还是各走自己的发现、抓取和提交流程。
但除此之外，互联网上还有很多规模更小的搜索引擎。
如果它们支持 IndexNow，我就没有必要为了每一家：
单独注册站长平台
→ 单独验证域名
→ 单独提交 Sitemap
→ 再单独维护我的多语言站点仍然可能通过 IndexNow 获得额外的 URL discovery 机会。
对于几十门语言这种规模来说，这种“一次标准化接入，覆盖更多搜索渠道”的价值会越来越明显。
哪怕最后只多带来一小部分长尾流量，也是额外收益。
十九、这次折腾以后，我得到的几个结论
第一，新 Key 第一次出现：
HTTP 202不用急着换 Key。
等待 validation 后再试即可。
第二：
HTTP 200仍然是我判断 IndexNow 接口提交成功的主要 machine evidence。
第三，不要期待 Bing Webmaster Tools Dashboard 实时反映接口结果。
我已经真实遇到过：
API 早就 200
→ Dashboard 长期 Get Started甚至专门重新做干净实验以后也是如此。
第四，后来 Dashboard 确实开始显示 Self 记录，所以自己直接提交不是完全没有 evidence。
但目前我仍然无法从 Dashboard 证明：
前一天自己 bulk submit 的所有几千个 URL 都已经逐条显示。
第五，Cloudflare Crawler Hints 的效果非常直观。
英文站一度显示：
过去 3 小时：565
Source：Cloudflare日语、德语站也在持续产生 Cloudflare 来源记录。
第六，目前从 Bing Webmaster Tools 的“可见结果”来看：
Cloudflare Crawler Hints 比自己的直接提交明显得多。
至于是不是 Cloudflare 实际处理得更快，还是 Bing Dashboard 对 Cloudflare 来源的 reporting 更及时，目前没有足够 evidence 可以下结论。
第七，IndexNow 并不能保证索引。
它解决的是：
主动通知
→ 增加发现机会
→ 增加抓取机会最终是否进入索引还是搜索引擎自己的判断。
但对于我的多语言项目来说，还有另外一层意义：
越多支持 IndexNow 的搜索引擎能够发现这些页面，就越有机会获得来自不同国家、不同搜索引擎的一部分长尾流量。
这也是我最终决定把 IndexNow 正式加入新 locale 上线流程的主要原因之一。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 简体中文：A Tour of Go 简体中文版
✅ 日语：A Tour of Go 日语版
✅ 德语：A Tour of Go 德语版
✅ 法语：A Tour of Go 法语版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前已上线简体中文、日语、德语和法语版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。