现场是这样的。定时任务每天凌晨把整站 5 万条 URL 全量推给 IndexNow，不管内容有没有变。前三周正常，第四周开始接口零星返回 429，必应抓取量反而比只推新文时更低，日志里同一批地址一天被提交多次。
中间走过弯路，把「发布时间和修改时间没参与判断，老页面被当新页面」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。全量重推没有和上次的提交记录做差集；任务失败后整批重试，已经成功的地址又进队列；定时任务和发布钩子各推一份，两边互相叠加。
第一件事是统计重复提交的比例
sort push.log | uniq -c | sort -rn | head -20接着用修改时间筛出真正变过的地址
mysql -e "SELECT url FROM posts WHERE post_modified > NOW() - INTERVAL 1 DAY;" -N > today.txt与已提交记录做差集只留新增
comm -23 <(sort today.txt) <(sort pushed.txt) > todo.txt失败重试只重跑失败队列
python push.py --retry failed.json恢复的判定其实很直接。每日提交量从五万降到三百左右，429 不再出现，必应对新文的抓取间隔缩到一天以内。
这里还有个坑。IndexNow 的价值在即时通知，重推没变的地址只是噪音，还会拖慢正常队列。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。