不少站点运营的日常是盯着後台的流量曲线，却很少打開服務器上的訪問日誌。日誌里存着最原始的一手记錄：谁在什么时候来、請求了哪個地址、服務器返回了什么。把這份记錄讀明白，比事後反复猜测“蜘蛛是不是不喜欢我的站”要實在得多。
日誌能回答哪些具体問题
- 蜘蛛最近有没有来，抓取频次是變多還是變少；
- 它主要停留在哪些目錄，哪些栏目長期無人問津；
- 哪些地址被反复請求，哪些返回了 4xx 或 5xx；
- 抓取請求的响應時間是否明顯偏長。
第三方工具也能看到其中一部分，但往往有采样和延迟。日誌没有這些加工环节，是更接近事實的那份資料。
打開日誌先看這几列
不同服務器软件的格式略有差別，但核心字段基本一致，重点盯住下面几項：
- 訪問時間：判断抓取是否集中在某個时段，是否與你的發布节奏、备份任務、定时脚本撞车；
- User-Agent：用来区分不同来源的爬虫，注意不要把伪装成蜘蛛名的采集程序当成搜尋引擎；
- 請求地址：看清蜘蛛要的是頁面、图片還是接口，是否大量落在不该被反复抓的路径上；
- 狀態碼：200 之外的结果都值得留意，尤其是成片的 404、403、429 和 5xx；
- 响應字节數與耗时：字节數為 0 或耗时異常，通常說明頁面渲染或後端出了問题。
三種值得警惕的信号
第一，抓取量突然掉到接近零
先別急着归因到内容质量。按顺序確認：服務器是否被防火墙拦截、是否触發過频率限制、robots.txt 是否被誤改、證书是否過期。這些都属于自己這邊能立刻查清的問题。
第二，抓取集中在少數地址上打轉
如果日誌里同一個列表頁、同一组带參數的地址被反复請求，說明站内的抓取路径可能太單一，或者存在蜘蛛绕不出去的循环结构。可以去检查分頁、篩選參數和站点地图里的地址是否合理。
第三，大量請求返回错誤
成片的 404 往往意味着站内連結指向了已失效地址，或者站点地图没有同步更新；成片的 5xx 則更像服務器资源或程序层面的問题，需要结合负载和错誤日誌一起看。
一套可执行的自查流程
- 把日誌按天切分，先過滤出主要搜尋引擎的 User-Agent；
- 統計当天請求總數、獨立地址數、各狀態碼占比；
- 排出請求量最高的二十個地址，逐個判断是否属于應该被抓的頁面；
- 筛出狀態碼非 200 的记錄，归類成“連結失效”“權限拦截”“服務異常”三類；
- 對比前一周同一時間段的資料，找出明顯偏离常態的項；
- 把確認的問题轉成待办：修連結、改配置、加监控，並约定下次复查時間。
這套流程不需要复杂工具，一段命令加一個表格就能跑起来，關键是养成固定周期查看的习惯，而不是出問题才翻。
需要提醒的是：日誌只說明蜘蛛来過、抓過某個地址，並不代表這個地址一定會被收錄或获得好的展現。它是一份诊断材料，不是成绩單。
顺手把日誌留好
很多服務器預設只保留最近几天的日誌，等到想對比歷史資料时才發現已经滚掉了。建议至少保留 30 到 90 天，並做压缩归档。日誌占用的空間不大，但它在排查抓取異常、定位服務器故障、复盘改版效果时，往往是最先被需要的那份材料。