报错是这么冒出来的。用 Screaming Frog 22.0 爬一个三千页的站，导出 Internal 报表里 200 是 2850 条。抽样抓包发现其中 400 多条其实是 CDN 返回的 429 限速页。
中间走过弯路，把「配置里的 429 重试次数是 3，重试全部失败后仍记录了内容」当成主因，改完现象没变。
原因不止一个，得分开看。工具默认把带内容的 429 当作可渲染页面归到 200 组。还有一种是爬取速度设为每秒 5 个请求，触发了 CDN 的频控阈值。
还有一种情况，报表导出时按状态码分组，429 分组被折叠没注意。
先把速度降到每秒 1 个再爬一次对比
screamingfrog --headless --crawl-speed 1 --url https://www.example.com再往下打开 429 的单独分组统计条数
python sf_diff.py old.csv new.csv --status 429然后配置里把 429 视为错误而不是重试成功
grep -i "429" ~/.ScreamingFrog/config/crawl.xml剩下的就是在 CDN 侧给本机 IP 加白名单验证
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/别只看报错消失，验证要多做一步。降速重爬后 429 分组归零，200 的数量降到 2400 左右，和服务器日志的真实响应分布对得上。
爬虫工具的状态归类和服务器日志经常有偏差，做收录诊断时以 access.log 为准，工具报表只用来找结构问题。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。