抓取路径出问题时，很多人第一反应是去看后台的抓取统计或收录曲线，但这些数据通常已经过一层聚合，看不出具体断在哪一步。服务器访问日志是更原始的证据：每次请求的时间、URL、状态码、UA、响应字节数都记在里面。学会读它，等于把蜘蛛在站点里的行走轨迹摊开来看。
先确认哪些请求真的来自搜索引擎
UA 字符串可以随意伪造，一条写着 Googlebot 的记录并不代表真是它。判断依据至少有两个：做反向 DNS 解析确认 IP 归属，以及核对官方公布的 IP 段。做不到全量验证时，也可以先按 IP 段过滤，再结合 UA 和请求行为看。
日志里值得重点看的几列
- 时间：抓取是持续发生还是集中在某几分钟，是否跟发布节奏同步。
- URL 路径：带参数的、大小写不同的、带与不带尾斜杠的，先分开统计，重复入口往往在这里露头。
- 状态码：200、301/302、304、404、5xx 各占多少，5xx 集中在哪些前缀下。
- 响应时间：慢的路径通常抓取频次会下滑，这是服务器侧对抓取路径最直接的影响。
- UA 与 IP：用来区分不同搜索引擎，也用来识别伪装爬虫。
三类典型问题在日志里的样子
路径走两步就断
入口页有稳定的 200 抓取，但入口页正文里指向下一层的 URL 在日志里几乎没有记录。多数情况不是蜘蛛不想走，而是那些链接在 HTML 里根本不存在——靠 JS 渲染、靠点击才插入，或者被属性挡住了。对照页面源码里的原始 HTML 核对一遍就能确认。
抓取集中在少数 URL
同一个列表页一天被访问几十次，深层内容页一周只有一两次。这通常说明入口太窄：站点的内链资源压在首页和少数几个栏目页上，蜘蛛每次来都在原地打转。日志上表现为路径分布的头部极重、尾巴极长。
5xx 与超时增多
日志里出现成片的 500、502、503，或者响应时间明显拉长，接下来几天的抓取频次往往会下降。这更像抓取调度在做自我保护，而不是惩罚，服务恢复稳定后一般会回来。要留意 CDN 缓存：命中缓存的请求不一定落到源站日志里，只看源站日志容易低估实际抓取量，最好把边缘节点日志或负载均衡日志一起看。
把日志和 Sitemap、内链对照起来
Sitemap 里提交了几万条 URL，日志里只被请求过几百条，说明 Sitemap 更像一份备用清单，真正带路的还是内链结构。反过来，如果日志里出现大量你既没提交、也不在任何内链上的 URL，那多半是参数拼接或历史遗留入口在漏。
一个可执行的小流程
- 过滤出真实蜘蛛请求，按周导出日志片段。
- 按状态码和路径前缀分组，找出占比异常的那一组。
- 抽 10 到 20 条被反复抓取的 URL，和实际页面内容、内链位置对照。
- 抽 10 到 20 条从未被抓取的 URL，检查它们在 HTML 里是否真的可点、是否被属性挡住。
- 改完后保持同样的统计口径，观察两到四周的变化。
日志反映的是已经发生的事。改动之后要给蜘蛛一个重新爬取的周期，短期数据波动不必急着下结论。
把日志分析放进常规巡检：每周扫一次状态码分布和路径集中度，比等到收录出问题再回头排查要省力得多。抓取路径的修复，往往是内链、Sitemap 和服务器响应三者一起调整的结果，只改其中一处，效果通常有限。