IndexNow 自动提交怎么做：密钥、接口、失败重试与收录边界

IndexNow 解决的是“变化通知”，不是“收录保证”

IndexNow 是一套让站点主动通知参与搜索引擎“某个 URL 新增、更新或删除”的协议。它把“等爬虫下一次发现变化”改成“站点在发生变化时发送通知”，适合新闻、教程、商品、活动和频繁维护的公开页面。 但它只改变发现与抓取调度的入口，不替代搜索引擎自己的质量判断、索引策略和展示策略。

本文以 ZenLeak 当前的 Astro + Node 实现为例，完整说明密钥、验证文件、单页提交、批量提交、自动触发、失败重试和后台台账应该怎样设计。文中把“接口已接收”“搜索引擎已抓取”“页面已建立索引”和“页面被 AI 引用”严格分开。

它和 sitemap、robots.txt、百度主动提交有什么不同

这些入口经常被放在同一个“SEO 配置”清单里，但它们解决的问题并不相同。一个页面可以同时出现在 sitemap、站内内链和 IndexNow 台账中；它们互相补充，而不是互相替代。

对教程站来说，合理顺序是：先保证正式 URL、正文、canonical、robots 和 sitemap 正常，再把真实新增或修改的 URL 通过 IndexNow 通知。不要用批量重复提交来替代内链、页面质量或索引问题排查。

创建密钥与放置验证文件

IndexNow 使用一个站点所有者可控制的密钥文件验证主机。最简单的做法是生成 8 到 128 位由字母、数字或短横线组成的随机字符串，把它保存为根目录下的 {密钥}.txt，文件正文只放密钥本身。

例如，不要把下面的占位值直接用于生产：

INDEXNOW_KEY=replace-with-a-random-key

# 文件：public/replace-with-a-random-key.txt
replace-with-a-random-key

部署后，验证地址应该能够通过正式 HTTPS 主机公开访问：https://example.com/replace-with-a-random-key.txt。打开后应只看到密钥文本，不应出现登录页、HTML 错误页、重定向到其他主机、压缩后的乱码或额外的 JSON。密钥文件可以有文本文件末尾换行，但正文不能混入注释或另一把密钥。

如果验证文件不放在根目录，而是放在同一主机的其他路径，提交请求必须显式带上 keyLocation。同时要注意验证文件所在路径决定这把密钥可以覆盖的 URL 范围；ZenLeak 当前采用根目录文件，并要求验证地址是本站 HTTPS 主机上的 .txt 文件。

单 URL 与批量 URL 提交

变更量很小的时候，单 URL 提交便于定位问题；发布一批相互关联的页面时，可以使用 JSON 批量提交。无论使用哪种方式，都应只提交确实新增、更新或删除的公开 URL，并使用规范的 HTTPS 地址，不要把带有追踪参数、锚点或后台路径的 URL 当作正文版本提交。

单 URL 的请求形式可以写成：

curl -i "https://api.indexnow.org/indexnow?url=https%3A%2F%2Fexample.com%2Fguide%2F&key=replace-with-a-random-key&keyLocation=https%3A%2F%2Fexample.com%2Freplace-with-a-random-key.txt"

批量 JSON 请求的核心结构如下：

curl -i -X POST "https://api.indexnow.org/IndexNow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "host": "example.com",
    "key": "replace-with-a-random-key",
    "keyLocation": "https://example.com/replace-with-a-random-key.txt",
    "urlList": [
      "https://example.com/guide/",
      "https://example.com/case/"
    ]
  }'

官方文档允许批量请求一次携带最多 10,000 个 URL，但“协议允许的最大数量”不是“每个站点每天都应该提交的数量”。小站更应该按真实变更拆成小批次，这样后台台账能准确回答哪一批页面在什么时候被接口接收，也更容易处理错误和重试。

自动提交应该在什么时机触发

自动化的关键不是定时重复调用，而是识别内容版本是否真正发生变化。推荐把提交动作放在发布流程的成功阶段：正文和元数据写入完成、公开 URL 返回 200、canonical 与 sitemap 已更新之后，再把该 URL 放入待提交队列。删除或永久迁移页面时，也要根据协议和平台能力通知相应 URL 的变化。

1. 产生版本。为页面保存发布日期或修改日期，并生成稳定的内容版本标识。
2. 完成公开检查。确认 HTTPS、规范 URL、正文、robots 和 canonical 没有异常。
3. 写入待提交队列。相同 URL 和相同版本合并，避免一次编辑触发多条重复任务。
4. 分批通知。按批大小发送，并保存请求时间、URL 数、响应状态和错误摘要。
5. 等待后续证据。把接口结果、抓取日志、站长平台索引状态和 AI 引用测试分别记录。

ZenLeak 后台目前把公开栏目页、教程、实验记录和公开 AI 动态汇总成页面目录。教程使用最近修改日期，实验和动态使用各自的版本日期；只有新增页面或版本变化的页面会显示为待提交。这个台账是“应该通知哪些页面”的应用层判断，不是搜索引擎已经处理这些页面的证明。

重复提交、失败重试与限流

失败重试需要有边界。网络超时、上游暂时不可达和 HTTP 429 可以进入延迟重试；密钥无效、URL 不属于主机、请求格式错误则应先修复配置，不应立即原样重放。重试任务必须保留原始失败记录，否则后台只显示“最后一次成功”，会掩盖系统曾经丢失的通知。

重试策略至少应该包含指数退避、最大尝试次数和死信记录。例如第一次失败后等待 1 分钟，第二次等待 5 分钟，第三次等待 30 分钟；超过次数就标记为“需要人工处理”，而不是无限循环。具体间隔要服从服务商返回的 Retry-After，并结合站点规模调整。

后台应该显示哪些状态

一个只显示“成功 / 失败”的按钮不足以支持 SEO 或 GEO 复核。后台至少需要把页面状态、提交运行、搜索平台结果和 AI 观察分成几层。IndexNow 本身只负责其中的通知层。

例如，后台可以写成“2026-09-26 10:20，IndexNow 接口 HTTP 200，已接收 1 个 URL；百度抓取状态未知；Google Search Console 检查未配置；AI 引用尚未测试”。这比一个绿色“已收录”更诚实，也更能指导下一步工作。

为什么提交成功仍然可能没有收录

搜索引擎在收到通知后仍会根据自己的调度、抓取预算、页面可访问性、重复内容、canonical、质量信号和索引策略决定是否请求页面以及是否建立索引。IndexNow 不能绕过 robots、权限、服务器错误、noindex、重复页面或质量判断，也不能把一个没有清晰答案的页面变成可引用来源。

这也是 IndexNow 和 GEO 之间最容易被误解的地方：快速通知可能缩短“变化被发现”的等待，但 GEO 仍然需要清晰实体、直接答案、就近证据、稳定页面版本和可复核来源。即便搜索结果里出现页面，也要独立测试某个 AI 平台是否检索到、是否采用了页面内容、是否显示了来源以及来源是否真的支持回答。

ZenLeak 当前实现与使用方式

ZenLeak 的 IndexNow 配置由服务器环境变量控制，密钥不进入浏览器代码。后台页面会显示当前站点、验证文件路径、公开页面总数、待提交数量和最近运行历史；密钥本身不会在后台接口响应中返回。

INDEXNOW_ENABLED=true
INDEXNOW_AUTO_SUBMIT_ENABLED=false
INDEXNOW_KEY=你的随机密钥
INDEXNOW_BATCH_SIZE=100
# INDEXNOW_KEY_LOCATION=https://zenleak.cn/你的随机密钥.txt
# INDEXNOW_SUBMISSION_CACHE_FILE=/var/lib/zenleak/indexnow-submission.json

默认保持自动提交关闭更适合刚接入的站点：先从后台手动提交一页，确认验证文件、请求体、响应状态和台账写入都正常，再决定是否在发布成功后自动推送。自动开关应该由服务器配置控制，不应让未登录的前台访客直接触发。

当前后台支持“提交待更新”“全部重提”和单页提交。这里的“全部重提”适合密钥变更、整站迁移或需要重新建立通知台账的场景，不适合日常每天重复点击。日常发布优先使用待更新队列，失败记录按状态码处理，后续再结合站长平台和服务器日志复核。

常见问题

上线前检查清单

• 密钥是随机值，符合协议格式，没有写入前端代码或公开配置文件。
• 正式 HTTPS 主机可以直接打开 {密钥}.txt，正文只有密钥。
• 提交的 URL 属于正式主机，使用规范路径，不带追踪参数和锚点。
• 页面在提交前已经完成正文、canonical、robots、sitemap 和公开访问检查。
• 后台区分新页面、版本更新、已接收、失败、重试和需要人工处理。
• HTTP 200/202 只记为接口接收或接受，不写成已抓取、已收录或已引用。
• HTTP 403、422 和 429 有针对性的修复或退避策略，不无限重放。
• 自动提交只由真实内容变更触发，保留批次、时间、状态和错误历史。
• 百度普通收录、其他搜索平台索引状态和 AI 引用观察分别建账。
• 每次发布后保留线上 URL、响应、版本和后续复核日期，方便重新验证。

延伸阅读

• IndexNow 官方技术文档
• IndexNow 官方 FAQ
• Bing Webmaster：IndexNow 入门
• Google Search Central：sitemap 概览
• 百度搜索资源平台：普通收录
• robots、sitemap 和 llms.txt：GEO 技术基础配置
• 百度已经收录，为什么 AI 仍然不引用？