遇到收錄問题，多數人第一反應是打開站長平台看索引量。但索引資料更新有延迟，展示时也常有抽样，尤其在排查“新頁面為什么迟迟不進索引”這類問题时，服務器日誌往往能更早给出线索。日誌记錄的是蜘蛛的来訪行為，它不能直接告诉你结果，但能帮你把范围缩小到一個具体环节。
日誌能回答收錄問题里的哪一部分
要先分清：日誌是過程資料，索引是结果資料。日誌能告诉你蜘蛛有没有来過、来了几次、請求了哪些 URL、拿到什么狀態碼；它不能告诉你頁面最终有没有進索引——這一部分仍然要靠索引狀態报告和實际搜尋驗證。把两者分開，排查思路會清楚很多，也不容易把“抓取正常”誤当成“收錄没問题”。
先確認三件事，再谈別的
1. 来的是不是真蜘蛛
只看 User-Agent 不够，UA 是可以伪造的。更稳妥的做法是记錄訪客 IP，用反向解析或官方 IP 段列表核對。如果日誌里大量“蜘蛛”来自同一批可疑地址，而且只盯參數頁、後台路径，那多半是采集或掃描工具。基于假蜘蛛的資料去判断收錄，方向一開始就偏了。
2. 来的频率和时段
把某個目錄、某類頁面單獨拉出来，看每天被請求多少次、集中在什么时段。如果整站抓取量在涨，但新目錄一次都没被訪問，問题在發現环节；如果新目錄被反复抓取却始终不進索引，那更可能在頁面质量、重复度或内容價值上。
3. 抓的是哪些 URL
統計蜘蛛請求的 URL 分布：是老頁面被反复抓，還是新頁面也有人来。注意区分正文頁、分頁、篩選頁和參數頁，這几類被訪問的比例，常常能解释為什么抓取量看着不少、收錄量却不動。
狀態碼分布是最容易被忽略的一段
把日誌按狀態碼做一次匯總，比逐條翻更有效率：
- 200：正常抓取。顺便看响應体大小是否合理，過小的响應可能是空壳頁或渲染失敗。
- 301 / 302：跳轉鏈路過長會让蜘蛛停在中間，检查是否存在多层跳轉和跳轉循环。
- 404 / 410：確認是老連結有意下线，還是配置错誤導致的大面积失效。
- 503：服務器临时不可用。短時間大量出現，要查负载和防護策略。
- 403 / 429：被拦截或限流。蜘蛛會被“劝退”，之後来訪频率可能明顯下降。
抓取成功率掉下来之後再谈收錄，顺序就反了。
用日誌推断“發現”有没有發生
sitemap 提交、内鏈更新、外鏈出現，這些動作都會体現在日誌里，最直接的表現就是某個 URL 第一次被請求。如果一個新頁面發布好几天，日誌里连一次請求都没有，那就不必纠结索引狀態了，問题在 URL 發現：检查它是否出現在 sitemap 里、内鏈是否可達、是否被 robots.txt 挡住。
把日誌和另外两份資料對照起来
只看日誌容易下结论過早，建议三份資料交叉：
- 日誌：蜘蛛来過没有、抓了什么、拿到什么狀態碼。
- sitemap 與内鏈清單：哪些 URL 是你希望被發現的。
- 索引狀態报告與實际查询：哪些真的進了索引。
三者對照之後，通常能落到一個具体环节：没被發現、發現了没抓、抓了没索引、索引了又被移出。每種情况對應的處理方式差別很大，先定位再動手，比反复提交 URL 有效得多。
几個常见的坑
- 只統計總抓取量，不看 URL 分布，结论容易失真。
- 把假蜘蛛算進去，得出“蜘蛛很活跃”的错觉。
- 只用某一天的日誌下判断，而抓取本身有明顯波動。
- 忽略 CDN 或缓存层日誌，看到的請求數並不完整。
日誌是過程資料，索引是结果資料。過程正常不代表结果一定出現，但過程明顯異常时，结果基本不會好。
落地上不必太复杂：每周固定看一次日誌，新栏目、新目錄上线後的两三周重点盯。先確認抓取這一段是否顺畅，再去看索引資料，判断會稳得多。