很多站点排查抓取問题，习惯先從内容、内鏈和 Sitemap 找原因，却忽略了一個更前置的條件：蜘蛛每次請求都得先拿到一個正常的 HTTP 响應。服務器端的抖動會直接改變蜘蛛對整站的處理方式，而且影响往往比想象中更持久。
四類响應，四種後果
從蜘蛛的角度看，一次請求的结果大致可以分成四類，處理逻辑差別很大：
- 404 與 410：明确告诉你頁面不存在。短期會减少這類 URL 的抓取，長期會把它們從待抓列表里清出去。這属于信息有效，不算故障。
- 500、502、503、504：服務器端出错。蜘蛛無法判断是临时故障還是永久問题，通常先标记為待复查，過一段時間再试。
- 连接超时：請求發出去了，但久久没有响應。對蜘蛛来说這和 5xx 類似，只是它连错誤碼都拿不到。
- 连接被中断：响應头或部分内容返回後连接断開。這種情况最尴尬，蜘蛛拿到的是一份不完整的内容。
關键在于：4xx 是有效信息，5xx 和超时是無效信息。無效信息堆积多了，蜘蛛會認為這台服務器不稳定，從而主動降低抓取频率。
降频之後，恢复比下降慢得多
抓取速度被下調，不是当天出問题、第二天就能恢复的。蜘蛛通常需要连續观察到一段時間的稳定响應，才會逐步把抓取量提回来。有些站点會發現，故障持續了几小时，但抓取量的恢复花了两三周。
更麻烦的是连鎖反應：抓取频率降低，意味着新 URL 被發現得更慢、更新頁面的复查間隔被拉長、本来能抓完的頁面抓不完。這时候如果再去調 Sitemap 或者加内鏈，效果會被服務器的下限压住。
内容层面的優化决定上限，服務器稳定性决定下限。当下限被压低时，上限的調整几乎看不出来。
几個容易被忽略的抖動来源
- 資料库慢查询：列表頁、搜尋頁在高峰期响應時間從几百毫秒涨到几秒，蜘蛛刚好撞上就被记為超时。
- CDN 回源超时：邊缘节点正常，但回源失敗，蜘蛛拿到的是 5xx，而你在源站日誌里可能什么都看不到。
- 限流策略過嚴：把正常蜘蛛和異常流量一起限掉，返回 429 或 503。
- 發布與重啟：每次部署都有一小段時間返回 502，如果部署频繁，這個抖動會被持續记錄。
- 备份與其他抓取工具：本地备份任務和第三方采集占满带宽，蜘蛛請求排队超时。
日常该看哪些信号
- 服務器日誌里 5xx 的比例，按小时看，而不是按天看。
- 响應時間的 P95、P99，而不是平均值，平均值會把高峰掩盖掉。
- 抓取日誌中的抓取频率曲线，看它在故障之後有没有明顯下台阶。
- Sitemap 中 URL 的抓取覆盖變化，判断是不是有一批頁面長期抓不到。
- 部署、重啟、备份的時間点，和日誌異常時間是否重合。
把稳定性做成可预期的事
不必追求零故障，但要追求故障时有明确行為：
- 計划内维護返回 503 並带上 Retry-After，比直接断连更友好。
- 為蜘蛛来源設定合理的白名單與限流阈值，不要和其他流量共用一套規則。
- 把資料库慢查询和回源失敗纳入监控，不要只看源站返回的狀態碼。
- 部署时采用平滑重啟，避免每次發布都产生一批 502。
抓取優化里，連結结构、Sitemap 和内容质量都重要，但它們都建立在蜘蛛能稳定拿到响應這個前提上。先把這個前提守住，再谈其他調整，顺序會顺很多。