缓存头不决定收錄，但會决定蜘蛛看到哪一版
在蜘蛛池场景里，入口頁的主要任務是让搜尋蜘蛛稳定地訪問，並從頁面里發現目标 URL。缓存头不會直接让頁面被收錄，却會改變搜尋蜘蛛每次回訪时拿到的是最新版本，還是 CDN 或浏览器缓存里的舊版本。入口頁如果長期强缓存，新增連結可能迟迟不進入蜘蛛的解析队列。
Cache-Control 的常见寫法與影响
- max-age=86400：资源在一天内被视為新鲜。如果入口頁連結會频繁調整，這種設定會让部分抓取請求拿到舊内容，蜘蛛看到的新連結自然變少。
- no-cache：允许缓存，但每次使用前要向源站驗證。對入口頁比較友好，既能减少传輸，又能让源站决定是否返回新内容。
- no-store：完全不缓存。蜘蛛每次訪問都會完整拉取，源站压力更大，但内容實时性最好。适合連結變化非常频繁、且服務器能承受抓取的入口頁。
- must-revalidate：過期後必须回源驗證，不能使用過期副本。常與 max-age 搭配，避免過期内容被繼續使用。
没有一套參數适合所有蜘蛛池。入口頁更新频率、服務器承载能力和抓取频次，决定你该偏向實时還是偏向节省請求。
ETag 與 Last-Modified：條件請求的两種依據
ETag 和 Last-Modified 本身不會让蜘蛛多抓，但它們决定蜘蛛再次訪問时，源站能否用 304 响應告诉它“内容没變”。如果入口頁内容确實没變，304 可以节省带宽，也能让抓取预算用在其他 URL 上。但如果入口頁已经新增了連結，源站却因為 ETag 生成規則不合理、Last-Modified 時間没更新而繼續返回 304，蜘蛛就不會重新解析頁面，新增的目标 URL 也就不會被發現。
常见問题出在動態生成的入口頁：ETag 基于文件修改時間或固定字符串，内容變了但 ETag 不變；或者 Last-Modified 取的是模板時間，不是實际資料更新時間。這類情况下，蜘蛛看到的是“未修改”，實际頁面已经變了。
為什么入口頁不适合長期强缓存
有些运营者把入口頁当作静態 HTML 放到 CDN 上，並設定很長的 max-age。這样做的好處是源站压力小，坏處是連結更新後，CDN 邊缘节点仍可能返回舊版本。搜尋蜘蛛如果通過不同节点訪問，拿到的内容還可能不一致。入口頁的核心價值在于“發現連結”，舊版本會让 URL 發現效率下降。
CDN 缓存對蜘蛛池的額外影响
使用 CDN 时，搜尋蜘蛛請求的不一定是源站。CDN 的缓存策略、回源規則、Vary 响應头都會影响最终返回内容。如果 Vary 設定得太宽，或者按 User-Agent 返回不同頁面，缓存系統可能把蜘蛛的請求和普通用戶請求混在一起。排查时不要只看源站日誌，也要看 CDN 的缓存命中情况和回源日誌。
一個相對稳妥的入口頁缓存配置思路
- 入口頁優先使用 Cache-Control: no-cache 或較短的 max-age，例如 60 到 300 秒，让内容變化能較快传递。
- 保留 ETag 和 Last-Modified，但确保它們随内容變化而更新，不要用固定值。
- 如果入口頁連結更新频繁，可以測試 no-store，同时观察源站负载和蜘蛛抓取频次。
- CDN 上對入口頁單獨設定缓存規則，避免被其他静態资源的長缓存策略覆盖。
- 修改缓存头後，用抓取工具或日誌观察蜘蛛回訪时拿到的狀態碼和内容版本。
缓存头是抓取效率的調节器，不是收錄開關。把入口頁当成會變化的頁面来配置，通常比当成静態文件更符合 URL 發現的需要。
排查时看什么
如果新增目标 URL 後搜尋蜘蛛長時間没有反應，可以先看入口頁的响應头：Cache-Control 是否設定了很長的新鲜期，ETag 是否在内容變化後仍然相同，CDN 是否返回了舊版本。再對比源站日誌和 CDN 日誌，確認蜘蛛請求到底命中了哪里。多數情况下，調整缓存策略後需要一段時間观察，不要期待立即變化。