IndexNow IndexNow

IndexNow 是微软 Bing、Yandex、Seznam 等搜索引擎共同维护的即时索引协议：站点在 URL 新增或变更时主动推送，参与引擎几分钟内获知并安排抓取——把“被动等爬虫重访”换成“主动告知”。它解决的是收录时效，不是收录质量：推送触发的是重访，采不采信仍由内容与权限决定。对以 Bing 为检索底座的 AI 产品（ChatGPT Search、Copilot）而言，这是当前成本最低的入场动作之一。

协议怎么用：密钥、推送与节奏

接入只有两步。第一步，生成一个密钥，把对应的密钥文件放到域名根目录——文件内容就是密钥本身，引擎取到它即确认你对域名的控制权。第二步，内容变更时向协议端点 POST 变更的 URL 列表，单个或批量均可，参与方共享同一套协议规范。此后每次重要页面的发布、改版、勘误，都值得推一次。

有一条安全边界必须交代：密钥文件本质是公开的所有权证明，没有任何保密性——它必须放在全网可访问的位置，协议才能工作。因此密钥的角色类似站验证文件，而不是密码：只用于证明“这个域名归我管”，不要复用任何有价值的凭据，也不要幻想把它藏起来。

推送要有分级，不是见 URL 就推。优先推：新发布的重要页面、关键数据的勘误、结构或主题有实质变化的改版。可以推：常规内容更新、栏目页的周期性刷新。不必推：未发生变化的 URL、被 robots 禁止或加了 noindex 的页面、纯视觉微调。模板级的批量改动（比如全站标题规则调整）不要全站重推，挑核心页面推一批即可——推送的价值密度比覆盖面重要，高频重复推送未变更的 URL 不会带来额外可见度，反而稀释信号。它与 sitemap 的分工也顺理成章：sitemap 是全量地图，靠引擎按节奏来取；IndexNow 是增量事件，变了才喊。两者并行，一个保底、一个提速。

在功能谱系上，IndexNow 接的是老一代“主动通知”接口的班，但把多引擎共享、密钥验证、批量推送收进了统一规范，工程上省心得多。接入位置也有讲究：把推送挂进发布流程——内容管理系统的发布钩子、部署脚本的收尾步骤——而不是靠人记得。人工推送必然漏，工程化之后每次重要变更的边际成本接近零，纪律问题就变成了架构问题。

为什么它是 ChatGPT 与 Copilot 的入场券

价值链要从供给结构看。ChatGPT Search 的检索底座是 Bing：实测口径下，ChatGPT 引用与 Bing 首页约 87% 重合（ChatGPT 引用与 Bing 首页重合度，未复验），Copilot 则直接消费 Bing 索引。这条依赖链上，站长侧可控的三件事构成组合：在 Bing 站长工具（Bing WMT）完成验证与收录维护、用 IndexNow 推送变更、确认没有屏蔽 OpenAI 的检索爬虫 OAI-SearchBot——三者齐备，约等于拿到 ChatGPT 与 Copilot 的入场券（引擎档案见 ChatGPT Search）。缺任何一环，后续的内容优化都在空转：内容再好，进不了 Bing 索引，就进不了这两个 AI 产品的检索池。

时效型内容是这条链路上受益最明显的场景：价格、活动、政策、版本说明，这类今天发布、明天就可能作废的信息，等重访周期等于等过期。推送把“引擎发现变更”压缩到分钟级，让时效内容的窗口期真正可用。反过来说，长青内容从推送里的获益有限——它的对手不是发现时机，而是内容本身的质量与权重。对中文团队还要补一句流程提醒：Bing 站长工具的账号与验证信息常常集中在个别人手里，人员变动会让整条链路静默失效——把账号与密钥纳入交接清单，是这张入场券最不起眼也最常被忽略的保质条件。

这个入场券的适用范围也要看清。协议的参与方构成决定了它主要服务 Bing 系与国际引擎；中文主流引擎的供给路径各不相同——生态内语料、第三方搜索接口——IndexNow 在那些链路上帮不上忙，想进对应引擎得按各引擎的供给结构另找入场券。它是一把好钥匙，但只开它配的那几把锁。

它不做什么：边界与误用

第一，IndexNow 不是收录保证。它把“引擎知道你变了”的延迟从重访周期压缩到分钟级，收录与否仍取决于内容质量、robots 权限与站点健康度——推送再勤，也救不回被 Disallow 的页面。第二，Google 不参与该协议——Google 体系的内容供给有自己的节奏，IndexNow 对 Google 搜索与 AI Overviews 没有直接通道，Google 侧的收录仍走它自家的机制；“IndexNow 能不能推 Google”这个常见问题的答案是干脆的：不能。第三，推送不是营销杠杆：把推送当广告位狂刷，除了污染自己的信号什么也换不来，协议的正确用法是“变了才推”。

还有一条认知边界要立住：IndexNow 改变的是“发现”的时机，不是“评估”的结果。引擎何时知道你变了，与你值不值得被收录、值不值得被引用，是两件独立的事。把它接进工作流只是把发现变量管住了，内容质量、结构、权限这些真正的功课一样都省不掉——把协议当捷径的期待，落地时都会落空。

推送之后：核对与排障

推送发出后，核对两个位置。日志侧：看参与引擎的爬虫是否在推送后回访了对应 URL——有回访说明链路通，回访后的状态码是否为 200 则反映页面本身是否健康。工具侧：在 Bing 站长工具里看对应 URL 的收录状态是否如预期更新。排障按三个常见点走：密钥文件不可访问或内容与推送的密钥不符（验证失败，推送被忽略）；URL 规范化差异（推送的地址与实际可抓取地址不一致，带不带斜杠、协议与主机名写法要统一）；robots 权限冲突（页面本身被禁止时，推送只会换来一次无效回访）。把这三点当作接入时的自检清单，多数“推了没反应”都能就地定位。

排障还有一个容易被忽略的前置项：推送之前先确认页面真的对爬虫可见。渲染依赖、跳转链、防爬中间件，都会让回访拿到与预期不符的内容——这类问题表现在推送“无效”，根因却在页面层。把“回访实际拿到了什么”作为排障的第一问，能省掉大部分弯路。

与 robots.txt、llms.txt 的分工

IndexNow 常与另外两个 AI 时代的名字混为一谈，三者分工其实清晰：robots.txt 管权限，允不允许爬、分用途允不允许（robots.txt（AI 语境））；IndexNow 管时效，变了就喊一嗓子；llms.txt 管导览，给 AI 一份站点内容地图与使用说明（llms.txt）。三者中，IndexNow 的机制反馈最确定——推送之后有抓取行为可核对；llms.txt 则相反，据 Ahrefs 对 13.7 万域名的统计，28% 的站点已发布该文件、97% 的文件全月零请求（llms.txt 采纳与请求研究），被动声明几乎无人消费。预算与注意力的排序因此很清楚：优先做有确定机制反馈的通道——收录、推送、可达性——把被动声明当作顺手补齐的一笔，而不是 GEO 的主战场。

维护成本也该摊到明面上：三个东西都不贵，贵的是注意力。我们建议把三项检查并进同一个季度例程——robots 分组是否仍然表达当前意图、推送链路在发布流程里是否还通、llms.txt 是否还与站点结构一致。协议层面的腐化是静默的：推送失败没人报错，规则过期没人报警，季度例行是把这类静默失效捞出来的最低成本方式。