收錄迟迟不動，很多人會先怀疑内容质量、内鏈或者 sitemap 提交。但把服務器日誌翻出来看，经常是另一回事：搜尋引擎确實来過，只是每次都被挡回去，或者只抓了一两頁就撤了。抓取是收錄的前置條件，抓取通道如果長期不顺畅，後面所有關于頁面质量的讨论都没有落脚点。
先把“抓不到”分成三類
同样是抓取失敗，原因和處理方式完全不同，先分類再動手。
- 明确拒绝型：403、401、DNS 解析失敗、连接被重置。通常来自訪問控制、WAF 規則或 IP 封禁，属于硬拦截，蜘蛛基本不會反复重试。
- 临时失敗型：500、502、503、504、429。服務器過载、後端超时、限速触發都會落到這里，短期可恢复，但持續出現會明顯影响抓取频率。
- 正常但慢：返回 200，但首字节時間很長。不會直接算失敗，只是每次抓取消耗的预算變多，抓取總量随之下降。
5xx：偶發几次和持續几天是两碼事
偶發的 5xx 很常见，搜尋引擎也能理解。真正需要注意的是成片、持續、集中在同一批 URL 上的 5xx。這種情况通常意味着後端某類頁面在特定條件下出错，比如篩選項過多的列表頁、需要實时查询的詳情頁、依赖外部接口的頁面。
處理思路是先定位范围：從日誌里按狀態碼篩選，看 5xx 集中在哪些目錄、哪些參數、哪個時間段。如果集中在參數组合复杂的 URL 上，說明爬虫正在探索你的長尾入口，而這些入口本身可能就不该被抓。把它們的产生方式收一收，往往比一味調服務器更有效。
429 與抓取速率：是你在限，還是對方在退
429 的含义是請求過多。它可能来自你自己的限速策略，也可能来自 CDN 或云防護的預設規則。需要確認两点：這個限速是否對搜尋引擎 UA 生效，以及限速阈值是不是定得太低。
搜尋引擎抓取本身是有节制的，正常站点的抓取速率一般不會高到触發限速。如果日誌里频繁出現 429，常见原因是：站点响應太慢導致並發堆积、站内存在大量自動跳轉或重复請求、某些 URL 被抓取时触發连鎖請求。先解决响應問题，再考虑調整限速。
CDN 和 WAF 是最容易被忽略的一层
很多“抓取異常”其實出在中間层。常见的几種情况：
- UA 黑名單誤伤：規則里把包含 bot 字样的請求全部拦掉，顺带拦掉了正常蜘蛛。
- JS 质询：人机驗證頁面對普通浏览器無感，對不执行 JS 的爬虫就是一道墙。
- 地域限制：站点限定某些地区訪問，而搜尋引擎的抓取节点可能不在范围内。
- 回源配置错誤：CDN 缓存了错誤頁，或者回源时後端返回 5xx，邊缘节点把這個狀態透传出去。
排查方法不复杂：用搜尋引擎官方给出的驗證方式，或者通過反向解析確認来源 IP，逐個节点測試能不能拿到正常的 200 與完整 HTML。
响應時間與抓取预算
抓取预算不是固定配額，而是搜尋引擎在给定時間内愿意並且能够從你站点取回的頁面數量。响應時間越長，單位時間取回的頁面越少；頁面体积越大、重定向鏈越長、需要加载的外部资源越多，單頁成本越高。對于頁面數量多、更新频繁的站点，這類损耗會直接体現在新頁面被發現的速度上。
一條可执行的排查顺序
- 從服務器日誌按搜尋引擎 UA 篩選，統計狀態碼分布與趋势。
- 按目錄、參數類型拆分，找出失敗集中在哪些 URL 形態上。
- 区分是源站問题還是 CDN/WAF 問题，逐层绕過驗證。
- 確認 robots.txt 與各類訪問控制没有把正常抓取挡掉。
- 针對成片的失敗頁，判断是修复還是收口，比如加 noindex、改為 404、去掉入口。
- 修复後用日誌观察两周，看抓取量與狀態碼是否回归正常。
修复之後的驗證別只盯着收錄數
服務器侧的問题解决後，最先變化的是抓取日誌，而不是索引量。建议先看三個指标：抓取請求總數是否回升、200 占比是否提高、被抓取的 URL 是否開始覆盖之前失敗的目錄。索引量的變化通常滞後，用短期波動判断修复是否有效容易誤判。
抓取通畅不等于一定被收錄，但抓取長期不顺畅，收錄基本無從谈起。先把通道打通，再谈頁面质量。