站点运营里最容易拿到的資料，其實不是後台报表，而是服務器日誌。它记錄的是蜘蛛真實来過、真實請求過的地址，比任何第三方工具的估算都直接。問题在于，多數人翻日誌只看一個總量，看完就關掉，里面真正能推動决策的信息被浪費了。這篇讲怎么把日誌讀出点有用的東西。
一、日誌里值得看的字段
不同服務器软件的日誌格式略有差异，但常见的组合字段基本够用：
- 時間與时区：先確認服務器日誌用的是本地時間還是 UTC，跨天對比时這一点會被放大。
- 請求方法與 URL：看清請求的是頁面、图片還是接口，路径要保留查询參數，否則分頁和篩選頁會被合並統計。
- 狀態碼：200、301、404、500 的分布，比總量更能說明問题。
- 响應字节：接近 0 的 200 响應，往往意味着空壳頁面或渲染失敗。
- User-Agent：用来初步篩選爬虫，但僅凭它並不足以判断身份。
- IP：配合反向解析做真伪校驗。
- 来源頁：不是所有蜘蛛都會带，但带着的时候能看出它從哪里顺着連結過来的。
二、先確認是不是真蜘蛛
User-Agent 可以随便伪造，所以看到一串熟悉的爬虫标识时，不要立刻当成搜尋引擎的抓取。比較稳妥的做法是：
- 對可疑 IP 做反向 DNS 解析，看域名是否属于對應搜尋引擎的官方域名後缀。
- 再把解析结果正向查一次，確認能回到同一個 IP，避免被伪造的解析记錄骗過。
- 對照官方公布的 IP 段范围做交叉驗證。
- 观察抓取路径是否符合爬虫行為：真爬虫通常按連結顺序扩散，伪爬虫常集中在少數几個地址上高频請求。
把伪造 UA 的請求算進抓取量里，會導致對站点抓取状况的整体誤判：看起来蜘蛛很活跃，實际搜尋引擎来的次數少得多。做月度對比时，最好把手動篩選過的資料單獨存档。
三、把日誌整理成几個可看的指标
原始日誌太细，需要先聚合成指标再看：
- 每日抓取總量趋势，观察是否有台阶式的突變。
- 狀態碼分布：404 和 5xx 各自的占比是否在上升。
- 去重後的 URL 數量，與總請求數分開看，前者反映覆盖，後者反映频次。
- 首頁、栏目頁、内容頁三類的抓取占比，判断蜘蛛是否集中在浅层。
- 新頁面從發布到首次被抓的天數，這是衡量發現渠道是否顺畅的直观指标。
- 單個 URL 的重复抓取次數，找出被反复抓取却没變化的地址。
四、几個常见問题的判断思路
内容更新了，但看不到抓取
先在日誌里按 URL 精确搜尋，確認是完全没有請求，還是来了但抓的是舊版本。前者偏向發現渠道的問题，後者更可能與缓存或响應头有關。
抓取量突然下降
先看服務器侧有没有集中的 5xx 或响應時間飙升，再看 robots.txt、CDN 規則、防火墙是否在這段時間有過變更。日誌按天排列，和變更记錄放在一起對齐，多數異常能找到對應时点。
蜘蛛總在低價值頁面打轉
把抓取频次最高的地址排個序，如果前列被标簽頁、篩選頁、搜尋结果頁占據，說明内鏈结构和可抓范围需要收缩，而不是繼續加内容。
五、一個轻量的每周流程
- 導出最近七天的日誌，按爬虫标识初步過滤，並做真伪校驗。
- 聚合出上文的几項指标，與上一周做對比。
- 列出抓取次數最多和最少的两组頁面，各抽查几條，看是否符合预期。
- 把異常項對應到具体動作：改内鏈、改响應头、收窄可抓范围或調整更新节奏。
- 存档本周資料，至少保留几個月的對比基线。
六、容易踩的坑
- 只看 CDN 日誌或只看源站日誌。邊缘节点的缓存命中請求可能不會回源，两邊資料對不上时要先搞清楚口径。
- 日誌按小时或按大小切分，直接拿文件做統計，跨天資料被切断。
- 用總請求數代表抓取覆盖，忽略了去重。
- 拿一天的采样資料下结论，蜘蛛的抓取本身有波動。
- 把日誌当成唯一依據。它只能說明来過的部分，不能說明没来的原因，需要和站点地图、内鏈结构一起看。
日誌不會直接告诉你要改什么，但它能把模糊的猜测變成可以核對的记錄。坚持每周花半小时讀一遍，比等到收錄出問题再回头翻要轻松得多。