缓存头為什么會出現在运营视角里
蜘蛛每天能分配给一個站点的抓取次數是有限的，具体多少由它自己决定，我們看不到也改不了。但有一件事是可以做的：让它在已经確認没變化的頁面上少花一点時間。如果每個頁面每次被抓都返回 200 和完整正文，服務器要重新拼一次頁面，蜘蛛也要重新解析一遍；如果服務器能明确告诉它“這個頁面自上次之後没改過”，它就有机會直接跳過内容抓取。
這個信号主要来自响應头里的几項：Last-Modified、ETag、Cache-Control、Expires。它們本来是给浏览器和 CDN 用的，但蜘蛛同样會讀。
三個常见的错誤配置
1. Last-Modified 每次都變
有些 CMS 或者模板在輸出头的时候，顺手寫了目前時間。结果就是：不管頁面有没有改，每次响應的 Last-Modified 都是新的，蜘蛛永遠得不到“未修改”這個判断依據，304 也就無從谈起。
2. ETag 不稳定
ETag 如果基于文件 inode、進程 ID 或者随机串生成，多台服務器之間就會互相打架。蜘蛛上一次從 A 机器拿到一個 ETag，這一次從 B 机器拿到另一個，它只能当成新内容處理。
3. 全局關掉了缓存
有的站点為了“保證内容最新”，在 Nginx 或應用层给整站加了 no-store、no-cache、max-age=0，静態资源、栏目頁、文章頁一视同仁。對用戶来说影响不大，對抓取来说就是每一次都按全新頁面處理。
怎么自查
- 用 curl -I 或者浏览器開發者工具，拉两遍同一個 URL 的响應头，比較 Last-Modified 和 ETag 有没有變化。
- 如果頁面确實没有改動，两次的值應该完全一致。
- 带上 If-Modified-Since 再請求一次，看服務器會不會返回 304。
- 顺手看一下 Cache-Control 有没有作用到 HTML 上，图片、CSS、JS 這些静態资源是不是配了更長的缓存時間。
- 经過 CDN 或反向代理的站点，两邊都查一遍，確認缓存层没有把上游的头丢掉或者改寫。
設定时的几個原則
- Last-Modified 用内容本身的更新時間，也就是文章最後修改的時間，不要用目前時間。
- 静態资源可以给長缓存，文件名带版本号或哈希值，更新时換名字，不用靠短缓存来兜底。
- HTML 頁面谨慎使用長缓存，可以用較短的 max-age 配合 Last-Modified 或 ETag。
- 多机部署时统一 ETag 生成規則，避免同一頁面在不同机器上给出不同标识。
- 缓存头不是排名手段，它只影响服務器和蜘蛛之間的沟通效率。
观察节奏
不需要天天盯着。比較合适的做法是每個月抽一批代表性 URL——首頁、栏目頁、最近的几篇文章、几張图片——走一遍上面的检查。改動過服務器配置、上了 CDN、換過模板之後，再补做一次。
如果抓取日誌里能看到大量重复請求同一批没變的頁面，而且這些頁面的响應体都是完整正文，那基本可以判断缓存头没有生效，值得回头看一眼。
缓存头不會让蜘蛛多来，也不會让收錄變快。它只是在蜘蛛来的时候，让它少做一点重复劳動。這件事的價值不在某一次抓取，而在于把省下来的配額留给真正有變化、還没被發現的頁面。