為什么蜘蛛會被拦在入口頁之外
蜘蛛池入口頁刚上线时抓取正常，某天換了 CDN 厂商、加了 WAF，或者服務器迁到云防護後面，抓取量就掉了。很多人第一反應是内容被降權，其實更常见的情况是請求根本没到達源站——防護层在邊缘就把蜘蛛拒了。對搜尋引擎蜘蛛来说，它看到的只是一次 403、一次 503，或者一個需要执行 JavaScript 才能通過的驗證頁面，除了重试之外没有別的反馈。
- UA 黑名單誤伤：不少防護預設規則會把带 spider 字样的 UA 当成掃描器。
- IP 信誉库把机房 IP 段整体标记為高風險。
- 單 IP 請求频率触發限流。
- 對所有訪客開啟了 JS 挑战或驗證碼。
- 只放行部分地区的訪問，蜘蛛出口不在其中。
- 防護层把错誤的 403 响應缓存了下来。
怎么判断是誤拦，而不是内容問题
先看响應碼和日誌
把 CDN 或 WAF 的訪問日誌和源站的訪問日誌放在一起比對，是最直接的办法。如果防護日誌里能看到蜘蛛 UA 或官方 IP 段的請求，而源站日誌里對應的记錄是空的，說明請求在邊缘就被處理掉了，压根没落到源站。再對照响應碼：连續大量 403、406、429、503，或者返回 200 但内容是一段挑战脚本，都指向拦截。
用官方渠道交叉驗證
各搜尋引擎的站長平台一般都有抓取诊断或抓取測試工具，可以模拟蜘蛛從外部發起請求。如果工具里顯示抓取失敗、超时或被拒绝，而你在本地浏览器訪問同一個 URL 一切正常，基本可以確認防護层按来源做了区分。同时核對蜘蛛的真實 IP 段——查一下该搜尋引擎官方公布的 IP 列表，拿它跟防護日誌里的来源 IP 對一遍，還能顺带区分真蜘蛛和伪造 UA 的采集器。
放行时按什么维度更靠谱
優先按 IP 段，而不是 UA
UA 是最容易伪造的字段，只按 UA 放行，等于同时给一批伪装的采集程序開了门。相對稳妥的做法是把官方公布的蜘蛛 IP 段加進白名單，並且定期更新——搜尋引擎的 IP 段會變。如果防護支持，再叠加一次反向 DNS 校驗，確認来源 IP 确實归属于對應搜尋引擎。放行范围尽量收窄到入口頁所在的域或目錄，不要顺手把整站都放開。
速率限制和缓存要單獨設定
放行不等于放任。给白名單單獨设一档速率上限，既能保證抓取通道顺畅，也不至于让防護彻底失效。另外注意缓存策略：如果防護层把 403 或挑战頁缓存了，即使後面放行，返回的仍是舊响應。放行之後清理一次相關缓存，並確認蜘蛛請求不會被强制跳轉到某個驗證頁面。
放行之前先记錄目前的抓取量和响應碼分布，否則放行後拿不到可以對比的基线資料。
放行之後要复核什么
- 蜘蛛請求是否落到源站：看源站日誌里来自官方 IP 段的請求量有没有回升，而不只是看防護层的請求數。
- 响應碼分布：403、503 是否下降，200 的比例是否上升；如果 200 上升但抓取量没變，可能是速率限制還在起作用。
- 抓取到的内容是否正常：確認蜘蛛拿到的是完整 HTML，而不是骨架屏、跳轉頁或空内容，啟用了前端渲染的入口頁尤其要检查。
- 有没有伪造流量混入：放行後如果日誌里出現大量非官方 IP 段、UA 却寫着蜘蛛名字的請求，說明白名單開得太宽，需要收回。
几個容易踩的坑
- 只按 UA 放行，结果把伪装采集器一起放進来。
- 規則只寫在外层 CDN，内层 WAF 或源站的規則没同步，請求到中間又被拦一次。
- 換了 CDN 或 WAF 厂商之後没有重新核對白名單，舊規則不在新平台上。
- 為了蜘蛛關掉驗證碼或 JS 挑战，顺手把整站的防護都降級了。
- 只看“抓取量”不看“落到源站的量”，把防護层的命中当成有效抓取。
防護和抓取不是非此即彼。把白名單、速率、缓存這三件事分開配置，再留一份可對比的基线資料，大多數誤拦都能在几天内定位清楚。至于抓取量恢复之後能不能轉化為收錄，那是另一個环节的事，蜘蛛池本身能解决的只是“被看见”這一段。