抓取日誌里出現 5xx、429 或者成片的连接超时，很多人的第一反應是“蜘蛛是不是不喜欢這個站了”，接着去改标题、改内容、重新提交 sitemap。方向可能没错，但顺序常常反了——服務端连稳定應答都做不到时，後面那些動作很难被正确评估。下面按“先看通道，再看内容”的思路，给出一份核對顺序。
抓取失敗不等于收錄出問题，但會拖慢收錄
抓取是收錄的前置條件之一。搜尋引擎需要先拿到一份完整的 HTML，才能判断這個 URL 是否值得進入索引。如果同一個地址在一段時間里反复返回错誤狀態，抓取端會降低訪問频率，甚至暂时把该目錄移出高频抓取范围。這时候你看到的收錄變慢、新頁面迟迟不出現，往往不是内容质量問题，而是抓取通道被自己堵住了。
把服務器狀態碼分布当作第一優先級来核對，比反复調整頁面文案更有效率。
先看日誌里的狀態碼分布
從最近的抓取日誌里按响應碼做一次分组統計，重点看這几類：
- 200：正常。如果占比高但收錄没動，問题就不在抓取通道，需要回到内容與 URL 規范上找原因。
- 301 / 302：跳轉本身没問题，但要確認跳轉鏈是否超過一跳、是否跳到了错誤目标。
- 404 / 410：属于正常反馈，只要不是大面积存在，一般不影响整体抓取。
- 5xx：服務端自身的错誤，這是最需要立刻處理的一類。
- 429 / 503：限速或维護狀態，通常伴随 Retry-After 提示。
- 403 / 401：權限或拦截，常见于 CDN、WAF、地域策略誤伤。
- 超时、连接重置：往往在日誌里体現為没有狀態碼，容易被直接忽略。
三類高频問题的處理顺序
5xx：先看時間是否集中
如果 5xx 集中出現在某個時間段，多半和当时的發布、备份、資料库压力有關；如果全天分散出現，更可能是應用层的偶發错誤或某個接口拖垮了整頁渲染。處理顺序是：先確認是全局還是個別路径，再看是否與某個功能模块相關，最後才考虑是不是抓取频率過高導致的资源竞争。
429 與 503：区分限速和维護
429 一般說明訪問频率超過了服務端设定的阈值。此时不要一味提高限速上限，先確認抓取是否集中在低價值 URL 上，比如參數组合生成的篩選頁、站内搜尋结果頁。把這類地址先收口，再放核心頁進来，往往比放宽限速更有效。503 要確認是計划维護還是被動降級，维護頁如果長期挂着 503，抓取节奏會被明顯压低。
超时與响應慢：比错誤碼更容易被忽略
日誌里没有狀態碼的记錄，通常就是超时或连接中断。排查时看两件事：一是首字节時間是否稳定，二是是否存在個別接口拖慢整頁。图片、統計脚本、第三方组件都可能成為瓶颈，但它們未必影响正文抓取，需要结合渲染方式判断。
403 與 401：检查是否有誤伤
這類狀態常出現在上 CDN 或安全策略之後。核對时注意：是否對特定 User-Agent 做了拦截，是否對境外或特定網段做了限制，是否触發了频率型防護規則。誤伤的特征是同一目錄浏览器可以訪問、抓取端却持續被拒。
一份可执行的核對顺序
- 按小时統計狀態碼占比，标出異常集中的時間段。
- 確認異常是否集中在個別目錄或 URL 模板上。
- 對照服務端监控，检查是否為發布、备份或资源瓶颈導致。
- 检查 CDN 與 WAF 規則，排除對抓取端的誤拦截。
- 收口低價值 URL，减少無效請求占用抓取額度。
- 观察一到两周，確認失敗率回落到可接受区間。
服務端恢复之後，再看内容與 URL
抓取成功率回升，只說明通道顺畅了，不代表收錄一定會跟着涨。此时再回到常規核對項：頁面是否有獨立價值、是否存在多個版本指向同一内容、canonical 與實际展示是否一致、内鏈是否给了入口。這些因素决定的是“抓到的頁面值不值得進索引”，和服務端狀態是两個层面的事。
把两者分開看，排查會更清楚：服務端問题解决的是能不能顺利拿到頁面，内容與規范問题解决的是拿到之後留不留。顺序對了，很多看似無解的收錄停滞，其實只是第一步没做完。