不少人看服务器日志时，看到搜索引擎爬虫一天来几百次，就默认收录不会出问题。但抓取和收录是两件独立的事：爬虫来了、把页面取走，只表示这个 URL 进入了待处理队列；至于是否入库、以哪个版本入库、之后会不会被合并或忽略，是后面才决定的。日志能证明"来过"，证明不了"收下"。
访问日志能说明什么
把日志当成一份访问记录来读，它可以回答下面这些问题：
- 爬虫是否真的请求了这个 URL，而不是只从站点地图里知道它的存在
- 服务端返回的状态码、响应体大小、响应耗时
- 访问用的是移动端还是桌面端 UA，是普通爬虫还是图片、视频类爬虫
- 大致抓取频率，以及这个 URL 是从哪一层被走到的
它回答不了的问题是：页面有没有进索引、进的是哪个版本、是否被判定为重复或低质。这几项要去索引状态报告或者 URL 检查工具里看。把两边的数据放在同一时间轴上，才谈得上对照。
对照排查的三步
第一步：先过一遍状态码和响应体
返回 200 但响应体只有几百字节，是前端框架空壳页面的典型表现。这种情况说明爬虫拿到的是没有被渲染的骨架，正文还在 JavaScript 里。反过来，如果登录页、错误页大范围返回 200，也会让爬虫把无效页面当成有效页面带回去。频繁出现的 301、302 需要顺着跳转链看一遍，跳转层数太多容易在中途被放弃。
第二步：确认抓到的版本是不是你想要的那个
如果站点做了移动适配、动态渲染或者多套模板，同一个 URL 在不同 UA 下返回的内容可能不一样。把日志里移动 UA 和桌面 UA 的响应大小、请求时间放一起比一比，差距明显时，就要回到页面上核对两种版本的实际内容是否一致。
第三步：和索引状态对齐
用站点地图或 URL 检查工具确认这个 URL 当前处于哪种状态。"已发现，尚未抓取""已抓取，尚未编入索引""已排除"对应的含义完全不同。把日志里的抓取时间点与状态变化时间对齐之后，才能判断是抓了没被处理，还是根本没有进入处理流程。
几种常见的抓了却不收录
- 内容与站内已经收录的页面高度相似，被合并处理或被判定为重复版本
- 正文文字太少，关键信息放在图片里或者要点开交互才出现
- 返回给爬虫的 HTML 与用户看到的不一致，两边对不上
- 该 URL 属于被 canonical 指向其他页面的旧版本
- 模板频繁改动，每次抓取拿到的内容差异较大，页面稳定性差
可以动手调整的地方
- 缩小观察范围：日志只看目标目录的 URL，把图片、样式、脚本请求过滤掉，否则数据噪音会盖住真实信号
- 一次只改一处，改完给它足够的时间再去看数据变化，不要在同一天里连续叠加多个改动
- 优先处理入口页面和栏目模板的问题，它们影响的不只是一个 URL，而是一整批页面的抓取和入库表现
- 让重要页面靠内链保持在较浅的层级，不要只依赖站点地图被发现
抓取记录只回答"爬虫来过没有"。页面有没有进索引、进的是不是最新版本，要另找证据。
把日志当作线索，而不是结论。真正有用的做法是：日志指出爬虫的行为，索引状态指出系统的判断，页面本身决定这两者能否对上。三者不一致的地方，往往就是需要动手的位置。