报表里的“已發現，尚未抓取”“已抓取，尚未编入索引”看起来只差一步，實际卡住的位置完全不同。服務器日誌是少數能把這几步拆開的原始材料：它记錄蜘蛛什么时候来過、請求了哪個地址、返回了什么狀態碼，而不是搜尋引擎匯總之後的结论。日誌不能直接告诉你頁面會不會被收錄，但能帮你判断問题出在發現、抓取，還是後面的處理环节。
日誌能回答的三個問题
- 這個 URL 有没有被發現：日誌里從未出現過，通常意味着入口不足，而不是内容质量不够。
- 發現之後有没有真的請求：只有一次试探性的請求，和持續多轮的抓取，含义並不一样。
- 那次請求算不算一次有效抓取：返回 200 且内容是最终頁面，才算把頁面交了出去。
先確認請求是不是真的蜘蛛
User-Agent 字段任何人都可以伪造，只按 UA 字符串篩選，容易把爬虫和仿冒請求混在一起。常用做法是：
- 對可疑的高频請求做反向 DNS 查询，確認域名归属；
- 比對搜尋引擎公布的 IP 段，IPv4 與 IPv6 分開看；
- 注意 CDN、WAF、负载均衡可能只保留一份日誌，源站未必能看到全部請求。
几種常见情况怎么讀
反复抓老頁面，新頁面几乎不出現
這通常說明新的 URL 還没有找到可靠入口。可以顺着内鏈、列表頁、sitemap 的顺序回查：新頁面是否至少有一條来自站点内部、能被普通爬取的連結。日誌里没有任何记錄时，先补入口，比反复提交更有效。
新頁面有請求，但狀態碼不對
如果日誌里能看到新頁面的請求，返回的却是 301、302、403、404 或 5xx，那么問题在服務器侧，跟内容质量無關。需要区分是重定向鏈太長、權限拦截，還是抓取时刚好遇到故障。把同一 URL 的多次請求狀態碼按時間排開，很容易看出是偶發還是稳定。
抓取频次整体下滑
频次是服務器资源、更新节奏、响應速度共同作用的结果，短期波動不代表惩罚。先確認响應時間有没有變慢、是否有大量相似頁面在消耗抓取額度，再考虑是否收敛低價值 URL 的入口。
日誌和报表對不上时的检查項
- 时区：日誌按服務器時間记錄，报表按站点設定时区，跨天對比容易错位。
- 身份：移動端與桌面端蜘蛛、图片和渲染相關請求可能使用不同 UA。
- 缓存：CDN 命中时源站没有记錄，但蜘蛛确實拿到了頁面。
- 抽样：部分日誌方案只保留一部分记錄，不能当成全量資料使用。
一個可执行的自查顺序
- 導出最近两到四周的原始日誌，先按 UA 過滤出主要搜尋引擎的請求。
- 把目标 URL 清單與日誌里的地址做交叉比對，标出“從未出現”“出現過”“频繁出現”三類。
- 對出現過的地址按狀態碼分组，找出非 200 的部分，回到服務器定位原因。
- 對照 sitemap 與内鏈结构，確認新 URL 是否有稳定入口，入口是否多套了一层跳轉。
- 把结果记錄下来，隔一段時間再看同一批 URL 的變化，比一次性的结论更有參考價值。
日誌反映的是抓取過程，不是收錄结果。它能說明蜘蛛来没来、有没有拿到頁面，但頁面最终是否進入索引、出現在什么位置，還要看内容本身和质量判断，不能反向倒推。
把日誌当成一份過程记錄，用它排除“根本没被發現”“抓取被拦截”“服務器不稳定”這類前置問题，剩下的部分才轮到内容和质量层面去讨论。按這個顺序處理收錄問题，會清楚很多。