要完成 IndexNow 协议接入，应先生成并公开部署验证密钥，再在网页新增、更新、删除或迁移正式生效后，通过 IndexNow API 提交对应的规范 URL，最后使用接口状态码、服务器日志和搜索引擎站长工具分层验证。IndexNow 是一种网页变更通知协议，作用是让网站主动告诉支持该协议的搜索引擎“某个 URL 已发生变化”，从而帮助搜索引擎更及时地发现待抓取内容。

IndexNow 协议接入与网页更新主动推送指南：配置、调用与验证实操

IndexNow 发送的是变更信号，不保证搜索引擎立即抓取、收录或提升排名。页面能否进入索引，仍取决于可访问性、内容质量、canonical、robots、noindex、站点信誉及搜索引擎自身策略。

一、明确 IndexNow 的适用场景

适合主动推送的变更

  • 文章、新闻、公告、职位或活动页面正式发布。
  • 商品价格、库存、描述或结构化数据发生实质变化。
  • 页面永久删除并开始返回 404 或 410。
  • 旧 URL 通过 301 永久迁移到新 URL。
  • 网站改版或大量页面完成公开迁移。

不应提交的 URL

  • 内容没有实际变化的页面。
  • 带跟踪参数、会话参数或无价值筛选参数的重复 URL。
  • 后台管理页、预览页、带访问令牌的地址及用户私有页面。
  • 不属于已验证主机名的第三方 URL。
  • 不希望进入搜索结果的测试或开发环境地址。
一、明确 IndexNow 的适用场景

二、接入前完成四项检查

1. 确认能够部署密钥文件

IndexNow 通过密钥文件验证提交者对网站的控制权。最简单的方式是把密钥文件部署在网站根目录。也可以使用 keyLocation 指定其他位置，但密钥文件必须可由搜索引擎公开访问，并且可提交范围会受到文件所在路径的限制。

2. 统一协议、主机名和规范 URL

http://example.com、https://example.com 与 https://www.example.com 是不同入口。应先确定最终使用的 HTTPS 主机名，并让 canonical、内部链接、XML Sitemap 和 IndexNow 提交地址保持一致。

3. 找到真实的内容变更事件

优先从 CMS 发布事件、商品数据库更新、后台审核结果或部署流水线触发推送。不要依靠定时扫描全站来制造提交任务，否则容易重复通知未变化的页面。

4. 保留 XML Sitemap

IndexNow 用于及时通知增量变化，XML Sitemap 用于描述站点整体 URL 集合和更新时间，两者功能不同。接入 IndexNow 后仍应维护 Sitemap。

三、步骤一：生成并部署 IndexNow 密钥

1. 生成密钥

IndexNow 密钥长度应为 8 至 128 个字符，可使用字母、数字和连字符。生产环境建议生成足够长的随机值；使用十六进制随机字符串是一种简单且合规的做法。

openssl rand -hex 32

以下示例假设密钥为：

7f18b2d9c04e61a3845f987ca321de90

2. 创建密钥文件

常见做法是让文件名与密钥一致并添加 .txt 后缀，文件正文只包含密钥本身：

文件名：7f18b2d9c04e61a3845f987ca321de90.txt
文件内容：7f18b2d9c04e61a3845f987ca321de90

3. 部署并检查文件

推荐的公开地址如下：

https://www.example.com/7f18b2d9c04e61a3845f987ca321de90.txt

执行检查：

curl -i https://www.example.com/7f18b2d9c04e61a3845f987ca321de90.txt

正确结果应同时满足：

  • HTTP 状态码为 200。
  • 响应正文与密钥逐字符一致，不包含 HTML、引号或说明文字。
  • 访问不需要登录、Cookie、验证码或来源校验。
  • 没有被 CDN、防火墙或访问控制规则拦截。
  • 尽量直接返回文件，避免不必要的重定向。

四、步骤二：使用 GET 接口推送单个 URL

首次连通性测试或低频更新可以使用 GET 请求。使用命令行时，通过 --data-urlencode 对参数进行编码：

curl -G 'https://api.indexnow.org/indexnow' \
  --data-urlencode 'url=https://www.example.com/products/sku-1001' \
  --data-urlencode 'key=7f18b2d9c04e61a3845f987ca321de90' \
  --data-urlencode 'keyLocation=https://www.example.com/7f18b2d9c04e61a3845f987ca321de90.txt'

url 必须是完整的绝对 URL，且其主机名应与密钥验证范围一致。GET 方式适合手工测试，不适合大量页面持续更新。

五、步骤三：使用 POST 接口批量推送 URL

批量提交使用 JSON 请求体，一次最多可提交 10000 个 URL。生产环境可根据队列规模和失败重试成本拆成较小批次，例如每批 100 至 1000 个 URL。

curl -X POST 'https://api.indexnow.org/indexnow' \
  -H 'Content-Type: application/json; charset=utf-8' \
  -d '{
    "host": "www.example.com",
    "key": "7f18b2d9c04e61a3845f987ca321de90",
    "keyLocation": "https://www.example.com/7f18b2d9c04e61a3845f987ca321de90.txt",
    "urlList": [
      "https://www.example.com/products/sku-1001",
      "https://www.example.com/products/sku-1002",
      "https://www.example.com/news/update-2025"
    ]
  }'

批量请求的关键约束

  • host 只填写主机名，不包含协议、路径或结尾斜杠。
  • urlList 中使用完整绝对 URL。
  • 同一批 URL 应属于声明的 host，不同子域名分批提交。
  • 提交地址应使用网站实际采用的协议和规范主机名。
  • 请求体使用 UTF-8 编码，并由标准 JSON 序列化工具生成。

六、步骤四：接入网站发布与更新流程

生产环境应在内容公开生效后自动创建提交任务，并通过异步队列调用 IndexNow，避免外部接口超时影响文章发布、商品更新等核心业务。

推荐处理流程

  1. 用户或系统发布、修改、下架内容。
  2. 业务数据库事务成功提交。
  3. 静态页面生成、缓存刷新或 CDN 更新完成。
  4. 记录规范 URL、事件类型、内容版本和发生时间。
  5. 将 URL 写入可靠的 IndexNow 消息队列。
  6. 对短时间内重复出现的 URL 去重并按主机名分组。
  7. 组装批量请求并调用接口。
  8. 记录批次编号、状态码、响应时间和重试次数。
  9. 对可重试错误执行退避，对配置错误触发告警。

业务事件与提交动作

业务事件网站处理IndexNow 动作
新页面发布页面公开返回 200提交新 URL
正文、价格或库存更新页面与结构化数据已更新提交原 URL
页面永久删除原 URL 返回 404 或 410提交原 URL
URL 永久迁移旧 URL 301 到新 URL提交旧 URL 和新 URL
草稿或预览修改尚未公开发布不提交

设置去重与防抖

同一页面可能在一次发布中连续触发正文、图片、库存和缓存事件。可设置 30 秒至数分钟的聚合窗口，只保留同一 URL 的最新版本；同时设置最长等待时间，避免持续变更导致任务一直不提交。

七、步骤五：处理删除、重定向和批量迁移

删除页面

永久删除后，应先让原 URL 返回 404 或 410，再提交该 URL。只发送通知但继续返回 200，搜索引擎无法通过抓取确认页面已被删除。

URL 永久迁移

配置旧 URL 到新 URL 的 301 重定向，同时更新 canonical、内部链接和 XML Sitemap，然后提交新旧两个 URL。旧 URL 用于通知原地址状态变化，新 URL 用于通知新的内容位置。

全站批量变更

网站改版时应先生成旧 URL 与新 URL 的映射表，检查重定向链和循环重定向，再按主机名拆分提交批次。使用队列记录成功、失败和待重试状态，不要在短时间内无控制地反复提交数十万条 URL。

八、步骤六：分层验证接入结果

第一层：验证密钥文件

curl -sS -o /dev/null -w '%{http_code}\n' \
  https://www.example.com/7f18b2d9c04e61a3845f987ca321de90.txt

预期输出为 200。还应读取响应正文，确认其与提交密钥逐字符一致。

第二层：验证 API 响应

状态码含义处理建议
200请求已成功接收记录成功，不要立即重复提交
202请求已接收，密钥验证仍在处理检查密钥文件并稍后复查
400请求格式或参数无效检查 JSON、URL 和必填字段
403密钥验证失败检查文件名、正文、路径和访问权限
422提交内容无法按声明的主机处理重点检查 URL 是否属于 host，以及请求字段是否符合协议要求
429请求过于频繁降低并发，按服务端提示或指数退避策略重试

第三层：验证抓取与索引变化

  • 在支持 IndexNow 的搜索引擎站长平台使用 URL 检查工具查看抓取状态。
  • 检查服务器访问日志，确认搜索引擎抓取程序是否访问已提交 URL。
  • 记录提交时间、首次重新抓取时间和索引状态。
  • 分别抽样检查新增、更新、删除和重定向页面，不要只检查首页。

验收时应把“API 接收成功”“搜索引擎发生抓取”和“页面进入或退出索引”作为三个独立指标。2xx 响应只能证明通知已被接收。

九、生产环境注意事项

只在公开版本生效后提交

数据库保存成功不一定代表页面已经可以从公网访问。存在审核、静态生成、缓存刷新或 CDN 发布流程时，应在最终页面状态稳定生效后再发送通知。

不要把外部调用放进主事务

IndexNow 接口超时不应导致内容发布失败。建议先提交业务事务，再通过事务消息、outbox 模式或可靠队列异步调用接口。

区分可重试与不可重试错误

网络超时、5xx 和 429 通常可以延迟重试；400、403 和 422 多数属于请求数据或配置问题，持续重试通常无效，应转入异常队列并告警。重试时使用指数退避和随机抖动，并设置最大次数。

提交前执行 URL 安全检查

使用主机白名单、路径黑名单和查询参数清理规则，阻止后台页面、预览链接、私有内容及包含令牌或个人信息的 URL 进入提交队列。

保留审计日志但避免泄露密钥

建议记录事件来源、URL、内容版本、提交时间、批次编号、HTTP 状态码、重试次数和最终状态。普通业务日志中不要完整输出密钥，可记录不可逆摘要或密钥版本标识。

十、监控指标与上线验收

  • 队列延迟：页面公开到任务进入推送队列的时间。
  • 提交延迟：页面公开到接口返回 2xx 的时间。
  • 请求成功率：2xx 请求数占总请求数的比例。
  • 重复提交率：统计周期内相同 URL 被重复提交的比例。
  • 错误分布：按 400、403、422、429、5xx 和网络超时分类。
  • 抓取延迟：提交时间到搜索引擎首次重新抓取的时间。
  • 队列积压：尚未处理或已达到最大重试次数的 URL 数量。

上线前至少测试新增、修改、删除、301 迁移、中文路径、带参数 URL、密钥不可访问、接口超时和限流场景，并确认单个失败批次不会阻塞后续任务。

十一、选型建议

中小型网站可以在现有 CMS、后端服务或部署流水线中增加 IndexNow 调用；多站点或高频更新系统更适合使用消息队列、统一 URL 规范化组件和集中监控平台。选型时重点检查事件来源是否准确、能否按主机分组、失败重试是否可控，以及日志能否关联具体内容版本。

如果团队还需要监测公开网页或搜索结果变化，可使用 Dataify 提供的网页采集、SERP、视频数据和通用采集 API 获取公开数据；这些能力适合数据采集与监测环节，但不能代替 IndexNow 密钥验证，也不能代替由网站控制方提交自有 URL。

十二、落地案例：电商商品更新推送

某电商站点每天产生商品上架、价格修改、库存变化和下架事件。团队在商品事务完成后写入变更队列，由消费者等待页面和 CDN 缓存更新完成，再按主机名与规范 URL 去重。

  1. 商品上架后确认详情页公开返回 200，再提交商品 URL。
  2. 价格或库存变化时先更新页面及结构化数据，再提交原 URL。
  3. 短时间内连续变化的商品使用两分钟聚合窗口，只提交最新版本。
  4. 商品永久下架后让原 URL 返回 410，并提交原 URL。
  5. 消费者每批提交 500 个 URL，出现 429 时暂停并指数退避。
  6. 监控系统关联商品版本、提交批次和搜索引擎抓取日志。

该流程的重点是确保每次通知都对应已经公开生效的真实变化，而不是单纯增加提交次数。

十三、常见问题

IndexNow 提交成功后，页面会立即被收录吗？

不会。成功响应表示变更通知已被接收，搜索引擎仍会根据页面质量、可访问性、重复内容、抓取资源和索引策略决定是否抓取及收录。

接入 IndexNow 后还需要 XML Sitemap 吗？

需要。IndexNow 适合通知增量变化，XML Sitemap 适合描述网站整体 URL 集合，两者配合使用更完整。

同一个密钥可以用于多个域名吗？

可以复用同一密钥字符串，但每个主机都必须在对应位置完成验证。为了缩小权限范围并便于轮换和排查，生产环境通常适合按主机或站点独立管理密钥。

多个子域名可以放在同一个批量请求中吗？

不应混合提交。批量请求应按主机名分组，example.com、www.example.com 和 shop.example.com 分别验证并提交。

页面删除后只提交 URL 是否足够？

不够。原 URL 还应返回 404、410 或正确的永久重定向状态，搜索引擎需要通过抓取确认页面当前状态。

出现 202 状态码应该立即更换密钥吗？

通常不需要。先确认密钥文件可公开访问、正文完全一致且没有访问拦截，再等待验证完成；如果长期无法验证或转为 403，再排查文件部署和提交参数。

一个批次提交多少 URL 合适？

协议允许一次最多提交 10000 个 URL，但不必每次填满。生产环境可使用 100 至 1000 个 URL 的批次起步，再根据更新量、接口响应时间、失败重试成本和限流情况调整。

十四、总结

IndexNow 协议接入可以归纳为四个环节：公开部署可验证的密钥文件，在页面真实变更并公开生效后提交规范 URL，通过异步队列完成去重、分组、批处理和失败重试，再通过 API 状态码、服务器日志和站长工具验证接收、抓取与索引状态。IndexNow 不能保证收录，也不能替代 XML Sitemap、规范化设置和高质量内容。

常见问题

IndexNow 是什么，接入时要完成哪些操作？

IndexNow 是一种网页变更通知协议。接入时需要生成并部署公开可访问的密钥文件，在页面新增、修改、删除或迁移生效后调用 API 提交规范 URL，再通过接口响应、访问日志和站长工具验证结果。

IndexNow 提交成功后，页面会立即被收录吗？

不会。成功响应只表示通知已被接收，搜索引擎仍会根据页面质量、可访问性、重复内容和自身索引策略决定是否抓取及收录。

接入 IndexNow 后还需要 XML Sitemap 吗？

需要。IndexNow 用于主动通知增量变化，XML Sitemap 用于描述网站整体 URL 集合和更新时间，两者应配合使用。

一个批次最多可以提交多少个 URL？

批量 POST 请求一次最多可提交 10000 个 URL。生产环境可根据更新规模、限流情况和失败重试成本拆成更小批次。

多个子域名可以放在同一个请求中吗？

不应混合提交。批量请求应按主机名分组，不同子域名分别完成密钥验证并分别提交。

删除页面时如何使用 IndexNow？

先让原 URL 返回 404 或 410；如果页面迁移，则配置 301。随后提交原 URL，迁移场景还应同时提交新 URL。

遇到 429 状态码怎么办？

降低并发和提交频率，采用带随机抖动的指数退避策略延迟重试，并避免对没有实际变化的 URL 重复提交。

总结

IndexNow 是用于主动通知搜索引擎网页变化的协议。完整接入流程包括部署验证密钥、在页面公开生效后提交规范 URL、通过异步队列完成去重和批处理，以及分层验证 API 接收、搜索引擎抓取与索引状态。生产环境还应处理限流、重试、删除、301 迁移和敏感 URL 过滤，并继续维护 XML Sitemap。