聊抓取路径时，大多數人從 robots.txt 和内鏈结构看起。但蜘蛛要走到那一步，前提是它的請求能先落到你的服務器上。如果 CDN、WAF 或主机层面的防護先把請求挡掉，後面的 Sitemap、内鏈、抓取预算都無從谈起。這類問题排查起来比較隐蔽：站点對普通訪客完全正常，只有蜘蛛的請求被拒。
拦截通常發生在哪一层
- CDN 的 Bot 管理或安全規則，預設對疑似自動化流量做挑战、限速或直接返回 403。
- WAF 把高频訪問、特定 User-Agent、缺少 Cookie 的請求判定為攻击。
- 主机面板的防 CC 功能，或机房层的 IP 黑名單，把云服務器 IP 段整段拦下。
- 地区限制、UA 白名單設定過窄，只放行浏览器常用的几個标识。
這些規則的共同点是：它們按請求特征做判断，而不是按内容。對真實用戶没影响，對蜘蛛却可能是致命的。
被拦之後，日誌里會留下什么
如果你的站有獨立日誌，先看服務器收到的請求里，還認不認得出蜘蛛的 UA。常见有三種情况：
- 日誌里完全没有蜘蛛請求。說明請求在更前面的节点就被處理掉了，源站日誌看不到，需要去 CDN 或 WAF 的控制台看拦截记錄。
- 有請求，但狀態碼集中在 403、429、503，或者返回一個驗證頁。這属于防護层放行到了源站，但源站或 CDN 仍给了拒绝响應。
- 有請求且狀態碼正常，但内容被替換過，比如返回了 JS 挑战頁。這时蜘蛛拿到的是一個空壳，等于路径走到了却讀不到東西。
怎么確認是拦截而不是内容問题
最省事的办法是做一次對照測試：用普通浏览器訪問目标 URL，再用带蜘蛛 UA 的請求工具訪問同一地址，比對狀態碼和返回内容。如果两者差异明顯，問题基本就在防護层。
另外可以對照几件事：搜尋引擎站長後台的抓取測試工具报什么错、抓取統計里目标頁有没有被成功抓過、同一時間普通用戶的訪問是否正常。如果只有带蜘蛛标识的請求異常，方向就比較明确了。
放行的正确姿势
不建议只按 User-Agent 放行。UA 可以随意伪造，按 UA 開口子等于给出一個公開的绕過通道。更稳妥的做法是叠加驗證：
- 先確認請求来源的 IP 是否属于搜尋引擎官方公布的地址段。
- 對關键 UA 做反向 DNS 解析，驗證域名归属，而不是只看字符串。
- 在 CDN 或 WAF 里為已驗證来源單獨建一條放行策略，優先級高于通用 Bot 規則。
- 如果必须限速，给已驗證来源一個明顯更高的阈值，避免它和普通爬虫共享配額。
顺序上，先放行官方来源，再收紧通用規則。反過来做，很容易在收紧时顺手把蜘蛛也拦了。
放行之後要复查的三件事
- 抓取是否恢复：连續观察几天的日誌，看蜘蛛請求數和覆盖的 URL 是否在回升，而不是只看某一天。
- 响應是否稳定：放行後如果源站扛不住，蜘蛛仍然會因為超时减少訪問，等于換了一種方式中断路径。
- 是否留下假信号：確認没有把拦截頁返回成 200，也没有在驗證頁里塞入誤導性的規范連結。
抓取路径的第一關不在站点内部，而在網絡邊界。入口被挡住时，任何關于内鏈和 Sitemap 的優化都不會产生效果，所以排查顺序上，先確認蜘蛛進得来，再谈它走得顺不顺。