入口页跑起来之后，大部分判断都要落到日志上：蜘蛛有没有来、来了多少次、抓的是哪些 URL、每次返回了什么状态。日志本身不提升抓取，但它决定了你在遇到问题时是拿着数据排查，还是靠感觉反复改页面。很多入口页的调整之所以来回折腾，原因就是日志留得太少或太短，等到想回看时已经没东西可看。
至少该留下哪些字段
如果条件允许，访问日志里这几项尽量齐全，被 CDN 或反向代理包一层时尤其要注意：
- 请求时间，明确标注时区，避免跨时区团队对不上号；
- 客户端 IP，并确认能取到真实来源 IP，而不是代理节点 IP；
- User-Agent 原始字符串，不要提前做过滤或归一化；
- 请求方法、完整 URL 连同查询串；
- HTTP 状态码与响应字节数；
- 响应耗时；
- Referer，用来判断蜘蛛是从哪条路径进来的。
字段缺失往往在排查时才发现。比如只有状态码没有完整 URL，就无法判断是哪个链接出了问题；只有 UA 没有 IP，就没办法区分正常抓取和被伪装的请求。
留存周期与轮转方式
常见的做法是按天切分、压缩归档，保留三十到九十天。选这个区间的原因很实际：一个 URL 从首次被发现到被反复抓取，中间往往跨越数周，留存窗口太短，就看不到完整链路。
- 按天切分，方便做同日对比和前后对比；
- 归档时压缩，控制磁盘占用；
- 清理之前先确认当前有没有正在跟进的问题，避免删掉正在用的证据；
- 多台服务器的话，尽量统一采集到一处，否则排查要在几个终端之间来回切。
用日志能回答的几类问题
蜘蛛到底来没来
先按 UA 中的蜘蛛标识过滤，再看 IP 段是否对得上。需要提醒的是，UA 是可以伪造的，单靠这一个字段很容易误判。更稳妥的方式是 UA、IP 段、请求特征三者交叉验证：同一来源的抓取频率是否稳定、访问的路径分布是否符合抓取习惯、是否伴随大量无意义的随机路径。
抓了哪些、漏了哪些
把日志里的 URL 去重，和入口页上实际存在的链接清单做对比，差异就是线索。某个链接一直没出现，可能是位置太深、被 robots 规则挡住、由脚本生成而抓取端拿不到，也可能是页面本身没被访问过。这一步不需要复杂工具，两张表对一遍就能看出方向。
返回了什么
状态码的分布比单条记录更有价值。5xx 集中出现，说明服务端不稳定；大量 3xx 要检查跳转链是否过长；404 集中出现，通常意味着链接清单和线上实际 URL 已经不一致，页面改过而链接没同步。响应耗时也值得留意，个别 URL 明显慢，往往会被抓取端降低优先级。
容易踩的几个坑
- 只保存聚合报表，不保留原始日志，出问题时无法回溯到单条请求；
- 日志时间不带时区，跨团队沟通时反复确认；
- 把 CDN 节点 IP 当成蜘蛛 IP，统计出来的来访量完全失真；
- 日志分散在多台机器、多个目录，没有统一收集入口；
- URL 中带敏感参数或令牌，未做脱敏就直接长期留存。
一个简单可行的落地方式
- 每台入口页服务器开启访问日志，按天轮转，先保证有原始数据；
- 用统一采集把日志归到一处，至少支持按 URL、状态码、UA 过滤；
- 每周固定看一次状态码分布和来访次数，形成基线，异常才显得出来；
- 发现问题时拉出当天原始日志逐条核对，而不是只看汇总数字；
- 调整入口页之后，用调整前后的日志对比来判断变化，而不是凭印象。
日志不解决抓取问题，它只是让「这件事有没有真的发生」变得有据可查。
把日志留存当成一项基础工作来做，成本不高，但能省下大量反复猜测的时间。入口页数量一多，没有日志几乎无法判断哪个环节出了偏差。