IndexNow 工作原理与网站部署方法：从密钥配置到提交验证

借助 Dataify 的网页采集与 SERP 数据能力可以辅助检查页面状态和搜索可见性，但 IndexNow 本身的部署核心是：在网站上放置验证密钥，并在页面新增、更新或删除后，通过协议接口主动通知支持该协议的搜索引擎。

完整落地流程可以概括为“生成密钥、公开密钥文件、提交变更 URL、记录接口结果、持续验证抓取与收录”。通常不需要把全站 URL 每天重复提交，也不能把接口返回成功等同于页面已经收录或获得排名。

一、IndexNow 是什么，工作原理是什么

IndexNow 是一种搜索引擎通知协议。传统模式主要依赖搜索引擎周期性抓取网站、读取站点地图或沿链接发现页面；部署 IndexNow 后，网站可以在内容发生变化时主动发送 URL，帮助支持该协议的搜索引擎更快获知变更。

一次标准提交的处理链路

1. 网站发布、更新或删除一个可公开访问的 URL。
2. 网站程序将发生实质变化的 URL 写入提交队列。
3. 程序向 IndexNow 接口发送域名、密钥、密钥文件地址和 URL 列表。
4. 接口验证密钥以及 URL 是否属于申报的主机。
5. 接口接受请求后，搜索引擎自行决定是否抓取、何时抓取以及是否建立索引。

因此，IndexNow 解决的是“通知发现”问题，不会绕过搜索引擎的质量判断。页面存在禁止抓取、禁止索引、错误 canonical、软 404、内容质量不足或服务器不可访问等问题时，即使提交成功也可能不被收录。

适合优先部署的场景

• 商品价格、库存和上下架状态频繁变化的电商网站。
• 职位、房源、票务、金融行情等时效性较强的平台。
• 新闻、帮助中心、产品文档和内容管理系统。
• URL 数量较多，依靠常规抓取难以及时发现变化的网站。
• 需要在页面删除后及时通知搜索引擎重新检查 404 或 410 状态的网站。

二、部署前先完成四项检查

1. 确认目标搜索引擎支持情况

不同搜索引擎对 IndexNow 的支持情况可能变化，部署前应查看目标搜索引擎当前的官方说明。不要默认所有搜索引擎都支持该协议，也不要用 IndexNow 取代 XML Sitemap、站内链接和搜索站长平台。

2. 统一网站的规范域名

明确网站实际使用的是 HTTPS 还是 HTTP、带不带 www，以及是否存在子域名。提交的 URL、请求中的 host 和密钥文件所在主机必须保持一致。已经跳转到新域名的旧 URL不应继续作为主要提交对象。

3. 检查页面是否允许索引

抽样检查目标页面的 HTTP 状态码、robots.txt、页面级 robots 指令和 canonical。正常内容页通常应返回 200，并将 canonical 指向正确的规范 URL；已永久删除的页面可以返回 410，或在确实不存在时返回 404。

4. 建立变更来源

自动提交需要明确触发点，例如 CMS 发布事件、商品状态变更、数据库更新任务或部署流水线。若系统无法识别哪些 URL 发生了变化，应先建立变更日志或消息队列，避免每次发布都推送全站。

三、生成并部署 IndexNow 密钥

步骤 1：生成密钥

生成一个不易猜测的字符串作为密钥。根据协议要求控制字符和长度，并避免使用域名、公司名称等容易被猜到的内容。例如可以使用系统提供的安全随机数工具：

openssl rand -hex 32

假设生成结果为 YOUR_INDEXNOW_KEY。生产环境必须替换为真实密钥，不要直接使用示例值。

步骤 2：创建密钥文件

在网站公开目录创建与密钥同名的文本文件，例如：

/YOUR_INDEXNOW_KEY.txt

文件内容只保留密钥本身：

YOUR_INDEXNOW_KEY

最简单的部署方式是将文件放在站点根目录，使其能够通过“站点域名/密钥.txt”直接访问。如果必须放在其他位置，提交时需要通过 keyLocation 明确指定完整地址，并确保该地址与提交域名符合协议要求。

步骤 3：验证密钥文件

部署后执行：

curl -i https://www.example.com/YOUR_INDEXNOW_KEY.txt

至少确认以下结果：

• 响应状态为 200，而不是 301、302、403 或 404。
• 响应正文与密钥完全一致，没有 HTML 模板或错误页。
• 无需登录、Cookie、验证码或特定请求头即可访问。
• CDN、防火墙和 robots.txt 没有阻止搜索引擎读取。

四、手动提交 URL，先验证最小链路

方法一：提交单条 URL

首次部署可先用 GET 请求测试一条刚更新的页面：

curl -i 'https://api.indexnow.org/indexnow?url=https%3A%2F%2Fwww.example.com%2Fupdated-page&key=YOUR_INDEXNOW_KEY'

查询参数中的 URL 应进行百分号编码。若密钥文件不在默认根目录，还需要传递经过编码的 keyLocation。

方法二：批量提交 URL

生产环境更适合使用 POST 请求。一次请求最多可按协议允许的数量提交 URL，但实际部署建议分批处理，以便重试、审计和定位错误。

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

host 只填写主机名，不带协议、路径和末尾斜杠。urlList 中的 URL 应使用完整绝对地址，并与申报主机匹配。

五、把 IndexNow 接入网站发布流程

步骤 1：定义提交触发条件

建议在以下事件发生后加入队列：

• 新页面首次公开发布。
• 标题、正文、价格、库存或结构化数据发生实质变化。
• 页面 URL 被删除并开始返回 404 或 410。
• 规范 URL、重定向目标或索引指令发生变化。

浏览量变化、内部统计更新、更新时间字段无意义刷新等事件不应触发提交。

步骤 2：建立异步队列

不要让内容发布请求同步等待 IndexNow 接口。更稳妥的做法是先将 URL 写入队列，再由后台任务去重、分批和提交。即使外部接口超时，编辑发布和商品更新也不会被阻塞。

步骤 3：实现批量提交函数

下面是基于 Node.js 内置 fetch 的简化示例：

const INDEXNOW_ENDPOINT = 'https://api.indexnow.org/indexnow';
const SITE_HOST = 'www.example.com';
const INDEXNOW_KEY = process.env.INDEXNOW_KEY;

async function submitToIndexNow(urls) {
  const uniqueUrls = [...new Set(urls)].filter((value) => {
    try {
      return new URL(value).hostname === SITE_HOST;
    } catch {
      return false;
    }
  });

  if (uniqueUrls.length === 0) return;

  const response = await fetch(INDEXNOW_ENDPOINT, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json; charset=utf-8' },
    body: JSON.stringify({
      host: SITE_HOST,
      key: INDEXNOW_KEY,
      keyLocation: `https://${SITE_HOST}/${INDEXNOW_KEY}.txt`,
      urlList: uniqueUrls
    })
  });

  if (!response.ok) {
    throw new Error(`IndexNow request failed: ${response.status}`);
  }
}

生产代码还应增加请求超时、分批上限、指数退避、失败队列和结构化日志。密钥可以通过环境变量或密钥管理服务传入，但公开验证文件仍需正常访问。

步骤 4：设计重试规则

网络超时和 5xx 响应可以有限次数重试；429 应延迟并降低提交频率；密钥或归属验证相关的 4xx 错误应先修正配置，而不是持续重试。建议记录 URL、提交时间、批次编号、HTTP 状态码和重试次数。

六、不同网站的部署方法

CMS 与博客

可使用经过维护的 IndexNow 插件，或监听文章发布、更新和删除事件。启用插件后仍要检查密钥文件是否真实可访问，以及插件是否只提交公开内容，避免把草稿、预览页和后台地址发送出去。

电商和大型动态网站

将商品、分类和库存变更写入消息队列，每隔数分钟合并去重后批量提交。对高频变动字段设置最小提交间隔，避免同一商品在短时间内被重复推送。

静态网站和持续部署项目

可以在构建阶段比较当前版本与上一个版本的路由清单，只提交新增、修改和删除的 URL。提交任务应安排在生产部署成功、页面已经对外可访问之后执行。

多域名与子域名项目

不要把不同主机的 URL 混在同一个请求中。主域名、www 子域名、商城子域名和国际站应分别确认密钥验证方式，并按 host 拆分批次。

七、如何验证部署是否真正生效

第一层：验证接口请求

查看接口 HTTP 状态码。常见结果包括：

• 200：请求已被接受。
• 202：请求已接收，密钥验证可能仍在处理。
• 400：请求格式、字段或 URL 存在问题。
• 403：密钥无效或密钥文件无法通过验证。
• 422：URL 与申报主机不匹配，或 URL、密钥关系无法验证。
• 429：请求过多，需要降低频率并延迟重试。

具体状态语义应以当前协议和目标接口文档为准。200 或 202 仅代表通知被接受，不代表已经抓取、收录或获得排名。

第二层：验证搜索引擎抓取

在服务器或 CDN 访问日志中筛选目标 URL，观察支持该协议的搜索引擎爬虫是否在提交后访问。识别爬虫时不要只相信 User-Agent；对安全要求较高的网站，还应采用搜索引擎公布的 IP 验证方法。

第三层：验证索引和搜索可见性

通过目标搜索引擎的站长平台检查 URL 状态、抓取时间和索引报告。对于核心页面，还可以按固定周期记录品牌词、产品词或页面 URL 的搜索结果变化。SEO 监测团队也可使用 Dataify 提供的 SERP、网页采集和通用采集 API 获取公开页面与搜索结果数据，用于批量核验页面可访问性和搜索表现；这类监测用于评估结果，不替代 IndexNow 提交。

建议的验收测试

1. 选择一个允许索引的测试页面并修改可见内容。
2. 确认新版本已经部署，页面返回 200。
3. 提交该 URL，保存请求时间、请求体和响应状态。
4. 检查接口日志中是否存在错误或重试。
5. 在后续日志中观察搜索引擎抓取记录。
6. 通过站长平台持续检查索引状态，不以一次搜索结果作为唯一依据。

八、部署时容易忽略的注意事项

• 保留 Sitemap：IndexNow 是增量通知渠道，XML Sitemap 仍有助于搜索引擎理解完整 URL 集合。
• 只提交规范 URL：过滤参数页、会话地址、预览页、站内搜索页和重复内容。
• 提交删除 URL：页面删除后仍可提交原 URL，让搜索引擎重新检查其 404 或 410 状态。
• 不要提前提交：必须等生产页面可公开访问后再通知，否则爬虫可能抓到旧版本或错误状态。
• 控制频率：对短时间内反复变化的 URL 去重，并设置冷却时间。
• 监控密钥文件：CDN 规则、框架路由或安全策略变更可能导致密钥文件突然返回 403 或 404。
• 注意域名迁移：迁移期间应同时正确配置重定向、canonical、Sitemap 和站长平台，不能只依靠主动推送。
• 避免泄露内部 URL：提交前执行域名白名单和路径规则校验，排除后台、测试环境及包含敏感参数的地址。

九、推荐的上线检查清单

• 密钥由安全随机方式生成，生产环境未使用示例值。
• 密钥文件可以匿名访问，正文与密钥完全一致。
• host、keyLocation 和 URL 主机关系正确。
• 提交程序能够去重、分批、超时和有限重试。
• 新增、更新、删除事件均经过测试。
• 接口响应和失败原因进入日志或监控系统。
• 页面本身返回正确状态码且允许抓取、索引。
• Sitemap、canonical、robots 和重定向保持正常。
• 已经建立抓取、索引和搜索可见性的后续验证流程。

常见问题

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

不会。接口成功只表示搜索引擎接受了 URL 变更通知。是否抓取、何时抓取以及是否收录，仍取决于页面可访问性、索引指令、内容质量、重复内容判断和搜索引擎自身策略。

部署 IndexNow 后还需要提交 XML Sitemap 吗？

需要。Sitemap 用于提供网站整体 URL 清单和更新时间，IndexNow 更适合通知增量变化，两者可以同时使用。

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

应根据密钥文件位置和协议允许的验证范围配置，不能简单假设所有子域名自动共享权限。部署时按主机分别测试，并确保每批 URL 与请求中的 host 相匹配。

页面删除后是否还要提交原 URL？

可以。删除完成并确认原 URL 返回 404 或 410 后，提交该 URL 能通知搜索引擎重新检查状态。不要把已删除地址重定向到无关首页。

为什么接口返回 403？

常见原因包括密钥填写错误、密钥文件不存在、文件被 CDN 或防火墙拦截、文件内容包含额外 HTML，以及 keyLocation 与申报主机不符合验证要求。应先用匿名请求检查密钥文件。

应该多久批量提交一次？

取决于内容变化频率。新闻或高频电商站可以按分钟级队列处理，更新较少的网站可在发布事件后触发。重点是提交真实变化、做好去重，并在出现 429 时降低频率。

总结

IndexNow 的正确部署方式是先生成密钥并公开验证文件，再把新增、更新和删除的规范 URL 通过接口提交。生产环境应采用异步队列、去重、分批、超时控制和有限重试，并同时保留 Sitemap、canonical、robots 与站长平台配置。验收时要分开检查接口是否接受、爬虫是否访问以及页面是否进入索引，不能把 HTTP 200 直接理解为已经收录。