现场是这样的。CDN 开了人机校验之后，连 /feed/ 和 /api/ 也被要求执行 JS 验证，蜘蛛拿到的响应是 202 加一段挑战脚本，页面正文一个字节都没有，收录直接停摆。
这类报错背后常见的原因有几处，逐个排除就行。校验规则按全站路径匹配，没有排除机器访问的接口；挑战页返回 202，被蜘蛛当成正常响应继续解析；静态资源路径也在校验范围内，CSS 和 JS 一起拿不到。
第一件事是看响应状态码与响应体
curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/feed/给接口与静态资源加校验例外
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/wp-content/themes/yourtheme/style.css末了对已知蜘蛛 UA 直接放行
curl -s -A 'Mozilla/5.0 (compatible; bingbot/2.0)' -o /dev/null -w '%{http_code}\n' https://www.example.com/post/1这次没动代码，只在配置和运行环境上找原因。
隔了一天再看，现象没变，说明不是偶发。
别只看报错消失，验证要多做一步。配置例外后接口返回 200 与真实内容，抓取量第二天回升，索引停止下跌。
202 不是成功，只是收下了挑战，凡是靠状态码判断健康的监控都会漏掉这种。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。