盯服务器访问日志的人常常会遇到一种落差：搜索蜘蛛确实来抓过蜘蛛池入口页，心里踏实了一点；可过一段时间回头看，目标 URL 在日志里一次都没出现过。这时候容易直接下结论说“蜘蛛池没用”，其实更常见的情况是链路中间某一环断了，只是没被注意到。日志本身能提供不少线索，关键是知道该按什么顺序去对。
先分清两件事：入口页被抓好，不等于链接被跟进
日志里一条针对入口页的请求，只能说明蜘蛛下载了这个页面，不能说明它解析了页面里的链接，更不能说明它把链接放进了待抓队列。想判断链接有没有“被读到”，至少要看两件事：
- 目标 URL 是否真的出现在入口页返回的 HTML 源码里，而不是只在浏览器渲染之后才出现；
- 日志里有没有针对目标 URL 的请求，哪怕是返回 4xx 或 5xx 也算被请求过。
如果源码里根本没有这条链接，问题在入口页的生成或输出环节；如果源码里有、日志里却没有，问题更可能出在后续的抓取调度上。
按顺序排查几个常见断点
- 链接是否依赖脚本才出现。用“查看网页源代码”的方式打开入口页，而不是只看渲染后的效果。源码里搜不到目标 URL，说明链接没有被输出。
- 是否被 robots.txt 或页面级规则挡掉。确认入口页自身没有被设为不可索引，同时确认目标 URL 所在路径没有被 robots.txt 禁止抓取。
- 入口页是否被 WAF、CDN 或防爬策略拦住。如果日志里响应码异常、返回体积明显偏小，或者只有部分 UA 能拿到完整内容，就要怀疑返回给蜘蛛的内容和返回给浏览器的内容不一致。
- 目标 URL 是否发生了重定向。如果目标 URL 做了 301 或 302，日志里出现的会是跳转之后的地址，看起来就像“从没被抓过”。
- 抓取频次是否本来就低。入口页被抓的次数很少时，挂在后面的目标 URL 排队更久，短时间内看不到日志属于正常现象。
做一个最小验证，比反复猜更快
挑一个入口页和一条目标 URL，单独做一次验证：手动抓取入口页的原始 HTML，确认链接确实在里面；然后在接下来的一段时间里，只盯这一对 URL 的日志，把时间、响应码、抓取 UA 记下来。这样得到的判断比看整体数据可靠得多，也更容易区分是入口页输出问题，还是调度问题。
几个容易误判的地方
- 只统计了部分日志文件或部分时段，目标 URL 的请求恰好落在没看的区间里。
- 日志按天轮转后被压缩归档，检索时没有合并，导致结果不完整。
- 把蜘蛛 UA 当成唯一证据。UA 可以伪造，反过来真实蜘蛛也可能因为缓存、压缩等原因不产生预期日志。
- 用第三方工具查询“是否被发现”，这类结果只能当参考，不能当结论。
抓取日志是排查工具，不是结果指标。它能说明蜘蛛来过，但不能保证目标 URL 会被收录，也不代表会有排名，这几件事之间没有等号。
链路都通了，接下来该看什么
如果入口页的输出正常、robots 规则没问题、也没有拦截和重定向，日志里还能看到目标 URL 被请求过，那入口页这一环基本可以认为完成了。再往下要关注的是目标 URL 自身的内容质量、可访问性、是否存在大量重复，以及整站的抓取配额是否够用。把这些不同层面的问题混在一起看，很容易让入口页背了不该背的责任。