本文约 2,653 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：资源平台的数据是”百度的视角”，日志才是”你的视角”
百度搜索资源平台会给出抓取量、索引量、抓取异常等数据，但它是采样与延迟的：通常有 1–2 天延迟，且只统计百度自己认定的那部分抓取。服务器日志则是全量、实时、第一手的记录——谁在什么时候请求了哪个 URL、服务器回了什么码、用了多少时间。想判断”百度到底来没来过””它来的时候我的服务器表现如何”，唯一可靠的依据就是日志。本文给出一套可以直接复制执行的分析流程。
原理分析：日志里能回答的五个问题
一份标准的 Nginx combined 格式日志包含：来源 IP、时间、请求方法与路径、状态码、响应字节数、Referer、UA。基于这些字段，可以回答五个核心问题：
- 来没来：是否存在真实 Baiduspider（需配合 DNS 校验）的请求。
- 来多少：按天/按 IP 统计抓取量，看趋势而非单点。
- 抓了什么：路径分布，判断抓取是否集中在低质页上。
- 结果如何：状态码分布（200/301/404/5xx）与响应耗时。
- 是否有异常：短时间内高频重复请求、异常 UA、异常来源。
其中第 4 项最关键：如果蜘蛛 90% 的请求拿到 200 且耗时低于 1 秒，说明抓取环节健康；如果 5xx 或 404 占比偏高，抓取频次下调只是时间问题。
保姆级实操
第一步：确认日志格式与位置
# Nginx 常见路径
ls -lh /var/log/nginx/access.log /var/log/nginx/access.log.1
# 确认日志格式（nginx.conf 里的 log_format）
grep -A5 'log_format' /etc/nginx/nginx.conf
第二步：抓取量按天趋势
LOG=/var/log/nginx/access.log
grep -i "Baiduspider" $LOG \
| awk '{print $4}' | tr -d '[' | cut -d: -f1 \
| sort | uniq -c | awk '{printf "%s %6d\n", $2, $1}'
第三步：响应码分布
grep -i "Baiduspider" $LOG | awk '{print $9}' | sort | uniq -c | sort -rn
# 只看非 200 的请求，快速定位问题
grep -i "Baiduspider" $LOG | awk '$9!="200"{print $9, $7}' | sort | uniq -c | sort -rn | head -20
第四步：抓取路径 Top 与抓取浪费识别
# 抓取最多的路径
grep -i "Baiduspider" $LOG | awk '{print $7}' | sed 's/?.*//' | sort | uniq -c | sort -rn | head -20
# 同一 URL 被重复抓取的次数（大于 50 次说明抓取预算被浪费）
grep -i "Baiduspider" $LOG | awk '{print $7}' | sort | uniq -c | awk '$1>50' | sort -rn | head -20
第五步：响应耗时分布
# combined 格式最后一个字段是请求耗时（需配置 $request_time）
grep -i "Baiduspider" $LOG | awk '{print $NF}' \
| awk '{s+=$1; n++; if($1>2) slow++} END {printf "avg=%.2fs n=%d slow(>2s)=%d\n", s/n, n, slow}'
若日志未记录耗时，先在 Nginx 的 log_format 中加入 $request_time 与 $upstream_response_time，重载配置后重新采集数据。
第六步：与资源平台数据交叉验证（抓取量本身偏低时，参考百度抓取频次异常的调整做恢复）
把日志统计的每日抓取量与平台显示的抓取量对比。若日志里真实蜘蛛（DNS 校验通过）有 800 次而平台显示 100，通常是大部分请求被判为伪造 UA，或者平台数据尚未更新；若日志里一次都没有，说明问题在抓取入口（DNS、防火墙、robots），而不是索引策略。
常见踩坑
- 直接 grep “Baiduspider” 就当真：伪造 UA 极多，必须做 DNS 双向校验后再统计。
- 日志被 logrotate 切走：分析时只看
access.log会漏掉历史，应连同access.log.1或.gz一起处理（zcat）。 - 开了 CDN 后来源 IP 全是节点：需要在 Nginx 里配置
real_ip_header X-Forwarded-For与set_real_ip_from，否则 IP 分析全错。 - 静态资源关掉 access_log 导致低估抓取量：很多优化教程建议
access_log off，这会让你丢失部分抓取数据，建议保留蜘蛛请求的日志。 - 案例：某站抱怨”百度不收录”，但日志分析显示 Baiduspider 每天来 600 次、其中 420 次拿到 404——原因是伪静态规则在插件更新后失效，文章页全部 404。修复规则后三天内抓取量不变但 200 占比从 30% 升到 98%，收录随即跟上。
- 只看一天数据下结论：抓取有波动，至少看 7 天趋势。
- 忽略 HTTPS/HTTP 双份日志：若同时开了 80 和 443 且日志分开，需要合并统计。
总结
判断标准：真实蜘蛛（DNS 校验通过）连续 7 天有访问、200 占比高于 95%、平均耗时低于 1 秒、抓取路径集中在内容页，才算”抓取健康”。行动清单：确认日志格式含 request_time → 提取蜘蛛请求 → DNS 校验真伪 → 统计按天趋势、响应码、路径、耗时 → 与平台数据交叉验证 → 针对非 200 项逐类修复。若抓取正常但索引量仍在掉，可继续看百度索引量突然下降的排查流程。
