核對收錄时，最容易忽略的一步是先確認搜尋引擎到底有没有把這個頁面抓下来。URL 提交了、内鏈也铺了、正文也不算薄，可索引里就是没有它，這时不少人的第一反應是内容和标题不够好，于是開始改版式、調结构。但如果抓取請求本身就没成功，後面所有關于内容质量的判断都建立在错誤的前提上。
先把「没抓到」和「抓到没收」分開
這两件事的處理方向完全不同。前者是服務器或網絡层的問题，後者才是内容與结构层面的問题。判断方法並不复杂：看抓取統計里這個地址最近一次成功返回的時間，以及返回的狀態碼。如果最近一次记錄還是几個月前，或者根本没有记錄，那大概率是抓取环节卡住了；如果最近几天都有成功抓取，但索引里依然没有，問题才轮到内容侧。
還有一個中間狀態值得注意：抓取成功但拿到的是空壳。比如返回 200，正文区域却是空的，或者只有模板框架。這種情况在索引侧看来，和抓取失敗的效果差不多，都需要回到抓取结果去看。
常见的几種抓取失敗表現
5xx 與超时
服務器错誤和响應超时是最常见的两類。資料库连接不稳、缓存被击穿、接口調用超时，都可能让頁面在蜘蛛訪問的那一瞬間返回 5xx。這類错誤的影响會被放大：连續出現之後，抓取工具通常會主動降低對這個站点的抓取频率，恢复起来需要一段時間。
超时則更隐蔽。带宽正常，只是頁面响應慢，比如首屏依赖一個慢接口，或者大量同步請求阻塞了渲染。單個請求可能只是慢，但批量抓取时就會變成大面积超时。
403 與 429
防火墙規則、UA 拦截、频率限制，都會让請求在到達應用之前就被挡回去，表現是返回 403 或者 429。有些站点為了防爬做了比較激進的策略，结果把正常的搜尋抓取也一起拦了。判断方法很简單：用不带 Cookie 的普通請求訪問同一地址，看看是否也會被拦。
协议與跳轉层面的問题
HTTPS 證书過期、證书鏈不完整、HTTP 到 HTTPS 的跳轉鏈條過長、跳轉成环，都會让抓取在半路中断。尤其是改版或者接入 CDN 之後，跳轉規則容易层层叠加，本来一跳能到的地方變成三四跳。
按模板分组排查，比逐個看有效
- 按模板分组取样，每個模板挑几條有代表性的 URL，不要從首頁開始一條條点。
- 用不带 Cookie、不带登入態的請求訪問，看到的狀態碼和响應头才是抓取工具看到的那一份。
- 對比同一模板下能抓到的頁面和抓不到的頁面，差异通常集中在某個參數、某台後端机器或者某段時間。
- 把失敗记錄按時間段排一遍，判断是持續性的，還是集中出現在高峰时段。
- 如果站点有多個出口 IP 或後端节点，逐個驗證，確認不是單台机器的問题。
修好之後，別马上按收錄结果判断
抓取恢复並重新訪問之後，到索引更新之間還有一段間隔，這段時間里收錄數不會立刻變化。比較稳妥的做法是把抓取失敗率和收錄率分開记錄，先看失敗率是否降下来，再看索引里的變化。两者混在一起看，很容易把正常延迟当成没修好，或者把局部修复当成整体好轉。
抓取是收錄的前置條件，但它不是收錄本身。先保證請求能拿到一份完整的頁面，再讨论這份頁面值不值得進索引。
還有一点常被漏掉：如果頁面本身可以正常抓取，只是内容不够獨立，那不该在抓取层面花太多時間。反過来，如果抓取成功率長期偏低，再怎么優化正文也不會明顯改變结果。先把狀態碼、响應時間和拦截規則這三項對齐，再去谈内容，顺序會顺很多。