抓取失敗和收錄是两件事，但會互相牵连
搜尋引擎處理一個 URL，大致分两步：先抓取，再判断是否值得進索引。抓取失敗發生在第一步，單次失敗通常没有後果，爬虫下次還會来。麻烦在于失敗變成常態：某個目錄下的地址反复超时或返回 5xx，爬虫會降低訪問频率，新頁面被發現的間隔被拉長，已经收錄的頁面也可能因為拿不到最新版本而停在舊快照。
抓取是入口，收錄是结果。入口偶尔堵一次，结果不會立刻變；持續堵，结果就會慢慢變差。
抓取失敗拖慢收錄的三種表現
- 新頁面發現變慢：sitemap 提交了，日誌里也见到爬虫，但請求反复超时或返回 5xx，URL 一直停在「已發現」狀態。
- 索引更新滞後：内容改過之後，搜尋结果里長期顯示舊标题、舊摘要，因為爬虫没取到新版 HTML。
- 抓取量被浪費：同一批地址被反复重试，真正需要抓的頁面反而排在後面，配額没變，有效产出變少。
日誌里先確認這几组數字
不要只看「今天蜘蛛来了多少次」。按小时或按天統計下面几項，趋势比單日绝對值更有參考價值：
- 狀態碼分布：2xx、3xx、4xx、5xx 各自的占比，5xx 長期偏高就值得看一眼。
- 响應時間分位：平均值容易被少數快請求拉低，重点看 90 分位和超时次數。
- 失敗集中在哪類 URL：是某個栏目、某種參數组合，還是全站随机出現。
- 抓取總量趋势：如果總量在下降、失敗率在上升，說明問题已经影响到爬虫的訪問意愿。
按這個顺序排查
- 先確認监控和日誌是否同源。有些「5xx」来自 CDN 或负载均衡层，源站日誌里根本没有這條請求。
- 判断是應用层還是資料层。慢查询和连接池耗尽，往往表現為大面积 504，而不是明确的报错。
- 看是否只有爬虫触發的路径慢，比如带參數的篩選頁、站内搜尋、需要實时計算的列表頁。
- 检查反爬和限流規則是否誤伤，频率限制、UA 判断、IP 封禁都可能让爬虫拿到 403 或空响應。
- 最後才考虑服務器規格。多數「扛不住」的情况，真正原因是某個頁面没做缓存或某個查询没加索引。
恢复期做什么、不做什么
問题修好後不必急着加動作，爬虫的訪問频率通常會自己回升，時間從几天到几周不等，取决于站点規模和過去的稳定程度。可以做的：
- 把确實需要收錄的 URL 重新整理進 sitemap，去掉已经下线的地址。
- 確認重要頁面現在返回 200，並且服務端返回的 HTML 里就有正文内容。
- 用抓取工具模拟一次請求，確認狀態碼和响應時間正常。
不建议做的：因為着急收錄而临时放開大量本不该收錄的頁面，或者用 noindex、robots.txt 遮挡来「减轻压力」。這些手段會改變站点的收錄结构，恢复起来比修服務器麻烦得多。
观察窗口要给足
修复後至少观察一到两周再下结论。單日資料波動說明不了什么，要看的是失敗率是否回落、抓取總量是否回升、新頁面是否開始進入索引。三者方向一致，才說明這次調整确實生效了。