接入IndexNow，先检查平台是否已经自动支持；手动接入时，公开提供同一主机上的密钥文件，再向参与端点发送新增、修改或删除的URL。密钥文件、提交的host和URL范围要相符，收到200只代表通知被接收，不代表页面已经收录。
下面给出根目录与子目录两种配置、单条和批量请求，以及常见响应的排查方法。示例域名与密钥仅用于教学，不应直接提交给搜索引擎；本地验证也不会冒充Bing或Google的结果。
先查平台支持，别重复装两套提交器
先查现有CMS、主机或SEO插件是否已经提供IndexNow支持。如果发布、修改和删除事件已经由一处处理，就先核启用状态、触发记录与目标URL，不要为了“再保险”装第二个提交器。
两套程序可能同时报相同变化，却让你分不清哪一条记录来自哪里。更清楚的安排是指定一个主要维护入口，知道密钥或自动验证由谁管理、提交失败在哪里查看。
没有现成支持，才走手动接入。IndexNow针对参与该协议的搜索引擎共享变动通知，不能当成Google收录提交接口。参与者与平台支持以IndexNow官方FAQ的当前信息为准，不必向所有参与者反复发送相同通知。
密钥文件怎样放，才覆盖目标URL
密钥是用于验证提交者能够控制相应主机的字符串，不是你的Google、Bing或WordPress账号密码。手动配置按协议生成合格字符串，长度为8—128字符，使用其允许的字母、数字与连字符。
根目录配置最容易理解
假设教学密钥为indexnow-demo-20261018，则可在同一主机提供：
https://example.com/indexnow-demo-20261018.txt
文件以UTF-8纯文本保存，正文就是相同密钥，不是一个带菜单的网页、PDF或下载说明。实际生产要生成自己的值，下面这个公开演示值不要复用。
根目录密钥用于对应主机的URL。example.com与www.example.com是不同主机，子域也不能随便混在同一份提交中。官方协议
子目录里的密钥有范围限制
协议允许通过keyLocation指出同主机其他位置的密钥文件，但位置会影响可提交的路径范围。如果文件在https://example.com/catalog/key.txt，应按协议理解它覆盖/catalog/下的地址，不能拿来提交/help/guide/。
| 密钥位置 | 教学目标URL | 能否按这个配置提交 |
|---|---|---|
| 根目录密钥文件 | /catalog/item-a/ | 范围相符 |
/catalog/key.txt | /catalog/item-a/ | 范围相符，并提供keyLocation |
/catalog/key.txt | /help/guide/ | 不在该目录范围 |
example.com的密钥 | shop.example.com/item-a/ | 主机不符，应单独配置 |
只要有根目录配置条件，优先用它减少范围误解。密钥放在子目录却按“整个域名都验证了”提交，是常见的接入错误。
先检查公开文件，再提交一条变动URL
从未登录窗口打开密钥URL，确认只有相同字符串。再请维护者核实际响应：正常200、纯文本、没有验证码、登录限制、HTML错误页或防火墙拦截。
浏览器页面上“看见密钥”还不够。例如某个模板将它包进完整网页，或CDN仍返回旧内容，搜索引擎取得的文件就可能与配置不同。核公开地址最终发送的内容，而不是服务器里那份本地文件。
单条URL要正确编码
下面是一个请求格式教学例，不是已执行提交：
https://api.indexnow.org/indexnow?url=https%3A%2F%2Fexample.com%2Fcatalog%2Fitem-a%2F&key=indexnow-demo-20261018
url里面放要报告变化的完整地址，并正确URL编码。若原地址含查询参数，其中的&也要作为地址的一部分编码，不能让外层请求把它误读成另一个IndexNow参数。
如果使用非默认密钥位置，再带上正确编码的keyLocation。不要为了看见一次200，随便换成不属于自己或不在配置范围的页面。
批量提交怎样写，哪些地址不能混进去
批量请求使用JSON，每次最多10000个URL。它适合一批真实变化，限额不是让你每小时把全站所有地址重复报一遍。批量提交格式
下面是根目录密钥的教学请求体：
{
"host": "example.com",
"key": "indexnow-demo-20261018",
"urlList": [
"https://example.com/catalog/item-a/",
"https://example.com/help/guide/"
]
}
将教学内容替换为自己的真实配置，保存为UTF-8文件indexnow-payload.json后，可以在具备curl的环境中发送。Windows下可使用下面的curl.exe形式；其他系统使用对应的curl命令。没有替换教学值前不要执行。
curl.exe --request POST "https://api.indexnow.org/indexnow" --header "Content-Type: application/json; charset=utf-8" --data-binary "@indexnow-payload.json"
将它以application/json; charset=utf-8发送到当前参与端点，例如https://api.indexnow.org/indexnow。这里的两个地址属于同一主机；生产时换成你控制的真实变动URL与对应密钥。
如果改用/catalog/key.txt，请求体里需要相应keyLocation，同时移除不在范围的/help/guide/。补了keyLocation字段，不会自动扩大密钥可覆盖范围。
删除内容，报告的是旧URL
新建、修改和删除都可以产生变动通知。删除时报告被删除的旧地址，同时让那个地址按实际情况响应；不能把所有旧地址替换成首页再通知。
提交前过滤不同主机、格式错误和重复地址，并确认没有把后台、临时预览或不该公开的个人数据URL混进去。是否值得索引仍由相应搜索引擎判断，通知器不能替页面决定内容质量。
200、202、403和422，应该怎样处理
先保存HTTP状态与对应URL、主机、密钥位置和提交时间。不要程序一失败就无限重试，或者把所有非200都写成“暂时没收录”。
| 响应 | 官方含义的重点 | 先查哪里 |
|---|---|---|
| 200 | 通知成功接收 | 接入层完成，后续另查抓取与索引 |
| 202 | 已接收，密钥验证待处理 | 密钥公开可读与后续验证状态 |
| 400 | 请求格式有问题 | JSON、编码与字段格式 |
| 403 | 密钥验证有问题 | 文件是否找到、内容是否匹配 |
| 422 | URL不属于host或不符合协议要求等 | 主机、目录范围与请求内容 |
| 429 | 过多请求 | 降低提交频率，保留失败记录后合理处理 |
状态码描述的是协议处理，不是对文章内容的评分。比如422通常先查配置，没必要因为这个错误重写整篇正文；200后仍未索引，则应进入相应引擎的页面诊断。
本地教学测试验证了两点：纯文本文件能返回与配置相同的字符串；根目录和/catalog/配置的候选URL范围不同。这是本地程序的可复现结果，没有向公共引擎发送示例URL，也没有声称它们通过真实索引验证。
通知完成后，再查相应搜索引擎
通知成功后，检查的是相关搜索引擎实际发现、抓取和索引情况。页面禁止索引、返回错误或内容用途不清，IndexNow不能绕过这些条件。
如果你面对的情况是“已经200，为什么仍没收录”，接着看成功通知后的排查。Google相关发现与索引按其支持的机制检查，不把Bing的一条通知当Google处理记录。
网站整体还应有真实内链、正确站点地图与有用内容。IndexNow帮助报告变化，学习与排错可以继续沿谷歌SEO学习路径和相应搜索引擎工具展开，不用提交次数代替页面质量。
把提交接到发布、更新和删除流程
真正的接入完成后，发布系统应能在内容变化时报告相应URL，并留下最少但足够定位的记录。只手工测试一次，然后每篇新文继续忘记提交，没有解决维护问题。
可以这样安排事件：
- 文章正式发布后，报告它的正式URL。
- 重要内容更新并已上线后，报告相同正式URL。
- 内容删除或迁移后，报告相应发生变化的地址，并核实际响应。
记录中保留事件、URL、提交时间、状态和必要错误；不要记录网站登录密码等无关凭据。重复发布事件应去重，批量失败要能定位到哪一批，而不是把失败批次记成全部成功。
密钥轮换、主机变更或CDN规则调整后，重新核文件与代表URL。已有平台接管自动验证时，按平台文档维护，不能把手动文件规则强行套到所有集成。
继续阅读：谷歌SEO完整优化流程：把当前技术检查接到抓取、索引与页面维护。
常见问题
密钥放到任意子目录，都能提交全站吗？
不能这样理解。官方协议对非根目录密钥有路径范围约束。用keyLocation指出位置后，仍需核目标URL是否在范围内；有条件时用根目录减少复杂性。
能把主域与所有子域放到同一批JSON吗？
批量请求按同一host组织，子域应按自己的主机与验证配置处理。不能因为品牌相同，就把不同主机地址混在一份请求里。
提交后200，是否还需要站点地图和内链？
需要继续维护它们。200只表示变动通知接收，不能替代发现路径、可访问性、索引条件与内容本身，也不保证任何搜索结果。
