入口頁能被搜尋蜘蛛正常抓取，連結也規規矩矩寫在 a 标簽里，可目标 URL 就是一直没動静。這種情况下很多人會回头改入口頁，其實問题往往不在入口頁，而在目标 URL 的“门口”——CDN 或 WAF 把它挡住了。搜尋蜘蛛本质上也是一個 HTTP 客戶端，遇到拦截同样拿不到内容。
先分清：發現和抓取是两件事
入口頁上的連結只完成“發現”這一步。能不能真正讀到内容，取决于目标 URL 返回的狀態碼和响應体。CDN、WAF 的拦截通常表現為 403、405、429、503，或者更隐蔽的一種：返回 200，但内容是驗證頁、挑战頁或一段空壳。前几種會让蜘蛛把這次抓取记為失敗；後一種更麻烦，因為狀態碼看起来正常，實际正文並不存在。
狀態碼 200 不等于抓到了内容，先看响應体是不是真正的頁面。
常见的拦截形態
- 按 UA 或 IP 拦截：只放行浏览器 UA，搜尋蜘蛛 UA 直接吃 403。
- JS 挑战：返回 200，需要执行脚本後才跳轉，蜘蛛一般不會执行。
- 频率限制：同一 IP 段短時間請求偏多，触發 429 或 503。
- 地域限制：某些节点能訪問，目标机房所在区域被規則挡住。
- 缓存了拦截结果：CDN 把 403 或挑战頁缓存下来，後續正常請求也拿到同一份。
怎么確認是被拦了
- 看源站訪問日誌，按搜尋蜘蛛的 UA 與其官方 IP 段筛一遍，確認請求有没有到達源站。
- 用命令行工具带搜尋蜘蛛 UA 請求目标 URL，再和普通浏览器 UA 的结果對比，看狀態碼與响應体差异。
- 查 CDN/WAF 後台的拦截日誌和命中規則，確認是否存在 UA 黑名單、Bot 規則或频率阈值。
- 把入口頁日誌和目标 URL 日誌放在一起看：入口頁能進、目标 URL 長期 403 或 503，基本可以定位在目标端的訪問控制。
處理思路
- 把已確認的搜尋引擎 IP 段加入白名單，或按官方提供的反向 DNS 驗證方式放行，比只看 UA 更可靠，因為 UA 可以伪造。
- 為爬虫單獨走一條不触發 JS 挑战的規則，避免驗證頁把正文顶掉。
- 检查频率限制是否過紧，蜘蛛的並發节奏可能刚好踩在阈值上。
- 清理 CDN 上被缓存的错誤响應，並設定不要缓存 4xx、5xx。
- 顺带確認 robots.txt 没有額外屏蔽，两處叠加會互相掩盖問题。
被拦之後有哪些连带影响
目标 URL 反复失敗，會让蜘蛛降低對该路径的抓取频率，甚至在一段時間内不再尝试。如果入口頁本身也被拦，頁面里的其他連結會一起失去被發現的机會。這通常不是“惩罚”，而是资源分配的结果。反過来，如果只有目标 URL 被拦、入口頁正常，連結的發現记錄一般還會保留，但這並不代表之後一定會被重新抓取，更不构成收錄保證。
几個容易忽略的细节
- 有些 WAF 對 HEAD 請求放行、對 GET 拦截，只测一種方法容易誤判。
- 首頁規則正常不代表内頁正常，規則常按路径或參數單獨配置。
- 蜘蛛 UA 被滥用後，服務端可能對整段 UA 做拦截，需要配合官方 IP 段一起判断。
- 抓取失敗在日誌里也可能顯示為连接重置或超时，看起来不像“拦截”。
排查顺序建议從日誌開始，先分清是“没来抓”還是“来了没拿到”。日誌里连請求都没有，問题在發現和調度层面；請求到了但返回異常，問题在目标端的訪問控制。把這两层分開看，绝大多數“入口頁没問题、目标 URL 却没動静”的情况都能找到落点。