很多站長判断收錄情况的依據是服務器日誌：只要看到疑似蜘蛛的訪問记錄，就預設頁面已经被抓取。但日誌里的訪問记錄、抓取統計里的抓取次數、索引里的頁面狀態，是三套不同的口径。三者對不上时，先別急着改頁面，先把口径核對清楚。
一、先確認訪問者到底是谁
日誌里的 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 和服務端配置，否則前後两次資料没法比較，等于白白多绕一圈。