入口頁搭好、連結也放上去了，搜尋蜘蛛却像没来過一样，很多人第一反應是“連結不行”或“蜘蛛池没效果”。實际排查中，有一個常见但容易被忽略的环节：請求在到達源站之前，就被 CDN 或 WAF 拦掉了。蜘蛛看到的可能不是你的頁面，而是一張驗證碼、一個 403，或者一段需要执行 JavaScript 才能通過的挑战頁。
先分清两種“抓不到”
一種是蜘蛛压根没發起請求，另一種是發起了請求但没拿到正常内容。前者要看入口頁有没有被正常發現、連結是否可提取；後者才和 CDN、WAF 有關。判断方法很简單：看源站的訪問日誌里有没有搜尋蜘蛛的 UA 和對應 IP 记錄。如果日誌里完全空白，問题多半在發現环节；如果日誌里有记錄但狀態碼是 403、406、429，或者响應体是挑战頁，就属于拦截問题。
常见的拦截形態
- 狀態碼拦截：直接返回 403、406、429，源站日誌可能只留下很少的记錄，甚至因為 CDN 缓存了拦截结果而完全没有回源日誌。
- 驗證碼或人机校驗頁：返回 200，但内容是“請完成驗證”，蜘蛛拿到的是一段無意义 HTML，也就無法提取里面的連結。
- JS 挑战：頁面先返回一段脚本，校驗通過後才跳轉到真實内容。搜尋引擎對這一步的處理能力有限，尤其是入口頁這種本身不靠渲染出内容的頁面。
- 地域或 IP 限制：蜘蛛的出口 IP 和你预期的訪客地区不一致，被規則直接拒绝。
- 频率限制：短時間抓取多個入口頁触發限流，表現為前面正常、後面開始 429。
按顺序排查
- 查源站訪問日誌，確認是否有蜘蛛請求、狀態碼分布和响應時間。
- 看 CDN 或 WAF 的拦截日誌，篩選蜘蛛 UA 和對應 IP 段，確認命中哪條規則。
- 用搜尋引擎官方提供的抓取測試或 URL 检查工具，看它們返回的响應碼和頁面内容。
- 用命令行带蜘蛛 UA 請求入口頁，對比正常浏览器 UA 的返回结果，重点看狀態碼和正文長度。
- 確認 robots.txt、sitemap 這些文件本身没有被誤拦，否則會连带影响發現和抓取。
放行时的取舍
不建议為了放行蜘蛛而全局關閉防護。更稳妥的做法是：把搜尋引擎官方公布的 IP 段加入白名單，只對這些来源跳過人机校驗和部分频率限制，同时保留對頁面的基础防護。UA 字段可以伪造，只按 UA 放行並不安全，能配合 IP 校驗會更好一些。
另外要区分頁面和接口。入口頁本身通常是静態 HTML，不需要复杂的風控；真正需要嚴格校驗的往往是登入、提交、搜尋接口。把两者混在同一條規則里，就容易出現“接口防住了，頁面也被防住了”的情况。
放行後怎么反向驗證
調整規則後不要只看一次结果。观察一段時間内入口頁的日誌：蜘蛛請求數量是否稳定出現、狀態碼是否以 200 為主、是否還會間歇出現 429。如果狀態碼正常但連結仍不被跟進，問题就轉移到連結结构、内容质量或目标頁本身，需要換一條排查线。
CDN/WAF 拦截只是众多卡点之一。它造成的現象是“蜘蛛像没来過”，而連結提取、目标頁质量等問题造成的現象更接近“来了但不跟進”，排查时先看日誌能少走很多弯路。