indexnow 怎么用：一个 key、一次请求，把更新直接告诉引擎

IndexNow 是一次 HTTP 请求，用来告诉参与的搜索引擎某个 URL 新增、更新或删除了。整套要三样东西：一个 key 字符串、把这个 key 以文本文件形式放在自己域名下、以及每次发布发一个请求。它免费，二十分钟能配完，而且全程不用登录任何搜索引擎后台 —— 这一条对做出海站的人尤其省事。

读这篇前

这篇默认你的页面已经能访问、也已经在 sitemap 里。没确认过就先去确认：给一个返回 404 的 URL 发推送，这一次推送就白费了。发布后的三步最小闭环写在页面改完之后怎么推送收录那篇里，本篇是它第三步的展开。

动手之前先看一眼你是不是已经有了。indexnow.org 列出的原生或插件支持里，WordPress、Shopify、Wix、Drupal、Joomla!、PrestaShop、Typo3、Umbraco 都在；CDN 那侧 Cloudflare 有原生集成。这几样只要开着一个，你就不用再写任何代码。

哪些引擎真的在听

IndexNow 是一份共享协议，所以发一次，全部参与方都能收到。支持方名单公布在 indexnow.org 上，很短。

这份名单里 Bing 一个就值回票价。ChatGPT 的联网搜索和 Copilot 取材都建在 Bing 的索引上，所以早一点进 Bing，就是早一点进入 AI 答案的候选来源池 —— 做 GEO 的人真正要的是这个，不只是多一个搜索引擎的流量。Google 那侧走自己的路，所以上一篇让你两边都做。

第一步 —— 生成 key 并放到自己域名下

key 的作用是让引擎确认这次提交来自控制这个域名的人。它是你自己编的一串字符，规则很窄：8 到 128 位，只能用 a-z、A-Z、0-9 和连字符。去掉花括号的 UUID 全部满足，而且随时能重新生成。

KEY=$(uuidgen | tr 'A-Z' 'a-z' | tr -d '{}')
echo -n "$KEY" > public/$KEY.txt
echo "https://example.com/$KEY.txt"

这个文件必须是 UTF-8、必须以 key 命名、内容必须就是那串 key，别的什么都不要有。部署完用浏览器打开这个地址看一眼。如果它没有以纯文本返回那串 key，就停在这儿 —— 后面每一步都会以 403 失败，而错误信息不会告诉你原因在这里。

文件也可以不放在根目录，但那样 key 的作用域就只覆盖它所在的那个目录。放在 /catalog/key.txt 的 key 能提交 /catalog/ 开头的 URL，不能提交 /help/ 开头的。放根目录就没有这个问题。

有一点很多人理解反了：这里的 key 不是 API token 那种意义上的密钥。协议要求你把它公开挂在一个谁都能读的地址上，因为那个公开文件本身就是控制权的证明。提交进代码仓库没有问题。真正要紧的是文件和你请求里发的值始终一致 —— 换了一头忘了另一头，提交会直接失败，不会自动退回旧值。

第二步 —— 先手动提交一条

自动化之前先用一个 GET 把链路验通。单条提交的写法协议里写死了。

curl -s -o /dev/null -w '%{http_code}\n' \
  "https://api.indexnow.org/indexnow?url=https://example.com/your-page&key=$KEY"

这里返回 200，说明 key 文件被找到并读取了。它不代表这个页面会被收录。这个区别要一直记着 —— 协议文档的原话是：200 只表示搜索引擎收到了你的 URL。

第三步 —— 换成批量端点

一次一条适合手动验证，放进发布流程就不合适了。批量写法一个 POST 最多带 10,000 条 URL，多数站一辈子也用不满。

POST /indexnow HTTP/1.1
Host: api.indexnow.org
Content-Type: application/json; charset=utf-8

{
  "host": "example.com",
  "key": "your-key",
  "keyLocation": "https://example.com/your-key.txt",
  "urlList": [
    "https://example.com/page-a",
    "https://example.com/page-b"
  ]
}

其中 host 的值必须和列表里每一条 URL 的域名一致。一个 payload 里混进两个域名，是批量提交看起来没毛病却返回 422 的头号原因。

回执怎么读

端点一共就返回五种码，每一种指向一类不同的错。这张表是本篇里最值得一直开着的部分。

几乎每个人第一次都栽在 403 上，而它只有两个原因：文件不在你说的那个位置，或者文件在、里面的值和你发的对不上。别的什么都先别改，用 curl 把 key 文件取下来，和脚本里的值逐字比一遍。单条能通、批量返回 422，那问题在 host 字段上，不在 key 上。

交付物：一段能直接放进发布流程的推送

把下面这段拿走，改两行，挂在发布内容的最后一步。它读你的 sitemap，一次批量推完，并把 HTTP 码打出来 —— 失败是看得见的，不是静默的。

#!/usr/bin/env bash
set -euo pipefail
HOST="example.com"
KEY="your-key"

URLS=$(curl -s "https://$HOST/sitemap.xml" \
  | grep -o '<loc>[^<]*</loc>' \
  | sed 's/<[^>]*>//g' \
  | python3 -c 'import json,sys; print(json.dumps([l.strip() for l in sys.stdin if l.strip()]))')

curl -s -o /dev/null -w 'indexnow: %{http_code}\n' \
  -X POST "https://api.indexnow.org/indexnow" \
  -H 'Content-Type: application/json; charset=utf-8' \
  -d "{\"host\":\"$HOST\",\"key\":\"$KEY\",\"keyLocation\":\"https://$HOST/$KEY.txt\",\"urlList\":$URLS}"

两个习惯能让它长期不坏。把推过什么、什么时候推的记一份日志，重复的就跳过。以及按变更推，不要按时间表推 —— 每天定时把没变过的 sitemap 推一遍，正是攒出 429 的方式。

做错了会怎样

三种常见错法都会给一个能看见的返回码，所以上面那张回执表是出问题时第一个该翻的东西。

1. key 文件的 content type 不对，或者结尾多了一个换行。浏览器里看还是对的。用 curl 取下来逐字节比。
2. 推送跑在部署完成之前。引擎按你给的地址过来，你的服务器还没发上去，这一次推送花在了一个 404 上。
3. 每次构建都把整份 sitemap 推一遍。一开始什么都不坏，然后提交开始返回 429，真正有用的那几条推送跟着噪声一起丢了。

indexnow 做不到什么

它不能让页面被收录。它只是把「被发现」这一步提前，引擎依然自己决定这个页面值不值得留下 —— 一个内容单薄的页面被更快发现，它还是单薄。它也到不了 Google，Google 不在参与名单上，所以它永远替代不了你流程里 Search Console 那一侧。

提前了多久，我们也说不出数字。要把这件事测准，得有一组不推送的对照 URL 跟踪几周，这个实验我们还没在自己的站上跑过。谁给你一个具体的「提前了 X 小时」，先问他对照组是什么。

真正该顺手一起查的是链路的其余部分。如果你的 sitemap 给每条 URL 盖的都是构建时间，推得再勤也修不好你发出去的那个信号 —— 我们那次 sitemap lastmod 调查里，24 个站有 13 个就是这个状态。QueryWin 要做的正是把这一整条链路查完，而不是盯着一个端点。

常见问题

IndexNow 对 Google 有用吗？

Google 不在 indexnow.org 公布的支持方名单里。它会不会通过别的途径读到这些提交，我们没测过，所以两个方向都不下结论。

能多久推一次？

协议没有公布每小时上限，但 429 这个码存在的意义就是拦过度提交。官方对用户生成内容给的建议是递减：前 20 条每条都推，之后到 100 条每 5 条推一次，再到 1000 条每 10 条推一次。

一定要用 Bing 站长工具吗？

提交不需要。核对需要 —— 那是你唯一能免费看到「URL 有没有被收到」的地方。

key 以后能换吗？

能。把新的 key 文件挂上去，脚本里的值改掉，旧文件先留一阵子。引擎是在你提交时才去读 key 文件的，没有需要重做的注册环节。