报错是这么冒出来的。运维改 Nginx 时把 robots.txt 的位置写错，访问一直返回 503，持续两天，蜘蛛的抓取量从每天两万次掉到不足一千。
中间走过弯路，把「CDN 把 503 缓存了十分钟，源站修好仍返回错误」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。robots 返回 5xx 时蜘蛛会暂停抓取，等恢复后再来。也可能是配置指向了不存在的上游，重启后一直 503。
还有一种情况，监控只探首页，robots 不在巡检范围。
动手时先确认 robots 的状态码
curl -sI https://www.example.com/robots.txt然后把位置指向静态文件
location = /robots.txt { root /var/www/site; }接着清掉边缘缓存的错误响应
curl -X PURGE https://www.example.com/robots.txt末了把 robots 加进巡检
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/robots.txt改之前先确认了最近有没有人动过配置，避免白查一遍。
怎么算真的好了，看的是同一批现象。恢复后当天抓取量开始回升，三天内回到原来水平，巡检里 robots 一直返回 200。
提醒一点。robots 是抓取的入口文件，它挂了比任何单页 404 都严重，监控必须单独盯这一条。报错文案容易误导，真正的原因往往在相邻那一层的日志里。