做收錄排查时，很多人第一反應是内容质量、内鏈、sitemap。但如果去翻服務器日誌，會發現另一類問题：搜尋蜘蛛确實来過，只是請求被挡回去了，或者响應太慢直接中断。這類失敗不會在頁面上留下痕迹，却會让收錄一直上不去。
抓取失敗和頁面质量差，是两條不同的线
頁面质量差，通常表現為已抓取但未编入索引；服務器端抓取失敗，表現為抓到一半没下文，甚至 URL 長期停在“已發現”狀態。两者的處理方式完全不同，先分清楚再動手。
判断依據其實很简單：看日誌里同一批 URL 的狀態碼分布。如果大量返回 5xx、超时，或者請求根本没到達應用层（被 WAF、CDN 拦截），那就不是内容問题。
常见的几類服務器端抓取失敗
5xx 狀態碼
- 500：應用报错，可能是某個查询、模板或第三方接口挂了。
- 502 / 504：反向代理拿不到後端响應，常见于後端超时或進程被打满。
- 503：服務暂不可用，短時間维護时可以用，但要配合 Retry-After，別長期挂着。
搜尋引擎對 5xx 的處理是“稍後再来”，不會立刻删掉 URL，但如果持續几周都失敗，抓取频率會明顯下降，已有的收錄也可能被降級。
超时和连接中断
服務器 TTFB 太高、响應体太大、或者连接被中途掐断，蜘蛛可能等不到完整内容。日誌里往往看不到狀態碼，只有连接被重置或超时的记錄。這類問题最容易被忽略，因為頁面在浏览器里“能打開”。
429 和訪問频率限制
一些站点用 WAF 或限流组件挡爬虫，規則设得太嚴會把正常搜尋蜘蛛也一起挡掉。表現為特定 UA 或特定 IP 段大量 403、429，而普通用戶訪問正常。
為什么偶尔失敗也會拖慢收錄
- 蜘蛛會根據歷史成功率調整抓取频率，失敗率高的目錄會被降频。
- 新 URL 的首次抓取如果失敗，可能被放進重试队列，等待時間比正常發現長得多。
- 反复失敗的 URL，即使後来恢复了，重新被信任也需要一段時間。
抓取失敗不會直接等于不收錄，但會持續消耗你在 URL 發現和内容建设上投入的效果。
一套可以照着做的排查顺序
- 拉一周的蜘蛛日誌，按狀態碼分组統計，看 5xx、403、429、超时的占比。
- 把失敗請求的時間段和服務器的 CPU、内存、慢查询日誌對齐，找高峰点。
- 检查 CDN、WAF、防火墙規則，確認没有誤伤搜尋蜘蛛的 UA 和 IP 段。
- 检查 robots.txt 和頁面 meta，排除“一邊挡一邊想收錄”的配置冲突。
- 抽查几個失敗 URL，用命令行带蜘蛛 UA 請求一次，尽量复現問题。
- 修复後观察狀態碼是否回到 200，以及抓取频率是否回升。
修复之後，怎么確認真的恢复了
別只看單次請求成功。更可靠的信号是：同一目錄下多個 URL 在一段時間内稳定返回 200，且日誌里出現持續、規律的抓取，而不是零星几次。必要时可以在 Search Console 里看抓取統計，或者手動請求重新抓取几個代表性 URL，但不要指望一次提交就立刻生效。
几個容易踩的坑
- 把 503 当成省事的挡箭牌，長期返回，收錄會被慢慢清掉。
- 只在測試环境看頁面正常，忽略了生产环境的超时和限流。
- 為了防采集把 UA 判断寫死，结果誤伤搜尋蜘蛛。
- 服務器恢复後不做观察，以為狀態碼正常收錄就會自動跟上。
服務器稳定不是收錄的充分條件，但它是必要條件。把狀態碼、响應時間和拦截規則這几件事理顺，再回头看内容质量和 URL 規范，排查會顺很多。