报错是这么冒出来的。把整站一万二千条新地址塞进一个 JSON 数组提交，接口返回 200，但响应体里的 confirmed 只有 10000，剩下两千条既没报错也没进抓取队列。
中间走过弯路，把「没有分批逻辑，失败后整批重推又把成功的部分重复提交」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。接口单次 URL 数量上限是一万条，超出部分被静默丢弃。少数情况下是脚本没有解析响应体，只看 HTTP 状态码就认为全部成功。
少数情况下是提交列表里混进了带参数的重复地址，实际有效条数更少。
第一件事是按 5000 条一批切开重新提交
python -c "import json;u=json.load(open('urls.json'));[json.dump(u[i:i+5000],open('b%d.json'%i,'w')) for i in range(0,len(u),5000)]"接着逐批提交并记录返回的 confirmed 数
for f in b*.json; do curl -s -X POST 'https://api.indexnow.org/indexnow' -H 'Content-Type: application/json' --data-binary @$f; done然后统计 confirmed 总数是否等于源列表
python check_confirmed.py --src urls.json --resp resp.log剩下的就是把分批和断点续传写进定时任务
python push_indexnow.py --chunk 5000 --resume state/indexnow.json恢复的判定其实很直接。分批提交后 confirmed 之和等于源列表条数，响应里 invalid 为 0，第二天抓取日志里能按批次找到对应请求。
这里还有个坑。只看状态码不看响应体是这类接口最常见的坑，200 只代表请求被接收，不代表每条 URL 都进了队列。报错文案容易误导，真正的原因往往在相邻那一层的日志里。