IndexNow 看起来简单得离谱,协议也确实简单:带着一个能证明你控制该主机的密钥,POST 一批 URL。真正难的部分全在这个请求之外。这些是 indexsubmit 在大规模运行 IndexNow 管线时积累的实战笔记。
密钥,一次就够
所有参与的引擎——Bing、Yandex、Seznam——读取你站点根目录下的同一个密钥文件(/{key}.txt,必须在根目录,不能放子目录)。一个通过验证的密钥覆盖所有参与协议的引擎,不需要按引擎维护密钥。
两条实用规则:
- 密钥文件必须以 200 返回,响应体就是密钥本身。重定向会破坏验证。
- 迁移主机或 CDN 后,再次推送前先重新验证——引擎取不到密钥时会静默丢弃你的提交,没有任何提示。
indexsubmit 按主机验证密钥并持续复检,因为这种失败模式是无声的。
去重是你的责任,不是协议的
IndexNow 没有内建幂等性。如果你的 CMS 因为草稿保存了两次而对同一 URL 触发三次提交,那就是三次提交。引擎能容忍,但你在消耗好感,也模糊了自己的信号:当所有东西都被提交时,你无法分辨哪些 mattered。
有效的纪律是按内容版本去重,而不是按 URL。一条渲染内容自上次推送后没有变化的 URL 不需要再推;内容变了就要推——哪怕一小时前刚推过。
indexsubmit 的每个推送任务都携带每条 URL 的内容版本;批次内的重复会合并,每次提交的结果——accepted、failed、rate_limited、unknown——逐 URL 记录并接受审计。
每家引擎的真实行为
Bing 是实现最完整的:收录快、索引影响可见、IndexNow 面板细节最多。如果你的流量主要来自 Google,跳过 IndexNow 很诱人。别:Bing 的索引会反哺许多其它展示面,今天的收录是明天"存在于那里"的前提。
Yandex 完整参与协议,行为与文档一致。对流量是否有用取决于你的受众,但提交管线本身表现正常。
Seznam(捷克市场)也参与。如果你不做那个市场,包含它的成本是零——同一个请求就会到达它。
所有引擎都不会做的事,也是大家最容易忽略的:确认不等于收录。200 或 202 只表示"已接收",对这条 URL 是否会被收录、会不会被保留只字未提。闭环的唯一方式是事后检查判定——那是 URL Inspection 的问题,不是 IndexNow 的。
一条经得起现实的管线
最小可用生产管线:
发布(或内容变更)时:
1. 计算 URL 的内容版本
2. 入队 {url, version} —— 与上次推送的版本去重
3. 分批(小批次胜过一个巨型请求)
4. 携带密钥 POST 到 api.indexnow.org
5. 逐 URL 记录结果:accepted | failed | rate_limited | unknown
6. 之后:检查该 URL 的索引判定;被推送的 URL 一直进不了索引就告警要为两种失败模式做好设计:
- 限速。 推得太猛时引擎返回 429。按主机退避;不要盲目重试整个批次。
unknown(未知)结果出现在网络错误时——把它们当作"花了钱但结果未验证",绝不能静默重放。 - 从不闭合的循环。 只推送的团队永远不知道推送有没有用;只检查的团队永远无法加速发现。价值在配对:发布时推送、用检查验证、被推送的 URL 进不了索引就告警。
indexsubmit 在这之上加了什么
上面的管线正是 indexsubmit 替你运行的:按内容版本去重、小批次可审计、逐 URL 记录结果(包括 unknown——我们从不自动重放),以及验证环节:检查被推送的 URL 是否真的进入了索引,没进就告警。
如果你想自建管线,API 直接暴露提交与结果。无论哪种方式:那个 POST 只是最简单的百分之十,剩下的百分之九十才是"我们在用 IndexNow"和"IndexNow 真的有效"之间的差距。