很多站長排查抓取問题时，會把注意力放在 Sitemap、内鏈和响應時間上，却忽略了一個更前置的环节：請求根本没到站点程序，就被 WAF、限速或防火墙拦掉了。蜘蛛拿到的是 403 或 429，而你在應用日誌里什么都看不到。
被拦截时的典型表現
- 服務器訪問日誌里，来自已知爬虫的請求大量返回 403、429，或者干脆没有记錄，只在 WAF 日誌中出現；
- 某個時間点起抓取频次断崖式下降，但站点内容和内鏈结构並没有改動；
- 抓取統計與自家日誌對不上，Sitemap 長時間停留在“已提交未抓取”；
- 只有带參數的 URL 被拦，首頁和静態頁正常，這類情况通常是規則命中了查询字符串。
誤伤一般来自這几個地方
WAF 的通用規則集
多數 WAF 預設規則會拦截含 SQL 關键字、脚本片段、超長參數或特殊字符的請求。而站点的篩選參數、搜尋頁 URL、老版本 CMS 的路径里，恰好可能包含這些字符串，蜘蛛抓到這些 URL 时就會被一並拒掉。
频率限制與 CC 防護
蜘蛛抓取本身就是短時間内的大量請求。如果限速策略只按 IP 計數、不区分来源，专业爬虫很容易被当成攻击流量。反過来，有些站点為了“防采集”把阈值調得极低，正常訪客滑動列表也會触發拦截。
User-Agent 黑名單
UA 字符串可以被任意伪造，用黑名單去拦爬虫既拦不住恶意采集，又容易誤伤：部分防護产品的 UA 库更新不及时，會把新版爬虫标识当成可疑對象。而用 UA 做白名單同样不可靠，攻击者複製字符串就能绕過。
先確認是不是真蜘蛛，再谈放行
不要只看 UA。更稳妥的做法是核對請求来源 IP 是否属于搜尋引擎官方公布的 IP 段，或者對 IP 做反向 DNS 查询，確認主机名归属後再正向解析回去，两者能對上才可信。同时把 WAF 日誌、服務器訪問日誌和抓取統計資料放在一起對照，看被拦的路径是否集中在某几類 URL 上。
放行之前先驗證身份，放行之後保留其他防護——按 UA 白名單開口子，等于给所有伪造者開门。
放行时要注意的几件事
- 按官方 IP 段放行，而不是按 UA 字符串放行，並定期更新 IP 段列表，搜尋引擎偶尔會調整出口地址。
- 對已驗證的爬虫單獨設定限速阈值，與普通訪客、可疑流量分開計數，避免一锅端。
- 只對確認為誤伤的規則做例外，不要為了让蜘蛛通過而整体關閉 WAF。
- 保留 403、429 的日誌记錄，出問题时才能回溯是哪條規則先動的。
放行之後观察什么
調整後不要马上認為問题解决。接下来几周留意三個信号：訪問日誌中爬虫請求的狀態碼分布是否回到以 200 為主；抓取總量是否逐步回升而不是一次性暴涨；Sitemap 與重点目錄的抓取频次是否恢复。如果抓取量回来了，但深层頁面仍然很少被訪問，那問题可能已经不在防護层，而要回到内鏈结构和抓取路径上繼續排查。
站点防護和蜘蛛抓取並非天然對立。把驗證做扎實、把放行范围收窄到可確認的身份上，既能挡住恶意流量，也不會把自己的抓取通道一起堵掉。