不少站点把收錄問题归到内容质量或外鏈上，但翻開服務器日誌，最先暴露的往往是响應異常。蜘蛛每次来訪，首先拿到的是狀態碼和响應時間，只有這一层稳定，後面的解析、渲染、入库才有意义。
响應层為什么排在收錄流程前面
抓取是收錄流程的第一步。頁面返回 200 且内容是完整的 HTML，蜘蛛才有東西可解析；如果每次抓取都撞上超时、5xx，或者被限速挡回来，這個 URL 在抓取队列里的優先級會逐渐下降。這不是某種惩罚，而是抓取资源會被優先分配到能稳定拿到内容的地址上。
几類常见的異常响應
5xx：服務器侧报错
500、502、503、504 都表示服務器這邊出了問题。偶發几次通常影响有限，但如果同一批 URL 反复出現 5xx，抓取频次會被主動調低。用 503 做临时维護本身没错，但最好配合 Retry-After，並且別長期挂着；長期 503 的效果接近于让這些頁面停止被更新。
429：請求過多
429 常出現在 CDN 或 WAF 层。它和 5xx 不一样，含义是「能响應，但你現在来得太频繁」。蜘蛛被限速挡下後，既拿不到内容，也無法判断頁面是否變化。需要排查防護規則是不是把已知的搜尋蜘蛛一起拦了，或者站点自定义的限速阈值设得過低。
超时與连接中断
响應時間過長同样影响抓取。頁面本身不复杂，但接口、第三方脚本或資料库查询让它经常几十秒才吐出内容，蜘蛛可能直接断開。這類情况在日誌里往往表現為没有狀態碼，或者長時間卡在等待阶段。
名义 200，内容却不是頁面
還有一種更隐蔽的情况：狀態碼是 200，返回的却是「服務器繁忙」「内容不存在」這類提示。對蜘蛛来说這是一個正常頁面，但頁面是空的，長期如此很难被当作有效頁面處理。這類响應應当改成對應的错誤狀態碼，让语义回到正确的位置。
排查顺序
- 取一段连續几天的日誌，按狀態碼分布做統計，先看非 200 請求的比例和趋势。
- 把異常請求按 UA、IP 段、URL 目錄分组，判断是全局問题還是集中在某個模块。
- 對比同目錄下正常頁面與異常頁面的差异，看是否有共同的模板、接口或參數特征。
- 如果異常集中在固定時間段，检查是否與备份、跑批、批量發布撞在一起。
統計时別只看平均值。平均值容易被缓存命中的請求拉低，中位數和較高分位數更能反映内頁的真實响應情况。
處理时容易忽略的几点
- 別只盯首頁。首頁通常是缓存命中最好的位置，問题多集中在内頁和列表頁。
- 区分限速與故障。429 需要放宽規則或加白名單，5xx 要去修代碼、资源或配置，處理方式完全不同。
- 保持狀態碼语义正确。内容已刪除就返回 404 或 410，不要用 200 兜底。
- 不给蜘蛛單獨做一套内容。返回给蜘蛛和用戶的内容不一致，會带来新的問题。
- 控制發布节奏。一次上线大量新 URL，容易在短時間内触發限速。
响應层修好之後，收錄不會立刻跟着變。它只是把「能不能稳定拿到内容」這一步打通，頁面是否進入索引，還要看内容质量、重复程度和站点整体情况。
修完怎么看有没有改善
不要只對比收錄總數。更實用的做法是固定一批之前频繁出错的 URL，持續观察它們的狀態碼分布有没有變好、抓取次數有没有回升、頁面内容有没有被重新更新。如果响應已经稳定两三周，抓取仍然不動，那問题多半已经轉移到内容或结构层面，這时候再回過头查模板、内鏈和重复内容，方向會清楚很多。