不少人在日誌里看到入口頁有訪問记錄，就預設一切正常。但更常见的情况是：入口頁面向普通訪客能打開，搜尋蜘蛛的請求却在 CDN 或 WAF 那一层就被挡掉了，返回 403、429，或者一個体积很小的 JS 驗證頁面。這種狀態下，入口頁里挂的目标 URL 根本不會被解析到，也就谈不上被發現。

先判断拦截發生在哪一层

確認問题的顺序，比直接改入口頁内容重要得多。

• 日誌里入口頁的蜘蛛請求量突然骤降，或者只剩几個固定 IP 反复出現；
• 响應碼集中在 403、429、503，或者狀態碼是 200 但返回体积異常小；
• 响應头里带 server、cf-ray 一類字段，能快速看出是 CDN 节点還是源站返回的；
• 用命令行工具带上常见蜘蛛 UA 請求同一路径，返回内容和浏览器打開的不一致。

要注意，單纯改 UA 的模拟請求不能当作结论。搜尋蜘蛛的真實 IP 和 UA 通常是配套驗證的，不少 WAF 會做双向校驗，只看 UA 容易得出错誤判断。

常见的誤拦原因

• UA 黑名單里寫了 bot、spider 之類的關鍵詞，把正常蜘蛛一起拦了；
• 频率限制按 IP 計數，蜘蛛短時間内连續請求入口頁触發了阈值；
• 区域規則，蜘蛛的抓取节点落在被屏蔽的地区；
• 人机驗證或 JS 挑战開啟，而蜘蛛不會执行驗證逻辑；
• robots.txt 或整站路径被規則拒绝，蜘蛛無法確認抓取许可。

處理思路

1. 先分清是拦截還是入口頁自身故障，看响應头归属就能定位，不必反复改頁面。
2. 在 CDN 或 WAF 里把官方公布的蜘蛛 IP 段加入白名單，比只按 UA 放行更稳。
3. 把 robots.txt、sitemap 等文件路径單獨放行，避免一條規則让蜘蛛進不来。
4. 關閉针對蜘蛛抓取路径的 JS 挑战和人机驗證，只對表單、登入等敏感路径保留。
5. 适当放慢入口頁的連結更新节奏，降低單位時間内的請求量，避免持續触發限流。

几個容易踩的坑

白名單加了 UA 就够了

不完全是。伪造 UA 的成本很低，所以很多防護預設不信任 UA，真正起作用的是 IP 段白名單加上反向解析校驗。

入口頁被拦，換個入口頁就行

如果拦截規則是按整站或按 IP 生效的，新建入口頁同样會被挡。先修拦截，再谈其他調整。

拦截解决後马上能看到结果

不一定。抓取频率的恢复、連結的重新排队都需要時間，而且被發現和進入抓取队列是两件事，被收錄又是另一件事，建议分開观察。

用日誌位置、响應碼归属、来源 IP 核對這三步確認拦截点，通常比反复調整入口頁内容更有用。

總结一下：入口頁能被訪客打開只是最低要求，關键要看搜尋蜘蛛拿到的响應是不是正常内容。一旦發現拦截，先定位是哪一层在拒绝、按什么規則拒绝，再考虑放行方式和抓取节奏，而不是急着換連結寫法或換入口頁。