很多收錄問题追到最後，並不是頁面质量差或者内容重复，而是蜘蛛根本没能把頁面完整拿回去。抓取是收錄的前一步，這一步失敗，後面的索引、選頁、排序都無從谈起。当你在日誌里看到大量 5xx、超时或者连接中断，先把注意力放回服務器本身。
先分清三種情况
- 抓取失敗：請求没拿到正常响應，頁面连“被看见”都算不上；
- 抓取成功但未收錄：内容已经拿到，卡在索引阶段的判断或排队；
- 收錄後消失：曾经進過索引，後来被移除。
三者的處理方向完全不同。日誌里的狀態碼，是区分它們最直接的依據，比反复刷新後台的收錄狀態有用得多。
服務器端常见的失敗信号
- 5xx（500、502、503、504）：程序異常、後端超时、網關配置問题；
- 连接超时：服務器响應太慢，蜘蛛等不到结果就断開；
- 连接被拒绝或重置：防火墙、WAF、限流規則把請求挡掉了；
- 429：訪問频率被限制，等于明确告诉蜘蛛降速；
- 返回不完整：狀態碼是 200，但 HTML 被截断，正文缺失。
最後一種最容易被忽略，因為日誌看上去是“成功”的，實际抓到的却是個残缺頁面。
一個可执行的排查顺序
- 拉取一段時間段的訪問日誌，按狀態碼分類統計，看 5xx 占比和集中出現的 URL 段；
- 观察失敗的時間分布，是全天均匀，還是集中在备份、定时任務、流量高峰；
- 單獨测几個失敗 URL 的响應時間，区分是“慢”還是“直接报错”；
- 检查 CDN、WAF、安全插件是否存在誤拦截，尤其是新出現的爬虫 IP 段；
- 看資料库、缓存、外部接口的耗时，很多时候慢的是頁面依赖的下游服務；
- 確認服務器资源（CPU、内存、连接數）是否在抓取时段被打满。
挡爬虫要挡得精细
有些站点為了减轻压力，直接對整個 IP 段返回 403，结果把正常的抓取也一起挡掉了。更稳妥的做法是：對高频請求做限速而不是拒绝，给静態资源加缓存，把動態頁面的查询结果缓存起来，必要时在 robots.txt 里調整抓取节奏，而不是用错誤狀態碼回應。
用 403 或 503 大面积回應爬虫，短期省了流量，長期可能让整站的抓取节奏被拖慢。
抓取恢复之後
服務器稳定下来之後，抓取會逐步恢复，但收錄不會同步回来。需要给蜘蛛重新訪問的机會：保持内鏈可達、站点地图正常、重要頁面不要压在很深的层級。曾经被标记為失敗的 URL，往往要等下一轮抓取才會重新评估，這段時間里持續观察日誌中的狀態碼變化就够了，不必频繁改動頁面。
几個容易走偏的做法
- 一看到抓取失敗就怀疑被惩罚，先排除服務器問题；
- 把 5xx 頁面直接 301 到首頁，制造新的跳轉與内容不對應問题；
- 频繁更換服務器或 IP，让抓取节奏反复重新适應；
- 只盯首頁狀態，忽略列表頁和詳情頁的失敗率。
抓取失敗本质上是服務器問题，不是内容問题。把狀態碼分布、响應時間、拦截規則這三件事查清楚，收錄才有繼續往下走的基础。