报错是这么冒出来的。文章下线后调用 IndexNow 提交该 URL，接口返回 202，两周后 site 查询仍能看到这条结果，抓取日志里也没有再次访问的记录。
把日志和配置对完，能解释这个现象的基本就这几处。IndexNow 只通知内容变化，不保证删除，删除要看页面返回的状态码。另一种情况是提交的是页面地址而不是已变成 404 的最终地址。
不容易想到的是，Bing 侧处理有延迟，少量 URL 会被合并到下一轮抓取。
动手时先确认接口返回的请求 ID
curl -s -X POST https://api.indexnow.org/indexnow -H "Content-Type: application/json" -d '{"host":"www.example.com","key":"abc123","urlList":["https://www.example.com/post/1"]}'然后确保该地址返回 404 或 410
curl -sI https://www.example.com/post/1 | head -2补充提交站点地图让蜘蛛重新判断
curl -s https://www.example.com/sitemap.xml | head -5报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
恢复的判定其实很直接。该地址返回 410 且再次提交返回 200，两周后 site 查询里该结果消失，Bing 的索引状态显示已移除。
删除类变更靠状态码说话，接口只是加速器，页面仍返回 200 时推多少次都没用。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。