聊蜘蛛抓取，多數人先去看後台报表。报表好用，但它是加工過的二手資料，滞後、聚合、颗粒度粗。真正原始的一手记錄在服務器日誌里：蜘蛛几点来、要了哪個 URL、服務器回了什么、返回多少字节、花了多少毫秒，全都在。学會讀日誌，很多“抓取好像不太對”的猜测就能落地成几條具体记錄。
先弄清楚日誌里哪些字段有用
不同服務器格式不一样，但下面這几列基本都有，讀抓取情况主要靠它們：
- 請求 IP 與 User-Agent：判断是不是搜尋蜘蛛，以及是哪一家。
- 訪問時間：看抓取的時間分布與频率。
- 請求方法與 URL：GET 還是 HEAD，抓的是頁面還是图片、CSS、JS。
- 狀態碼：200、301、404、5xx，一次抓取里各占多少。
- 响應字节數：返回 200 但字节數異常小，值得警惕。
- 响應時間：慢在哪個环节，日誌里能看出大概。
- Referer（如果有）：有时能看到蜘蛛是從哪個頁面跳過来的。
別只信 UA，先做一次身份核對
User-Agent 是可以伪造的。做日誌分析前，先確認筛出来的是真蜘蛛。常见做法是拿 IP 段去官方公布的范围里核對，或者對少量 IP 做反向 DNS 查询，看域名是否落在官方域下。這一步不做，後面所有结论都可能建立在被刷的假流量上。
從日誌里能讀出的三件事
一、抓了什么，以及漏了什么
把一段時間内蜘蛛請求過的 URL 去重，再和站点實际的 URL 總表對比。差集就是“蜘蛛没来過的部分”。這批 URL 里，有的是孤儿頁面，有的被 robots 挡住，有的虽然在 Sitemap 里却没有任何内鏈指向。哪一類占多數，决定先修哪里。
二、拿到的是什么
統計蜘蛛請求的狀態碼分布。理想情况是绝大多數 200 加少量 304。如果 3xx 占比很高，說明站内大量連結指向了會跳轉的 URL，蜘蛛每次都要多走一步；如果 4xx 集中在某個目錄，多半是某處模板輸出了失效連結；如果 5xx 时不时出現，那就是服務器稳定性在拖抓取的後腿。
三、走的路径和频率
按時間排序，單看一個蜘蛛 IP 的請求序列，能還原它這一趟的走法：從哪個頁面進来，先抓了什么，往哪個目錄深入。如果發現它總在同一批 URL 上反复往返，或者深度到第二层就停住，那通常不是蜘蛛懒，是站内路径在那里断了。
几種典型的日誌形態，對應不同問题
- 某個目錄下大量 404，且 Referer 集中在同一個頁面——模板里有失效連結。
- 同一 URL 短時間内被高频請求，狀態碼全是 5xx——服務器扛不住，蜘蛛在重试。
- 列表頁抓得很勤，詳情頁寥寥——列表到詳情的連結太弱、太深。
- 大量 URL 只在 Sitemap 里出現，日誌中從無记錄——這些 URL 缺少内鏈入口。
- 返回 200 但字节數長期很小——可能是空内容或软 404 的伪装。
動手分析的几個步骤
- 先把非蜘蛛流量過滤掉，只留经過核對的目标蜘蛛记錄。
- 按天或按周切片，別把一整年的日誌混在一起看，趋势會被平均掉。
- 統計狀態碼分布、URL 去重數、單日請求量三條基础曲线。
- 挑几個異常目錄，按時間還原訪問序列，看蜘蛛怎么走到這里。
- 把结论落成具体改動：修連結、改 robots、补内鏈、加缓存或調服務器。
- 改完观察同一批指标的下一周期變化，用日誌驗證，而不是凭感觉。
日誌是抽样，不是全貌。蜘蛛不會把每個 URL 的每次訪問都寫進你能看到的文件里，压缩、轮轉、CDN 层都可能让记錄不完整。做判断时留点余地，別拿一天的日誌给整站定性。
日誌分析解决不了的事
它能告诉你蜘蛛来過、拿了什么、走得顺不顺，但不能保證某個 URL 一定被收錄，也不能替你决定内容好不好。把日誌当成体检报告：指标異常时指向可能的問题，改完之後看指标有没有回来。至于收錄和排名，那是另外一整套變量的事。
如果站点不大、日誌量不多，每周花半小时導出一次，看看狀態碼和訪問量两條线就够了。真正有價值的不是分析得多深，而是發現問题之後改得够快。