如果你做过 SEO，一定遇到过这种抓狂时刻：页面已经更新了，甚至你自己都检查过很多遍没问题，但搜索引擎就是不来抓，或者抓了很久才反映到索引里。IndexNow 的出现，其实就是为了解决这个“通知成本太高”的问题：与其让搜索引擎靠 sitemap 或随机抓取碰运气，不如你在页面变化时主动告诉它：这几个 URL 变了。

先把预期说清：IndexNow 不会让你立刻排名，它也不是跳过质量审核的捷径。它做的事情更像是把发现与抓取这一步变得更及时、更稳定。对于内容更新频繁、URL 量比较大、或者经常下架产品的站点，IndexNow 往往能让“变化被看见”的速度快一截，间接减少旧信息造成的误导和跳出。

一句话理解 IndexNow：你发“变更清单”，引擎按清单来抓

传统方式里，sitemap 像是一张全量目录，搜索引擎会定期来读，但它并不知道哪些 URL 真的变了。IndexNow 更像增量更新：你新增了页面、改了内容、删了产品，就把这些 URL 打包成请求发出去。引擎收到后，会把它们加入待抓取队列。你不用每天盯着它有没有来抓，但你能把“我已经通知了”这件事做成确定性动作。

什么时候值得用（以及什么时候别浪费时间）

  • 值得用：产品经常上下架、价格/库存经常变；新闻/博客更新频繁；大站点抓取预算紧张；迁移/改版后需要更快让引擎跟上。
  • 不建议优先：站点基础技术问题一堆（robots 拦了、canonical 混乱、404 很多）；内容质量不稳定。因为这类站点的瓶颈通常不在通知，而在页面本身。

配置步骤：关键就 2 件事（key + 放对位置）

IndexNow 的配置看起来有点技术，但真正容易错的就两点：key 文件放错位置、以及 URL 版本不一致。标准做法是：生成一个 key（一串字符），然后把这个 key 作为文件名，放到你站点根目录下（也就是访问 https://example.com/{key}.txt 能直接打开的地方），文件内容也放同样的 key。这样引擎才能确认你有权限代表这个站点发送通知。

你完成 key 文件之后，就可以开始推送 URL 了。推送的 URL 要和你的网站最终版本一致：全站是 https 就不要推 http；你统一了不带 www 就不要推带 www。很多人推送成功了却没效果，最后发现是 URL 版本混用，等于你在通知一个并不存在的站点版本。

最小可用的推送节奏：先手工跑通，再考虑自动化

新手不需要一上来做复杂集成，你可以先用最小动作跑通：每次发布文章/上新产品时，把 URL 记录到一个列表里，凑够 10～50 个就推送一次。等你确认“推送—抓取—索引更新”的链路是通的，再考虑自动化（例如 CMS 发布后自动推送）。这样做的好处是：你能知道问题出在哪一步，而不是一开始就把系统搞复杂。

POST https://api.indexnow.org/indexnow
{
  "host": "example.com",
  "key": "YOUR_KEY",
  "keyLocation": "https://example.com/YOUR_KEY.txt",
  "urlList": [
    "https://example.com/page-a",
    "https://example.com/page-b"
  ]
}

验收：你怎么知道自己配置对了？

  • 用浏览器能打开 key 文件（返回码 200），内容就是那串 key。
  • 推送的 URL 在站点里能正常访问（非 404/非跳转到另一个版本）。
  • 过一段时间后，在 Bing Webmaster Tools 里能看到抓取/索引趋势变化（不用追求秒收录，但至少应当更稳定）。

常见坑：推送了不该推的 URL，结果把站点搞乱了

最常见的问题是推送了 noindex 页面、参数页、站内搜索页，等于你在主动邀请引擎来抓一堆你自己都不想被收录的内容。正确做法是：先把站点的索引策略理清楚（哪些该收录、哪些不该），再把推送范围限定在确实需要被发现的页面。如果你担心索引膨胀，先读这篇：索引膨胀怎么控。

延伸阅读

参考资料