站点运营里，服務器日誌是最早、也最不经加工的一份抓取记錄。Search Console 的报告有延迟、有抽样，而日誌里的每一行請求，都對應一次真實發生的訪問。把日誌用起来，能回答几個很具体的問题：来的到底是不是搜尋蜘蛛、它抓了哪些 URL、抓到的是 200 還是 5xx、這一周比上一周多来還是少来。
第一步：確認是不是真的蜘蛛
UA 字符串谁都能寫，日誌里出現 Googlebot 並不代表就是 Google。判断顺序一般是：
- 對来源 IP 做反向 DNS 查询，把 IP 反解成域名，看是否落在官方網段；
- 再對照官方公布的 IP 段列表做一次核對；
- 结合行為看：真蜘蛛通常不會只抓一個頁面就走，也不會在几秒内密集請求一堆不存在的路径。
如果需要更嚴格，再做一次正向解析確認，避免有人伪造 PTR 记錄。這一步做完了，後面所有統計才有意义。
第二步：把抓取分布拆開看
只看總請求數意义不大，數量涨跌都可能由無關因素造成。建议按几個维度拆：
- 狀態碼：200、301、404、5xx 各占多少。404 占比高，說明站内存在大量失效連結；5xx 出現，說明蜘蛛来的时候服務器並不稳定。
- URL 類型：文章頁、列表頁、标簽頁、带參數的篩選頁、站内搜尋结果頁，各自被抓了多少。如果大量抓取落在無價值的參數頁上，抓取预算就被消耗在回报很低的地方。
- 目錄分布：哪些栏目被抓得多，哪些栏目長期没有蜘蛛進入。
- 時間分布：抓取是否集中在某個时段，是否和你的业務高峰或备份任務撞在一起。
第三步：抓取频率的變化比绝對值更有信息
一周内蜘蛛訪問量翻倍，不一定是好事；腰斩，也不一定就是坏事。
更值得盯的是這几個信号：
- 老頁面的回訪間隔是不是在變長，可能意味着站点更新节奏放慢，或者响應時間變差；
- 新發布的 URL 從上线到第一次被抓，中間隔了多久；
- 同一個 URL 在短時間内被反复抓取，通常指向内鏈到處指向同一地址，或多個地址没有做归一化。
第四步：和 Search Console 互相校驗
日誌说抓了、GSC 说没抓，或者反過来，都是常见現象。原因通常有几個：GSC 資料有延迟、只覆盖一部分；日誌里混進了非搜尋方的爬虫；带參數的 URL 在报表里被折叠統計。一個實用的分工是：用日誌判断“到底来没来”，用 GSC 判断“抓取之後被怎么處理”。
第五步：把检查變成例行動作
不需要每天盯總量，每周固定看几件事就够了：5xx 的數量、404 的增量、新 URL 首次被抓的时長、抓取量排名前 20 的 URL 是不是你希望優先抓的那批。有異常再往下追，没異常就记錄基线。
日誌不解决所有問题，但它是唯一一份不带解讀的原始记錄。把它和 Sitemap、内鏈结构、服務器监控放在一起看，抓取這件事才有一個可以對照的參照物。