很多站长判断收录情况的依据是服务器日志：只要看到疑似蜘蛛的访问记录，就默认页面已经被抓取。但日志里的访问记录、抓取统计里的抓取次数、索引里的页面状态，是三套不同的口径。三者对不上时，先别急着改页面，先把口径核对清楚。
一、先确认访问者到底是谁
日志里的 User-Agent 可以直接伪造，任何脚本都能把自己写成搜索引擎蜘蛛。只看 UA 字符串就统计抓取量，很容易把自家采集程序、监控探针、第三方工具都算成蜘蛛。
- 反向 DNS 与 IP 归属：把日志里的 IP 做反查，确认域名归属与官方公布的 IP 段是否一致。
- 行为特征：真正的抓取通常分散、连续、按 URL 顺序推进；固定周期、固定路径、固定顺序的访问更像探针。
- 来源分布：同一 IP 段在短时间内扫过大量不存在的 URL，更接近扫描器而非正常抓取。
尤其是使用了蜘蛛池或批量提交工具时，日志里会混进大量非搜索端的访问，这部分量不能直接当作“抓取量”来用。
二、日志里的“命中”要分清是哪一种
即使确认是搜索蜘蛛，一次访问也不等于一次有效抓取。至少要把下面几种情况分开看。
只取走了 robots.txt 或站点地图
这类请求会出现在日志里，但不代表它抓了正文页。统计抓取量时如果不过滤这些路径，数字会明显虚高。
请求方法不是 GET
HEAD 请求只拿响应头，不取正文。日志里出现 HEAD 往往只是连通性检查，不能算作内容抓取。
状态码不是 200
301、302、304、403、429、5xx 都算“来过但没拿到完整内容”。其中 304 表示内容未变，通常说明上次抓取的版本仍有效；429 和 5xx 则要去看服务端限流与稳定性。
请求根本没到源站
如果前面有 CDN、WAF 或负载均衡，被拦截的请求可能只记录在边缘节点，源站日志里看不到。判断抓取是否正常时，边缘日志和源站日志要一起看。
三、时间口径要先对齐
日志时间、抓取统计时间、索引状态更新之间常有延迟，也常有时区差异。核对前先确认几件事：
- 日志时间戳用的是 UTC 还是本地时间，与后台报表是否一致。
- 记录的是请求开始时间还是响应完成时间，差别在慢请求上会被放大。
- 索引状态本身存在更新延迟，“昨天抓了、今天还没进索引”属于正常范围，需要按观察窗口来判定。
四、把三方数据放到同一张表里核对
建议取一批样本 URL 逐条对照，而不是只看总量：
- 日志：该 URL 最近一次被抓取的时间、状态码、响应大小。
- 抓取统计：该 URL 所在目录的抓取频次与占比。
- 索引状态：该 URL 当前是否在索引中，收录的是哪个版本。
三条都能对上，说明链路基本正常，问题可能出在页面质量或版本选择；如果日志里有、抓取统计里没有，先怀疑身份识别与统计过滤；如果抓取统计有、索引里始终没有，再回到内容与规范化上排查。
日志只能说明“有人来过”，说明不了“页面已经被收”。把身份、状态码、时间口径三件事对齐之后，再讨论抓取是否充分，结论才站得住。
最后提醒一点：核对期间尽量不要同时改动 robots.txt、canonical 和服务端配置，否则前后两次数据没法比较，等于白白多绕一圈。