做入口頁时，很多注意力放在連結、狀態碼和服務器上，Cookie 和 Session 這類服務端會话机制常被忽略。它們不直接“吸引”蜘蛛，却會改變蜘蛛每次請求看到的内容和 URL 形態。如果處理不当，入口頁可能出現同一内容被多個 URL 指向、蜘蛛拿不到核心連結、日誌里爬虫记錄被誤判等情况。

蜘蛛通常不保留 Cookie

绝大多數搜尋引擎蜘蛛在抓取时不會像浏览器那样维護長期 Cookie。一次請求結束後，服務器下發的 Set-Cookie 往往不會被後續請求带回。也就是说，如果入口頁把關键連結或正文放在“必须带某個 Cookie 才顯示”的逻辑之後，蜘蛛很可能只看到一個空壳頁面。

不同搜尋引擎對 Cookie 的支持程度不一致，有的蜘蛛在單次會话内可能短暂保留，但這不能作為设計前提。更稳妥的做法是：入口頁對不带 Cookie 的請求也返回完整的可抓取内容。

Session ID 寫進 URL 會制造重复

一些服務端环境在客戶端禁用 Cookie 时，會把 Session ID 拼到 URL 里，例如出現 ;jsessionid=... 或 ?PHPSESSID=... 這類參數。蜘蛛大多數时候不带 Cookie，正好會触發這種回退逻辑。结果就是同一個入口頁出現大量带不同 Session ID 的 URL。

對 URL 發現来说，這相当于人為增加了重复入口：抓取预算被分散，日誌里同一路径反复出現，後續分析也容易失真。建议检查 Web 容器和框架配置，關閉通過 URL 传递會话 ID 的選項，让會话只走 Cookie。

Set-Cookie 與缓存、回源的關系

入口頁如果每次响應都带上 Set-Cookie，尤其当 Cookie 值每次不同，CDN 和反向代理通常會更谨慎地缓存该响應，回源次數随之上升。静態资源如果也被下發 Cookie，問题更明顯。對入口頁而言，不必要的 Set-Cookie 能省則省；确實需要时，可以区分路径，避免影响整站缓存策略。

另外，蜘蛛每次請求都會收到新的 Set-Cookie，但它一般不會在後續請求中携带，所以不要指望用 Cookie 给蜘蛛“记狀態”。

不要把 Cookie 当成真人识別依據

有些站点用“是否有 Cookie”来判断訪客是不是真人，然後把無 Cookie 的請求当成異常。這個逻辑並不可靠：蜘蛛大多没有 Cookie，部分用戶也會禁用或清理 Cookie。如果依據這條規則去封禁，很容易誤伤抓取。更合理的识別方式是结合 UA、IP 反查和訪問行為，而不是單看 Cookie。

可以落地的检查清單

• 用 curl 不带任何 Cookie 請求入口頁，確認返回的 HTML 里包含核心連結和正文。
• 检查日誌中是否存在带 ;jsessionid=、PHPSESSID 等會话參數的 URL；有的话先關閉 URL 會话传递。
• 確認入口頁不依赖登入態或驗證 Cookie 才展示可抓取内容。
• 减少入口頁响應中的 Set-Cookie，静態资源尽量不设 Cookie。
• 對已经产生的带 Session ID 重复 URL，用 canonical 或 301 收敛到規范地址。
• 不要用 Cookie 存在與否做蜘蛛封禁判断，避免誤伤正常抓取。

Cookie 和 Session 不决定蜘蛛来不来，但會决定蜘蛛“看见什么”。把入口頁對無 Cookie 請求的响應理顺，是 URL 發現和日誌分析少踩坑的一步。

整体思路不复杂：入口頁要允许匿名、無狀態地訪問，會话机制只服務于真實用戶，不干扰抓取端。改完配置後，隔几天看一次訪問日誌，確認带會话參數的 URL 是否消失、蜘蛛請求是否還能拿到完整連結，再决定下一步調整。