後台报表看不到的東西，日誌里往往有
大多數站点能看到的抓取信息，来自搜尋平台的站長後台或抓取統計。這些資料经過聚合，優点是直观，缺点是有延迟、有采样、通常只覆盖單一搜尋引擎。服務器訪問日誌是原始记錄：谁在什么時間、請求了哪個地址、服務器回了什么狀態碼、花了多久。排查抓取問题时，先看日誌通常比反复刷新後台更快定位到原因。
一條訪問日誌里值得關注的字段
常见格式大致包含：来源 IP、時間、請求方法與路径、狀態碼、响應字节數、User-Agent、Referer。多數服務器還會額外记錄上游處理時間。對應到抓取分析：
- 時間：抓取是否集中在某個时段，是否和站点维護窗口重叠。
- 路径：蜘蛛實际走了哪些 URL，哪些目錄被反复請求。
- 狀態碼：5xx 集中出現，通常意味着源站或後端不稳。
- 响應時間：長尾慢請求會拖慢整轮抓取。
- 响應字节：狀態碼 200 但字节數為 0，可能是空响應或中途中断。
先確認来的是不是真蜘蛛
UA 可以随便伪造，判断来源建议按這個顺序来做：
- 用日誌里的 IP 做反向 DNS，看域名是否落在官方公布的網段。
- 再做一次正向解析，確認能回到同一個 IP。
- 與搜尋平台官方给出的 IP 段列表比對。
驗證之後，才能把真實抓取和爬虫软件、镜像站、监控探针区分開。来源没分清，後面的分析结论很容易整体跑偏。
日誌里常见的几類抓取異常
抓取量突然下滑
先看是不是服務器侧的問题：某段時間 5xx 或超时上升、带宽打满、WAF 規則變更。抓取量的變化往往滞後于故障本身，日誌里能更早看到那個拐点。
狀態碼结构不對劲
健康站点的抓取日誌里，200 應占多數，404 和 301 是少數。如果 404 突然增多，检查是否改過目錄结构或參數規則；如果出現 301 長鏈，把跳轉改成直连；如果 5xx 成片出現，優先修後端，而不是繼續提交 URL。
URL 分布失衡
把日誌路径按目錄、參數聚合，看看抓取集中在哪。常见情况是：带一串篩選參數的地址被大量請求，真正需要更新的詳情頁却很少出現；或者静態资源和接口請求占了很大比例。這類問题通常要靠 robots 規則、參數規范化和内鏈調整来解决，而不是單纯加大提交量。
响應時間拖尾
關注 P95、P99 這類尾部耗时，而不是平均值。少數慢請求會一直占着连接，让整轮抓取變慢，平均值往往看不出這個問题。
反复抓同一批 URL
如果日誌里總是那几個頁面在循环，新 URL 迟迟不出現，多半是内鏈入口太窄：新内容要经過很深的层級才能到達，或者只存在于 Sitemap 里。這種情况先补内鏈，再谈其他提交方式。
把日誌與 Sitemap、内鏈對照着看
三個資料源互相印證會清楚很多：Sitemap 代表你希望被抓取的集合，内鏈代表蜘蛛實际能走到的路径，日誌代表它真正走了哪些。三者對不上的地方，往往就是抓取效率的损失点。比如 Sitemap 里有、日誌長期没有，說明入口不足；日誌里有、内鏈里没有，說明存在歷史遗留地址或被外部引用的參數頁。
落地时可以先做這几件事
- 日誌至少保留 30 天，方便做周與周的對比。
- 按 UA 加 IP 段過滤出真實蜘蛛，單獨統計，不和普通訪客混在一起。
- 每天匯總一次：抓取總量、狀態碼分布、訪問最多的路径、慢請求清單。
- 出現異常时，按服務器、robots、内鏈、Sitemap 的顺序依次排查。
日誌反映的是抓取過程，不等于收錄结果，也不直接决定排名。它最大的價值，是让你在被告知之前，先知道自己這邊發生了什么。
把日誌当成一份持續更新的抓取记錄来看，很多問题就不必等到报表變色才動手。