搜索引擎蜘蛛每天来几次、抓了哪些 URL、哪些请求是白跑一趟，答案通常就躺在服务器的访问日志里。相比在站长平台看汇总数据，日志能落到具体的 URL 和具体的时间点，排查问题时更直接。这篇文章讲的是怎么把日志读成一份能用的抓取报告。
日志里必须先记全的字段
不少服务器的默认日志格式只保留 IP、时间、方法、URL、状态码这五项，用来复盘抓取是不够的。建议至少补齐下面这些：
- User-Agent，用来切分来源
- 响应时间
- 返回字节数
- Referer，多数蜘蛛请求为空，可作为辅助判断
- 如果有 CDN，把边缘处理时间和回源时间分开记录
响应时间和字节数决定了你能不能看出“这个页面被抓了但没有内容”或者“服务器是从哪一刻开始变慢的”。缺了这两项，很多结论只能靠猜。
把搜索蜘蛛的请求单独切出来
第一步是按 UA 过滤，把常见的搜索蜘蛛单独导成一份。要注意 UA 是可以伪造的，如果要做严谨判断，还得拿 IP 段和反向 DNS 做交叉核对。这一步可以定期做一次，不必每次分析都重跑。
过滤之后，手上就有一份只有蜘蛛的请求列表了。接下来关注的是分布，而不是总数。
五个值得看的分布
- 状态码分布：200、304、301/302、404、5xx 各占多少。5xx 一旦抬头，通常意味着服务器在抓取时段扛不住。
- 抓取频次的时间分布：蜘蛛的活动时段相对固定，如果某天开始明显偏移，往往是抓取队列调整，或者站点响应变慢导致的。
- URL 目录分布：抓取量集中在哪些路径，深层目录是不是长期为零。
- 按小时统计的平均响应时间：超过某个阈值之后，抓取量一般会跟着往下走。
- 重复抓取的 URL：同一个地址在短时间内被反复请求，常见原因是内容频繁变动、重定向或者参数带来的多地址问题。
三种典型的日志形态
状态码 200，但字节数很小
这多半是空列表、占位页，或者模板渲染失败后返回了一个空壳。蜘蛛认为抓到了内容，实际上没有可用的东西。找到那几个 URL 对照一下，判断是分页取空、接口超时，还是渲染组件没加载出来。
大量 404 集中在同一个模板
如果 404 的 URL 有共同的前缀或者参数结构，通常是链接生成逻辑出了问题，比如列表里输出了已经下线的 ID。修复之后 404 会在几天内回落，但要留意蜘蛛不会立刻停止访问老地址，短期内看到残留是正常的。
5xx 突发，随后抓取量下降
顺序一般是：服务器先报错，蜘蛛识别到错误后降低抓取频率，之后一段时间抓取量都偏低，即使服务恢复了也要等一等才回到原来的水平。所以发现 5xx 的第一件事是止血，先把错误返回压下去，而不是接着观察曲线。
从日志回到站内动作
日志本身不解决问题，它只是把问题指出来。常见的对应动作可以这样排：
- 目录长期零抓取：检查内链是否可达、Sitemap 是否覆盖、有没有 noindex 或 robots 拦截。
- 抓取量只集中在浅层：检查分页的下一页是否可点，深层内容有没有别的入口。
- 响应时间上升：分辨是数据库查询、图片资源还是第三方脚本，优先处理拖慢首字节的部分。
- 重复抓取：确认是否存在参数造成的多个地址指向同一内容，用 canonical 归一。
- 状态码异常：先修服务端返回，再考虑重定向和清理死链。
日志的价值在于把“蜘蛛抓得不理想”这种模糊感受，变成一个能定位到 URL 和时间的具体问题。建议保留至少 30 天的原始日志，并在每次改动上线后，对比前后两周的抓取分布，看看改动到底带来了什么变化。