做站点运营时，URL 结构、内链、Sitemap 这些环节通常会被反复检查，但 CDN 与缓存这一层常常被跳过。蜘蛛请求页面时，拿到的往往不是源站刚刚生成的 HTML，而是边缘节点上的一份副本。缓存策略如果和内容更新节奏对不上，就会出现源站已经改完、蜘蛛看到的还是旧版本的情况。
缓存为什么会改变蜘蛛看到的内容
搜索引擎抓取的是一个 URL 的 HTTP 响应，而这份响应可能来自源站，也可能来自 CDN 节点或反向代理的缓存。这带来三个直接后果：
- 内容更新后，如果 HTML 缓存未过期，蜘蛛抓到的仍是旧正文、旧标题或旧链接；
- 状态码同样会被缓存，被缓存的 404 或 301 会在缓存周期内持续返回给蜘蛛；
- 缓存键设置不合理时，不同参数的页面可能互相覆盖，返回同一份内容。
所以缓存不只是运维话题，它直接决定了蜘蛛实际读到什么。
发布前值得确认的几项策略
HTML 文档的缓存时长
动态生成的 HTML 一般不建议做长时间缓存。常见做法是给 HTML 设置较短的 s-maxage，或者使用 must-revalidate，让节点在内容更新后能较快回源。把 HTML 缓存一整天，虽然能减轻源站压力，但当天所有改动对蜘蛛来说都是不可见的。
静态资源用长缓存加版本指纹
CSS、JS、图片这类文件可以放心使用长缓存，前提是文件名或查询串带版本号。更新时改文件名，蜘蛛和浏览器自然会拿到新文件，不需要专门去刷新缓存。
状态码不要被长期缓存
需要特别检查 404、410、301、302 的缓存头。一个临时下线的页面如果被缓存成 404，在缓存过期前蜘蛛每次来都会得到同样的结果；被缓存的跳转也一样，即使你后来改回了正常页面，节点仍会继续跳。
缓存键与查询参数
确认缓存键是否包含查询参数。如果忽略参数，分页、筛选、排序这些带参数的 URL 会共用一份缓存，蜘蛛抓到的内容与 URL 不对应，容易被判定为重复或空壳。反过来，如果参数过度参与缓存键，又会造成大量回源。
robots.txt 与 sitemap.xml
这两个文件通常放在根目录，也很容易被 CDN 一起缓存。它们的缓存时间建议短一些，避免新规则或新地址迟迟不生效。
内容更新后的刷新动作
- 发布完成后，主动刷新首页、栏目页、被改动的详情页，以及 sitemap.xml；
- 涉及 URL 变更的，先确认 301 已生效，再刷新对应地址；
- 把「刷新关键 URL」写进发布流程，而不是等发现问题再补；
- 大范围改版时，考虑整站刷新一次，并观察回源量是否会给源站带来压力。
怎么验证节点返回的是最新内容
- 用 curl -I 或浏览器开发者工具查看响应头，关注 Age、X-Cache、CF-Cache-Status 这类字段，判断是否命中缓存、缓存了多久；
- 带上搜索引擎的 UA 再请求一次，确认没有针对 UA 的差异化缓存；
- 从不同地区或不同节点请求同一个 URL，对比正文与状态码是否一致；
- 在 CDN 后台看命中率与回源量，异常升高往往意味着缓存键被频繁绕过。
缓存的目标是减少回源，而不是让内容停留在过去。判断标准很简单：发布十分钟后再抓一次，蜘蛛看到的是不是你现在看到的这一版。
几个常见的坑
- 为了提高命中率，把 HTML 缓存设得很长，更新只能靠手动刷新；
- 测试环境与生产环境共用一套缓存规则，测试页被节点缓存后影响线上；
- 只刷新首页，忘了列表页和 sitemap；
- 对 404 做长缓存，把后来重新上线的页面挡在门外；
- 忽略 Vary 头，导致压缩版与未压缩版、移动版与桌面版互相污染。
小结
CDN 与缓存不需要复杂配置，但需要和发布流程绑在一起：HTML 短缓存、静态资源长缓存加指纹、异常状态码不长期缓存、关键 URL 发布后主动刷新。把这四件事固定下来，蜘蛛读到的内容基本就能和源站保持一致。