缓存为什么也是站点运营的事
缓存本身不改变内容质量，但它决定了蜘蛛和用户在不同时间、不同节点上看到的是哪一版页面。常见的情况是：编辑在后台改好了标题和正文，本地刷新也对，但搜索引擎抓到的仍是几小时前的旧版本；或者反过来，一个临时的错误页面被缓存住，长时间挂在搜索结果里。这些问题往往不是内容问题，而是缓存规则没理清。
做缓存自查的目标很简单：新内容尽快可见，旧内容按预期退出，不该缓存的页面绝不缓存。
先分清三层缓存
浏览器缓存
由 Cache-Control、Expires、ETag 等响应头控制，影响回访用户和部分爬虫的重复抓取行为。HTML 通常建议短缓存或协商缓存，静态资源可以长缓存。
CDN / 反向代理缓存
缓存的是节点上的副本，通常关注 缓存键（URL、查询参数、Host、Accept-Encoding、UA 等）和 TTL。缓存键设置过粗，会把不同版本的页面混在一起；设置过细，命中率又会掉下来。
源站应用层缓存
页面片段、数据库查询、对象缓存等。这层出问题时的表现是：CDN 已经刷新了，但回源拿到的还是旧内容。
常见配置思路
- HTML 页面：设置较短的 TTL，或使用协商缓存，让内容变更后能较快生效；首页、栏目页、详情页可以按更新频率区别对待。
- CSS、JS、字体、图片：文件名带指纹（hash 或版本号）时可以设置长缓存，改版时靠文件名变化自动失效。
- 接口与动态请求：明确标注不可缓存，避免把用户相关数据缓存到公共节点。
- 错误状态码：404、5xx 页面不要长缓存，否则一次抖动会持续影响抓取。
- robots.txt 与 sitemap：建议短缓存甚至不缓存，避免规则更新后蜘蛛仍在读旧文件。
发布新内容后的自查动作
- 确认发布流程里包含缓存刷新（purge）这一步，而不是靠等 TTL 自然过期。
- 用 curl -I 或浏览器开发者工具查看响应头，重点看 Cache-Control、Age、X-Cache 等字段，判断命中的是节点副本还是回源结果。
- 换几个不同地区的解析节点抽查同一 URL，确认各节点返回内容一致。
- 检查首页、栏目页、sitemap 是否同步更新，避免只剩详情页是新的。
- 记录一次刷新到生效的大致耗时，作为后续运营的参考。
几个容易踩的坑
- 移动端与桌面端共用一份缓存：如果站点按 UA 输出不同模板，缓存键里必须体现这一点，否则会串版。
- 带登录态的页面被缓存：公共节点缓存了个人中心之类的页面，既有安全问题，也会让蜘蛛抓到不该抓的内容。
- 301 和 404 被长期缓存：URL 迁移或页面恢复后，节点仍返回旧状态，看起来像“改了没用”。
- 回滚时只回滚代码，忘了刷新缓存：结果新旧版本混在一起，排查起来很费时间。
- CDN 与源站压缩不一致：开启压缩后要确认缓存键包含编码维度，避免返回乱码或解压失败。
缓存自查不需要一次做到完美，先把首页、栏目页、sitemap、robots.txt 这几个关键位置的规则写清楚，收益通常最直接。
一份可执行的检查清单
- 列出站点主要页面类型，逐类标注期望的缓存时长与刷新方式。
- 核对静态资源是否带指纹、是否长缓存。
- 确认发布流程中缓存刷新是固定动作。
- 抽查三类 URL：刚发布的详情页、刚修改的栏目页、近期下线的旧页。
- 记录一次异常情况的处理过程，形成文档。
把缓存当成内容发布流程的一部分来管，蜘蛛看到的版本和用户看到的版本才不会长期打架。