收錄問题排查时，後台的收錄數字只告诉你结果，不告诉你過程。服務器日誌记錄的是蜘蛛真實訪問過哪些 URL、什么時間訪問、拿到了什么响應。頁面迟迟進不了索引，日誌通常比报表更早给出线索。

第一步：把三類請求分開

日誌原始内容很杂，直接看容易誤判，先按 User-Agent 分层：

• 搜尋引擎蜘蛛：百度、Google、Bing 等，标识明确，是分析主体。
• 正常用戶訪問：包括浏览器预取和静態资源請求，占比通常很大。
• 其他爬虫：采集器、监控工具、SEO 工具，與收錄没有直接關系。

拆完之後，剩下要分析的資料量會小很多，也更容易看出規律。

第二步：看抓取频次和投放位置

频次不是越高越好，重点是分布是否合理。如果蜘蛛每天来几百次，但绝大多數落在首頁、列表頁和几個參數地址上，說明内鏈没有把路径带到深层頁面。

频次突然下降，一般先查這几項：

• 服務器响應變慢或频繁超时；
• 近期新增了大量低质或重复頁面，拉低了整体质量判断；
• robots.txt 或頁面指令被改動，挡住了抓取；
• 站点结构大改，舊入口返回 404，蜘蛛找不到落点。

反過来，频次正常但收錄不動，問题通常不在抓取环节，而在頁面本身。

第三步：看蜘蛛走過的路径

把日誌里的 URL 按目錄归類，可以直观看到蜘蛛的兴趣点：

• 請求集中在几個模板頁，說明其他模板缺少入口；
• 大量參數型 URL 被抓，說明篩選、排序、追踪參數没有做好規范化；
• 出現大量 404 和跳轉鏈，說明歷史連結没有清理干净。

這一步常能定位到“蜘蛛知道 URL 却没有繼續往下走”的具体位置。

第四步：看响應狀態和耗时

狀態碼在日誌里是分层的，每一類指向的原因不同：

• 频繁 5xx：服務器或後端不稳定，蜘蛛會主動降低抓取频率；
• 大量 404：可能是内鏈寫错，或者頁面已删但連結還在；
• 跳轉鏈過長：每次跳轉都會消耗抓取額度；
• 耗时明顯偏高的 URL：容易被中断，抓取不完整。

响應時間是常被忽略的一項。同样一批頁面，如果平均响應從几百毫秒變成几秒，抓取量下降几乎必然發生。

日誌不能回答的部分

日誌能證明“蜘蛛来過”，不能證明“頁面被收錄”。抓取和收錄之間還隔着内容质量、重复程度、URL 規范等判断。日誌里抓取正常、索引里却没有，就要回到頁面层面去看：

抓取是蜘蛛的動作，收錄是搜尋引擎的判断，两者的證據来源不同，不要用一個指标替代另一個。

一份可执行的日誌检查清單

1. 按 User-Agent 過滤出真實蜘蛛請求；
2. 統計每日抓取量，看趋势是否平稳；
3. 按目錄聚合 URL，看覆盖是否完整；
4. 統計狀態碼分布，重点看 5xx 與 404 的占比；
5. 統計平均响應時間，找出明顯偏慢的地址；
6. 挑出被反复抓取却始终未收錄的 URL，單獨检查内容與規范。

發現問题後怎么處理

• 响應慢：先解决服務器和資料库瓶颈，其他調整放在後面；
• 抓取集中：补充合理内鏈，把入口铺到缺少連結的模板；
• 參數泛滥：用規范标簽或抓取規則收敛；
• 404 與跳轉鏈：清理内鏈，把跳轉控制在一次以内；
• 反复抓取不收錄：從内容重复度、頁面價值和 URL 版本统一入手。

日誌的價值，在于把“收錄不好”這句模糊判断，拆成具体的時間、地址和响應。落到具体 URL 上，處理起来才有方向。