有些站点内容本身没問题，連結也能打開，但蜘蛛拿到的永遠是首頁、登入頁或一段驗證脚本。排查时先別急着怀疑内容质量，看看服務器和前端有没有在蜘蛛到達内容之前就把它拦下来了。
蜘蛛常见的几種被拦現场
- 整站或部分栏目需要登入才能查看，未登入請求被 302 跳到登入頁。
- Cookie 同意彈窗、地区選擇彈窗、订阅彈窗盖住正文，未点击时内容不渲染。
- CDN 或主机面板開啟的人机驗證、等待跳轉對未知 UA 一律返回 403 或 503。
- 防火墙按 UA、IP、請求频率做限制，蜘蛛的 IP 段被誤伤。
- 測試环境加了 basic auth，正式上线时忘了摘掉。
先確認蜘蛛到底拿到了什么
最直接的办法是看服務器日誌里蜘蛛 UA 對應請求的狀態碼分布。如果某個目錄下大量返回 302、401、403、429 而不是 200，基本可以判断拦截發生在内容之前。這類响應同样會消耗抓取配額，日誌里塞满非 200 记錄，真正的内容頁反而被訪問得更少。
用匿名請求模拟一次
- 用命令行工具带上蜘蛛 UA 請求一個具体内容頁，只看响應头和狀態碼。
- 清掉所有 Cookie 再請求一次，對比两次返回是否一致。
- 如果第一次是 200，清 Cookie 後變成 302，說明存在基于會话的跳轉。
- 把請求频率稍微提高，看是否出現 429，判断限速阈值是不是设得過低。
移動端與主机端一起看
有些跳轉是前端脚本做的：頁面先返回 200，再由 JS 判断登入狀態跳走。這種在原始 HTML 里能看到完整内容，但渲染後的頁面會變成登入頁。两種狀態都要检查，別只看其中一邊。主机侧的防火墙規則、CDN 的机器人策略，也只能在服務端日誌里才能看清。
该放行的放行，该保護的保護
不是所有拦截都要取消。付費内容、用戶中心、後台路径本来就该挡住蜘蛛，這部分要做的是让它明确知道不该抓，比如用 robots.txt 或頁面指令声明，而不是让它一次次撞 401。真正需要放行的是公開内容頁、栏目列表頁和站点地图。
用 UA 或 IP 白名單放行要谨慎：UA 可以伪造，反向解析也不是所有主机都稳定支持。更稳妥的做法是让公開内容不依赖登入態，從根上减少需要放行的场景。
拦截問题排查清單
- 公開内容在未登入、無 Cookie 狀態下能否直接返回 200。
- CDN 與防火墙的机器人規則里，是否把搜尋引擎蜘蛛列進了挑战或限速名單。
- 彈窗组件是否阻塞了正文的首次渲染。
- 是否還有多余的 basic auth、内網 IP 限制、地域封鎖仍在生效。
- 站点地图里的地址是否和返回 200 的地址一致，有没有指向登入跳轉。
這類問题的特点是站点看起来一切正常，只有從蜘蛛的视角走一遍才會暴露。建议把匿名訪問检查固定進上线流程：改版、調整防火墙規則、更換 CDN 之後都重新驗證一次。