搭蜘蛛池的时候，大家往往盯着頁面内容、連結结构、域名歷史，却很少回头看 HTTP 响應头。實际上蜘蛛每次抓取拿到的第一手信息就是响應头，缓存策略配得不對，蜘蛛可能白跑一趟，也可能反复拉取同一份内容。
缓存头為什么會影响蜘蛛
普通用戶的浏览器缓存是為了省流量、加快二次訪問；抓取器同样會遵循一部分 HTTP 缓存语义，尤其是條件請求相關的那几個字段。区別在于，蜘蛛更在意「内容有没有變」，而不是「加载快不快」。如果服務器長期只回 304，蜘蛛會認為頁面没更新，来的频率自然下降；如果每次都回 200 且内容完全一样，抓取成本偏高，也浪費了抓取预算。
几個關键响應头怎么理解
Cache-Control
常见的 max-age 表示资源在多少秒内被视為新鲜。對入口頁這類需要经常被發現的頁面，設定過長的 max-age（比如一天以上）意义不大，因為蜘蛛的抓取間隔往往由自身策略决定，不完全受它约束。更稳妥的做法是给一個中等長度的缓存時間，让 CDN 能缓存，同时源站的更新仍能及时反映出来。
no-cache 和 no-store 经常被混用。no-cache 表示可以缓存但每次要回源校驗，no-store 表示完全不缓存。入口頁一般不需要 no-store。
ETag 與 Last-Modified
這两個字段用来支持條件請求。蜘蛛带上 If-None-Match 或 If-Modified-Since 再来时，服務器判断内容没變就回 304。問题常出在两類情况：一是動態生成的 ETag 每次都不一样，比如带上時間戳或進程 ID，導致永遠回 200，缓存形同虚设；二是内容明明更新了，Last-Modified 却没跟着變，蜘蛛拿到的還是舊判断。
Vary
如果入口頁會根據 User-Agent 返回不同内容，一定要在 Vary 里声明，否則中間缓存可能把 A 版本發给 B 請求。更需要注意的是，有些站群程序给蜘蛛版和用戶版返回差异過大的頁面，這在搜尋质量评估里属于高風險行為。
X-Robots-Tag
這是寫在响應头里的 robots 指令，作用與 meta robots 類似。排查「頁面明明能訪問却迟迟没有動静」时，別忘了检查這個头里有没有被加上 noindex。它经常出現在 CDN 或安全策略的預設配置里，最容易被忽略。
304 太多或太少都不是好事
長期只回 304，說明頁面确實没變，但入口頁如果几個月都不更新，蜘蛛的訪問動力會下降。反過来，每次請求都回 200 且内容一模一样，也會让蜘蛛觉得這個頁面不值得反复来。比較合理的节奏是：入口頁有實质更新时，内容變了、ETag 跟着變、正常回 200；没有更新的周期里，让 304 正常工作。
几個容易踩的坑
- 用脚本生成随机 ETag，看着像在優化缓存，其實是把缓存彻底废掉。
- CDN 缓存時間遠長于源站更新频率，導致蜘蛛抓到的是過期版本。
- 把所有入口頁设成 no-store，等于要求沿途每個节点都回源，源站压力集中。
- 服務器時間不准，Last-Modified 出現未来時間，條件請求的判断會乱。
- 响應头里同时出現多條 Cache-Control，语义冲突时行為难以判定，最好只保留一條。
一個可落地的配置思路
- 先確認入口頁的更新频率，據此定缓存時間，不要照搬静態资源的配置。
- ETag 用内容哈希生成，而不是随机值或時間戳。
- 保證 Last-Modified 與内容實际變更時間一致，服務器时钟保持同步。
- 如果做了 UA 分流，Vary 要寫清楚，並尽量让不同版本的核心内容一致。
- 上线後抽查响應头，用 curl -I 看一遍，通常比在浏览器里看更准。
- 改完观察一段時間的抓取日誌，看 304 與 200 的比例是否接近预期。
缓存和响應头是抓取鏈路上的基础设施，調好它們不會直接带来效果，但配错了一定會拖後腿。
整体来说，這類配置没有标准答案，取决于入口頁的更新节奏和资源结构。與其把它当成一次性的技術细节，不如当成日常巡检的一部分，配合日誌复盘，問题通常能在早期被發現。