有些站点會遇到一種很难复現的情况：搜尋里能搜到頁面，隔几天再看又不见了，再過一阵子又出現。翻日誌會發現，爬虫来的时候並不總是拿到正常响應，偶尔是 500、502，偶尔是连接超时。這類問题往往不是内容质量問题，而是服務器可用性把收錄狀態搅動了。

間歇性失敗為什么會動摇收錄狀態

搜尋引擎對頁面的收錄判断建立在多次抓取之上。一次成功抓取可能让頁面進入索引，但如果後續几次抓取都失敗，系統會認為頁面目前不可訪問，可能把它從索引里暂时撤下，或者降低後續抓取频率。等服務器恢复正常，頁面又可能重新被抓到，于是形成收錄狀態反复的現象。

關键在于失敗是間歇性的，而不是持續性的。持續性的 5xx 一般會被识別為服務器故障，處理方式相對明确；間歇性失敗則容易被誤判成頁面本身有問题，排查时也更容易被忽略。

第一步：確認失敗是偶發還是成片

先從服務器日誌里筛出爬虫 UA 的請求，按狀態碼分组統計。重点看三個比例：

• 5xx 占全部爬虫請求的比例，超過 1% 就值得查
• 超时請求的占比，包括長時間無响應和响應時間異常拉長
• 失敗請求是否集中在某個時間段

如果失敗集中在几分钟内，多半是某個進程重啟、缓存击穿或資料库抖動。如果全天零散分布，則更可能是资源長期吃紧，比如内存不足、连接數打满。

第二步：看失敗發生在哪一层

同样是 5xx，来源可能完全不同。按下面的顺序往下查，能少走弯路：

1. 反向代理或负载均衡层：连接被拒绝、上游超时
2. 應用层：脚本报错、内存溢出、第三方接口拖慢整体响應
3. 資料库或缓存层：连接池耗尽、慢查询堆积
4. CDN 或 WAF：把爬虫請求誤判為異常流量而拦截，返回 403 或 5xx

特別留意最後一項。有些站点開啟防護策略後，正常用戶訪問没問题，但爬虫的請求特征触發規則，被間歇性拦截。這類失敗在日誌里看起来像服務端错誤，實际是策略配置問题，改代碼是解决不了的。

第三步：分清對已收錄頁和未收錄頁的不同影响

两種情况要分開看。已经收錄的頁面被抓取失敗，風險是索引狀態波動、展示信息變舊；還没有收錄的新頁面抓取失敗，風險是發現被推迟，内鏈传递的權重也可能被浪費。

如果新頁面的失敗率明顯更高，可以检查是不是這些頁面的生成逻辑更重，比如需要實时聚合、調用外部接口。把這類頁面的渲染成本降下来，往往比反复改内容更有效。

收錄狀態反复，先別急着改标题和正文。先確認爬虫每次来的时候，服務器是不是都正常回應了。

一個可执行的核對清單

1. 導出近一周爬虫請求日誌，按狀態碼和時間分布做統計
2. 找出失敗率最高的 URL 類型，判断是模板問题還是個別頁面問题
3. 检查 WAF、CDN、限流配置是否對爬虫請求生效
4. 確認监控告警覆盖 5xx 與响應時間，而不只是端口探活
5. 修复後观察两周，看收錄狀態是否趋于稳定，而不是只看單日資料

把稳定性纳入日常巡检

服務器稳定性属于基础设施問题，它不會直接带来收錄，但會持續消耗已经取得的收錄结果。把它放進日常巡检項里，比等到收錄量下滑再回头逐項排查要省事得多。