頁面能不能被收錄，前面還有一步很容易被忽略：蜘蛛来抓的时候，服務器到底回了什么。响應狀態和响應速度，直接决定了這次抓取是有效、被放弃，還是被延後。
先分清：抓取失敗和内容不合格是两回事
内容质量的問题，通常發生在蜘蛛已经拿到頁面之後。而服務器响應的問题發生在更早的阶段——蜘蛛连頁面都没完整拿到，後面的判断根本無從谈起。所以当一批頁面集体没收錄时，先看日誌里這些 URL 的响應，往往比直接改内容更快找到线索。
几種常见的响應情况
5xx 與超时
服務器错誤和响應超时，對蜘蛛来说属于“没拿到”。偶發一次通常問题不大，蜘蛛會過一段時間再来；但如果连續多次失敗，抓取频率會被調低，恢复也需要時間。
429 與限速
返回 429 表示服務器在主動拒绝過多請求。這本身不是错誤配置，但如果限速阈值设得比蜘蛛的抓取节奏還紧，正常的抓取也會被挡掉一部分。
200 但内容是空的
狀態碼是 200，返回的却是一個空壳頁面、纯加载動画，或者“内容不存在”的提示。這種软 404 對收錄的影响，比直接的 404 更麻烦，因為它看上去是成功的。
403 與反爬拦截
部分站点的防護規則會拦截非浏览器請求。表現是蜘蛛拿到 403，而你在浏览器里訪問一切正常。這類問题一般要從日誌里才能發現。
狀態碼與頁面真實狀態不一致
临时维護却返回 404，永久刪除却返回 302，都會让蜘蛛對頁面的判断偏离實际。狀態碼尽量如實反映頁面目前是否可用，改動前先想清楚這是临时還是長期。
响應時間：多慢算慢
没有一個绝對阈值，但可以參考两点：一是和站内其他頁面比，如果某類頁面明顯慢很多，優先查這類頁面；二是看趋势，同一批頁面從 200 毫秒變成 2 秒，比一直稳定在 2 秒更值得關注。抓取资源有限，慢頁面會挤占其他頁面的抓取机會。
排查顺序建议
- 從日誌里筛出未被收錄的 URL，看它們最後一次被抓时的狀態碼和响應時間。
- 区分是整体問题還是個別頁面問题。整体偏慢，先看服務器和資料库；個別頁面異常，看模板或調用的接口。
- 检查是否有防護、CDN 或 WAF 規則在拦截。可以對比蜘蛛 UA 與普通 UA 拿到的返回结果是否一致。
- 確認修复後，观察日誌中该 URL 的响應是否恢复正常，再判断抓取频次有没有回升。
- 不要在响應問题没修好之前反复提交 sitemap 或請求抓取，那只會重复消耗抓取配額。
日誌里值得固定观察的几個字段
- 狀態碼分布：5xx、429、403 的占比變化。
- 响應時間：平均值之外，更要看慢請求的數量。
- 蜘蛛 UA 與 IP 段：確認請求确實来自搜尋蜘蛛，而不是被伪装的爬虫。
- 被抓 URL 的類型：是詳情頁、列表頁還是參數頁，問题常常集中在某一類。
把“服務器响應”当成收錄流程里的第一道過滤，很多莫名其妙的收錄問题會變得好解释：不是内容不行，而是蜘蛛根本没拿到内容。
小结
收錄是發現、抓取、索引這一串流程的结果，服務器响應卡在抓取這一段。定期從日誌回看狀態碼分布和响應耗时，比等到索引量掉了再回头查，成本要低得多。