很多站点反映蜘蛛不来抓，排查到最後會發現：連結没問题，Sitemap 也提交了，問题出在請求進来之後被拦住。蜘蛛拿到的不是頁面，而是一個登入頁、一次跳轉、一层遮罩，或者一張驗證碼。這種問题在日誌里常表現為狀態碼正常，但返回内容不對，只看狀態碼很容易漏過去。
登入墙與權限判断：蜘蛛看到的是登入頁
内容放在登入之後，蜘蛛自然拿不到。更隐蔽的情况是：站点對未登入用戶做统一跳轉，先 302 到登入頁，再让登入頁返回 200。蜘蛛顺着連結爬進来，讀到的是一堆重复的登入模板，真正的正文 URL 從来没有被真正抓取過。
如果确實有需要公開的内容，通常的做法是让它在未登入狀態下也能直接訪問，而不是靠跳轉兜底。检查时重点看：
- 正文 URL 未登入訪問时返回的是正文還是登入頁模板；
- 是否存在“先跳轉再返回 200”的鏈路，让狀態碼看起来是健康的；
- 會員区、後台、预览頁是否與公開内容混在同一套模板和連結里。
Cookie 跳轉：第一次訪問就被送走
地区選擇、語言切換、A/B 分流，常常靠 Cookie 或請求头做判断。問题在于蜘蛛第一次訪問时既没有 Cookie，UA 也和浏览器不同，站点就可能把它重定向到另一個版本，甚至重定向回首頁。
几種典型表現：
- 没有地区 Cookie 时預設跳到某個分站，蜘蛛始终停在入口；
- 分流脚本把一部分請求分到 B 版本，導致同一 URL 反复返回不同内容；
- 語言判断寫到跳轉逻辑里，爬虫拿到的永遠是預設語言的那一版。
比較稳妥的處理是：让預設版本直接返回内容，把地区、語言切換做成頁面上的顯式連結，而不是隐式跳轉。
同意彈窗與遮罩层：渲染层面的堵点
Cookie 同意條、订阅彈窗、App 下载引導，多數不會影响原始 HTML，但會影响渲染结果。如果彈窗以遮罩形式覆盖正文，而正文又是前端异步加载，蜘蛛渲染时可能先拿到遮罩层，正文還没挂上来就被判定為渲染完成。
另外，部分彈窗依赖第三方脚本，脚本加载慢或超时會拖長渲染時間。處理思路是让正文在初始 HTML 里就存在，彈窗逻辑延後执行；移動端的全屏引導尤其要注意，它经常是渲染後被“贴”上去的。
防火墙、UA 判断與驗證碼
WAF、CDN 防護和站内自研的防爬規則，是另一類容易被忽略的堵点。常见触發條件包括：請求频率触發限速、UA 命中黑名單規則、缺少某些浏览器請求头、来自云机房 IP 段、短時間内訪問大量 URL。
表現通常是返回 403、429，或者一張驗證碼頁，也可能是空响應。需要注意的是，這類拦截有时只在抓取高峰期生效，低峰期測試一切正常，導致問题很难复現。
怎么判断是不是被挡住了
- 看服務器日誌里蜘蛛 UA 對應的狀態碼分布，重点找 3xx、403、429 以及返回体积異常小的 200；
- 對同一個 URL 分別用蜘蛛 UA 和普通浏览器訪問，比對最终落地 URL 和正文内容；
- 清空 Cookie、不带登入態再訪問一次，看是否發生跳轉；
- 检查渲染後的頁面，確認正文是否被遮罩或彈窗挡住；
- 核對 CDN 與 WAF 規則里是否存在针對 UA、频率、IP 的拦截項。
放行时该守住的原則
- 安全策略按 IP 白名單和真實行為判断，不要僅凭 UA 字符串做业務逻辑；
- 需要屏蔽的頁面用 robots.txt 或 noindex 明确表達，而不是靠跳轉和拦截；
- 公開内容保持未登入可直接訪問，登入墙不要覆盖整站；
- 改版或調整防護規則後，留一段時間观察日誌中的狀態碼變化。
蜘蛛抓不到内容，很多时候不是路径問题，而是入口被礼貌地挡在了外面。先把請求顺利放進来，再去谈抓取深度和抓取节奏，顺序會更顺一些。