给站点做了安全加固之後，抓取量不升反降，是很多运营者會遇到的情况。日誌里看不到明顯的 5xx，頁面本身也没报错，但搜尋引擎蜘蛛的訪問记錄就是越来越少。排查到最後，問题常常出在 WAF、CDN 或者自建反爬策略上——它們把正常抓取和恶意爬虫一起挡在了门外。
這類故障的特点是安静。没有告警，没有错誤日誌，只有抓取频次在悄悄下滑，等發現新内容很久没被處理时，可能已经過去几周了。
蜘蛛被拦住的几種常见形態
WAF 規則誤伤
安全产品的預設規則集通常包含大量“疑似掃描”特征，比如請求參數里带特殊字符、短時間内重复請求同一路径、UA 中含爬虫字样。搜尋引擎蜘蛛的抓取行為恰好會命中其中一些特征：它會连續請求大量 URL，也會带一些看起来很“机器”的查询串。如果規則没有针對官方蜘蛛做例外，就容易被当成攻击流量拦截。
CDN 的人机校驗
部分 CDN 開啟了 JS 挑战或驗證碼挑战，正常浏览器能通過，但搜尋引擎蜘蛛不會执行這類挑战，结果就是收到 403，或者拿到一個需要跳轉的中間頁。表現上，蜘蛛看到的是一個空壳，真正的頁面内容拿不到。
频率限制與临时封禁
為了防刷，不少站点按 IP 或 UA 做了 QPS 限制。低频抓取时看不出問题，一旦站点更新量大、蜘蛛集中抓取，就會触發限流。轻則返回 429，重則把整個 IP 段临时封禁一段時間。更麻烦的是，蜘蛛在被限流後往往會自行降低抓取频次，之後再想提上来並不容易。
一份可执行的自查清單
- 查看服務器訪問日誌，確認最近一段時間是否還有来自主流蜘蛛 UA 的請求；如果一條都没有，先怀疑入口被拦。
- 用官方工具發起一次真實抓取，比如搜尋资源平台提供的抓取诊断，看返回的狀態碼和抓取到的 HTML 内容。
- 對比直连源站和经過 CDN 之後的响應，確認两者返回的内容一致。
- 检查 WAF 的拦截记錄，看是否有匹配到蜘蛛 UA 或蜘蛛 IP 段的規則命中。
- 检查 CDN 配置里是否啟用了人机校驗、Bot 管理或强制跳轉，確認其策略對已知搜尋引擎蜘蛛放行。
- 检查限流阈值，评估站点在更新高峰期可能产生的並發請求量，是否低于蜘蛛的正常抓取强度。
- 检查 robots.txt、防火墙白名單和 CDN 白名單是否在不同层級上互相覆盖。
怎么確認蜘蛛确實是“真”的
光看 UA 是不够的，UA 可以随意伪造，只按 UA 放行等于给所有伪装爬虫開了门。比較稳妥的做法是做反向 DNS 驗證：對請求 IP 做反向解析，確認域名属于搜尋引擎官方，再正向解析回同一個 IP。主流搜尋引擎都公布了各自的 IP 段和驗證方式，可以做成定时任務自動核對。
白名單不是一次配置就完事。搜尋引擎的 IP 段會新增和調整，寫死的 IP 列表過一段時間就可能失效，或者把已经回收的地址繼續放行。
放行时容易忽略的几個细节
- 放行位置要正确。如果站点前面有 CDN，源站看到的往往是 CDN 回源 IP，在源站放行蜘蛛 IP 段没有意义，需要把規則加在 CDN 或 WAF 那一层。
- 区分抓取與回源。CDN 缓存命中率高的时候，蜘蛛的請求根本不會到源站，日誌里看不到记錄不代表没抓，要结合 CDN 日誌一起看。
- 保留必要的拦截。放行不等于全開，针對異常請求路径、明顯恶意的參數仍然要拦，只是別把蜘蛛的正常請求一起放進去。
- 改完要复测。規則調整後重新用官方工具抓一次，並观察几天日誌里的抓取频次是否回升，不要只改不驗。
安全防護和抓取通路並不是二選一。多數情况下，問题只是白名單没配、規則没做例外，或者改配置时忘了同步。把上面這几項做成固定的检查動作，每次上 WAF、上 CDN、調整限流之後都過一遍，就能省掉不少“蜘蛛怎么突然不见了”的排查時間。