蜘蛛抓取返回码分布：收录下滑先查这里

收录肉眼可见地掉，站长第一反应往往是内容出问题了，赶紧改标题补内容。先别动。收录下滑有个更常见的隐形诱因：蜘蛛一直在来，但每次都扑空——抓走一串 5xx 或者大面积 404。抓取端不顺畅，搜索引擎会降低对你站点的抓取意愿，收录自然一茬不如一茬。

这不是玄学，官方文档写得明明白白：Google 的抓取文档说，站点响应稳定且快就上调抓取容量，响应慢或持续返回服务器错误（5xx）、限流信号（429）就下调。百度同理。所以诊断收录问题的第一张化验单，就是蜘蛛抓取的返回码分布——它直接告诉你蜘蛛的体检结论。

# 百度+谷歌蜘蛛的返回码分布

grep -E "Baiduspider|Googlebot" /var/log/nginx/access.log \

| awk '{code[$9]++} END {for (c in code) print c, code[c]}' \

| sort -rn

# 5xx 细节：哪些页面在报服务器错误

grep -E "Baiduspider|Googlebot" /var/log/nginx/access.log \

| awk '$9 >= 500 {print $9, $7}' \

| sort | uniq -c | sort -rn | head -20

健康站点的蜘蛛抓取里 200 应该占绝对大头。经验上的警戒线：5xx 占比超过 2% 就当事故处理，404 超过 10% 说明站内入口或外链指向出了系统性问题。抓到 5xx 清单后别急着改代码，先看是不是抓取高峰撞上了服务器的资源瓶颈——很多所谓 SEO 问题，其实是后半夜备份任务把 MySQL 挤死了。

# 结合抓取耗时定位慢页面（log_format 需加 $request_time）

# log_format spider '$remote_addr [$time_local] "$request" '

#                   '$status $http_user_agent rt=$request_time';

# 蜘蛛抓取平均耗时

grep "Baiduspider" /var/log/nginx/access.log \

| awk -F'rt=' '{sum+=$2; n++} END {printf "avg %.3f s\n", sum/n}'

# 抓得最慢的 10 条请求

grep "Baiduspider" /var/log/nginx/access.log \

| awk -F'rt=' '$2 > 3 {print $2, $0}' | sort -rn | head -10

平均耗时这条线官方也有说法：抓取容量上限的调整依据里明确包含响应时间与首字节时间是否稳定。平均响应压到 1 秒以内、没有超 3 秒的长尾，抓取容量才有上调的空间。改完服务器配置，第二天重跑一遍分布命令，5xx 占比应该肉眼可见地回落，这就是最直接的验证。

# 连续观察 7 天切割日志的分布变化

for i in 1 2 3 4 5 6 7; do

f=/var/log/nginx/access.log.$i

[ -f "$f" ] || continue

echo "== $(basename $f) =="

grep -E "Baiduspider|Googlebot" "$f" \

| awk '{c[$9]++} END {for (k in c) print k, c[k]}' | sort -rn

done

返回码清单里还有两类要单独说。一是 301 链条：蜘蛛抓一个旧地址被 301 到第二个、再 301 到第三个，每一跳都是一次独立的抓取请求，官方把避免重定向链列为抓取优化的常规项，日志里能直接量出来——统计蜘蛛抓取中状态码 301 的占比，占比高就该花时间把内部链接直接改成最终地址。二是 429：它是限流信号，搜索引擎会把它当服务器过载处理，抓取容量随之下调，出现 429 通常说明站点配了过激的防 CC 规则，把真蜘蛛误伤了，去 Nginx 或防火墙的限流配置里给已验证的蜘蛛加白名单。

收尾给一个判断框架：返回码分布管抓取端健康，收录量管索引端结果。分布好了收录还掉，才轮到查内容质量、重复度和站点结构。顺序反了，改半天内容也白搭——病根在服务器这一层。

相关阅读：收录下滑先看返回码分布，再看总纲。《SEO 自动化总清单：日、周、月、季各该跑什么》把本篇排在日志组的每日巡检位，五分钟一个动作，异常当天就知道。