在做蜘蛛池或入口頁时，有一種情况很容易被忽略：連結确實存在于頁面上，但要满足某個條件才輸出——比如先判断 Cookie、先校驗登入態、先经過一段 JS 交互。對普通訪客来说没問题，對搜尋蜘蛛来说，這些連結很可能等于不存在。
搜尋蜘蛛抓取时的預設狀態
搜尋蜘蛛發起請求时，基本可以理解為一個“干净”的匿名訪問：
- 不會带上你浏览器里的登入 Cookie 或會话标识；
- 不會先完成登入、驗證碼、滑块等交互；
- 不會点击按钮、滚動加载或提交表單；
- 通常按固定 IP 段和 User-Agent 訪問，行為比真實用戶更“机械”。
所以，如果你的入口頁逻辑是“没有 login_token 這個 Cookie 就返回一個空框架或跳轉到登入頁”，搜尋蜘蛛拿到的就是那個空框架或登入頁，里面的目标 URL 一個也發現不了。
几種常见的“登入/Cookie 门槛”寫法
1. 服務端判断 Cookie 再輸出連結
這是最直接的一種。後端檢測不到指定 Cookie，就只渲染頁面骨架，連結放在另一個需要鉴權的接口里。搜尋蜘蛛看到的 HTML 里没有目标 URL 的痕迹，URL 發現自然無從谈起。
2. 前端 JS 判断後再插入連結
頁面初始 HTML 是空的，JS 讀取 localStorage 或 Cookie，满足條件才用 DOM 操作把連結寫進去。部分搜尋引擎能执行 JS，但执行环境通常没有你的登入態，判断结果仍是不通過。即使 JS 能跑，被插入的連結是否被繼續抓取也要看渲染是否稳定、是否有超时。
3. 未登入直接 302 到登入頁
搜尋蜘蛛跟到登入頁後，看到的是表單和少量說明文字。原入口頁里的連結不會被解析，因為連結根本没出現在响應内容里。
核心問题不是“搜尋蜘蛛能不能执行 JS”，而是“它在没有登入態的情况下能看到什么”。頁面是否輸出連結，取决于你的服務端判断逻辑。
如果真的需要登入態才能看到連結
這取决于目的。如果這些 URL 本来就只给特定用戶看，那不被搜尋蜘蛛發現是正常设計，不需要折腾。如果目的是让搜尋蜘蛛發現並抓取這些 URL，就需要让連結出現在一個匿名可訪問的頁面上，常见做法有：
- 單獨做一個公開入口頁：不依赖任何 Cookie，服務端直接輸出目标連結的 HTML，结构简單、可缓存。
- 用 sitemap 补充：把目标 URL 寫進可公開訪問的 sitemap，作為 URL 發現的辅助通道，但 sitemap 本身也不能被權限拦截。
- 服務端渲染：把連結直接輸出到初始 HTML，而不是等 JS 执行後再插入，减少一层不确定性。
- 检查是否有拦截規則誤伤：有些站点是防火墙或 WAF 規則把未知 UA 当成異常流量，返回登入頁或挑战頁。這種情况要先在日誌里確認搜尋蜘蛛到底收到了什么狀態碼。
不要用“给搜尋蜘蛛單獨放行”来解决
一種常见的错誤做法是：檢測到搜尋蜘蛛的 User-Agent 就返回带連結的版本，檢測到普通訪客就返回登入墙。這属于向搜尋引擎和用戶展示不同内容，存在被判定為伪装的風險，轻則该頁面不被信任，重則影响整站抓取。除非差异只是样式或广告位，且不改變核心内容，否則不建议這么做。
怎么確認搜尋蜘蛛到底看到了什么
不用猜，可以直接驗證：
- 用不带 Cookie 的請求抓取入口頁，把 UA 換成常见的搜尋蜘蛛标识，看返回的 HTML 里有没有目标連結；
- 在搜尋引擎的站長工具里用 URL 检查功能查看“已抓取的頁面”和渲染结果；
- 翻服務器日誌，看搜尋蜘蛛訪問入口頁时的狀態碼、响應大小和频率。如果响應大小明顯小于你浏览时的頁面，多半就是被拦在门外了。
小结
搜尋蜘蛛不會带着你的登入態訪問。入口頁如果靠 Cookie 或登入判断来輸出連結，URL 發現基本不會發生。要么接受這個结果，要么把連結放到一個匿名可訪問、服務端直接輸出的公開入口頁上，並用日誌和抓取工具驗證搜尋蜘蛛真正拿到了什么。把這两件事分清楚，比反复猜测“它為什么不来抓”更有用。