頁面内容做得不错，站点地图也提交了，可索引狀態一直没動静。這时候很多人繼續回头改标题、加内鏈，却忽略了一個更前置的环节：搜尋方来抓取时，服務端给了什么回應。抓取不成功，後面的内容判断、质量评估都無從谈起。
抓取和收錄是两個环节
先把這個顺序理清：發現 URL、發起抓取、拿到頁面内容、判断是否入库，是四件事。抓取失敗或反复失敗，頁面就卡在“已發現”這一层，跟内容质量没關系。如果抓取日誌里同一個地址返回的是 5xx、超时或连接中断，那么去改正文是在解决错誤的問题。
先看抓取时服務端返回了什么
几類常见的坏信号
- 5xx 與網關错誤：源站崩溃、上游超时、CDN 回源失敗，都會以 500、502、503、504 的形式返回给爬虫。偶發一次影响有限，持續出現會让抓取频次被下調。
- 响應時間過長：首字节時間動辄數秒，爬虫的连接窗口等不起，表現為大量超时记錄。
- 连接重置與超时：防火墙、限速策略或 UA 拦截把爬虫請求直接掐断，日誌里看不到正常的 GET 记錄。
- 429 與訪問频次限制：短時間大量請求触發限流，爬虫被临时拒绝。
容易被忽略的拦截层
WAF、Bot 管理、CDN 的爬虫規則经常是單獨配置的。前台訪問正常，只說明浏览器 UA 能通過；爬虫 UA 是否被放行，需要單獨驗證。可以從服務端日誌里筛出爬虫 UA 的請求，看它們的狀態碼分布，而不是只看總体可用性。
核對顺序
- 確認現象：找一個具体 URL，用日誌或抓取測試工具看爬虫實际拿到的狀態碼和响應時間，不要用浏览器结果代替。
- 区分是全局還是局部：只有某個模板、某個机房或某個目錄異常，通常是局部配置問题；全站普遍超时，先查源站和 CDN。
- 排查拦截：检查 WAF、CDN、反向代理里的爬虫放行規則，確認没有按 UA 或频次誤杀。
- 修复並驗證：修完後用同样的方式复测，確認狀態碼回到 200、响應時間稳定在合理区間。
- 再回到内容层面：服務端恢复正常後，如果頁面依然不進索引，再去核對内容质量、重复度和 URL 規范。
抓取层面的問题解决之後，收錄通常不會立刻跟上，中間還隔着重新抓取和判定，观察要留出時間。
修复之後看什么
服務端恢复後，重点观察三件事：爬虫請求量是否回升、5xx 與超时占比是否下降、目标目錄的抓取覆盖是否扩大。這几項稳定了，再去站点地图和索引报表里看收錄變化更靠谱。如果只有部分頁面的收錄在恢复，說明問题可能同时存在服務端和内容两個原因，別急着下结论。
小结
收錄核對不必從内容開始。先用抓取日誌確認搜尋方拿到的是一次正常响應，再谈頁面质量，顺序對了能省下不少反复修改的功夫。