很多人在調蜘蛛池时會盯着入口頁的連結和内容，却忽略了一個不起眼的细节：HTTP 响應头里的缓存字段。它不直接决定搜尋蜘蛛来不来，但會影响蜘蛛再次訪問同一個入口頁时的判断——頁面到底變没變，值不值得重新解析一次。
搜尋蜘蛛怎么判断入口頁有没有更新
搜尋蜘蛛並不是每次回訪都完整下载整頁内容。当它已经持有這個 URL 的缓存副本时，通常會带上 If-Modified-Since（對應 Last-Modified）或 If-None-Match（對應 ETag）来询問服務器：這個頁面變了吗？服務器如果回 304 Not Modified，蜘蛛就知道内容没變，多數情况下會跳過解析，只更新一下抓取记錄。
Last-Modified 和 ETag 分別管什么
- Last-Modified：頁面上次修改的時間，精度到秒，适合更新不频繁的静態入口頁。
- ETag：内容指纹，内容變則值變，對模板化生成、時間戳固定的頁面更准确。
- 两者可以同时存在，蜘蛛一般會優先用 ETag 做判断。
304 响應本身不是坏事
304 是省流量的正常机制，不會因為出現 304 就让蜘蛛降低抓取频率。真正要留意的是另一種情况：入口頁明明新加了指向目标 URL 的連結，服務器却因為缓存配置没跟上，依舊回 304。蜘蛛會以為頁面没變，新連結自然也就不會被發現。
几種容易踩坑的缓存寫法
- 缓存時間設定過長，頁面已经改過但响應头没更新，蜘蛛一直拿到舊的 304。
- ETag 每次請求都重新生成，例如掺入随机數或請求時間，蜘蛛每次都判定内容已變，白白消耗抓取预算。
- Last-Modified 寫成未来時間或每次都是服務器目前時間，蜘蛛會反复回訪確認。
- 整站套用统一的静態缓存策略，入口頁更新後没有及时刷新缓存节点或 CDN。
缓存头是给搜尋蜘蛛省成本用的，不是用来催它来的工具。把响應头寫准，比反复調整抓取节奏更實在。
實操上的排查顺序
- 先用命令行工具請求入口頁，看响應头里的 Last-Modified、ETag、Cache-Control 是否符合预期。
- 手動带上 If-Modified-Since 再請求一次，確認内容變化後服務器返回的是 200 和新内容，而不是 304。
- 检查入口頁更新後，CDN、反向代理和程序内缓存有没有同步失效。
- 如果入口頁由程序動態生成，確認 ETag 不是每次都在變的随机值，可以按内容哈希計算。
- 把入口頁的訪問日誌與响應狀態對照着看，統計 304 與 200 的比例是否合理。
別把缓存头的作用想得太大
缓存配置只影响蜘蛛“要不要重新解析”這一小步。入口頁能否被稳定抓取、目标 URL 是否值得跟進，仍然取决于入口頁本身能否正常訪問、連結结构是否清晰、目标站是否允许抓取。基础問题解决之後，再回头優化响應头，收益才比較明顯。
如果發現蜘蛛回訪频率持續偏低，優先排查的應该是入口頁是否可訪問、是否被 robots.txt 拦住、是否存在大量重复内容，而不是先去改 Cache-Control。顺序搞反，容易白折腾一场。