开启 CDN 和页面缓存之后，服务器压力通常会明显下降，但缓存层也带来一个副作用：蜘蛛看到的页面，可能不是你刚更新的那一版。缓存本身不是问题，问题在于缓存了什么、缓存多久、出错时返回什么。
缓存为什么会干扰抓取
搜索引擎蜘蛛拿到的响应，往往经过 CDN 节点或反向代理，而不是直接打到源站。如果缓存层把旧的 HTML 版本、临时的错误页、甚至带登录态的页面存了下来，蜘蛛就会按这份副本来理解你的站点。更麻烦的是，这类问题在浏览器里经常看不出来，因为你的浏览器可能命中了另一个节点，或者带上了不同的请求头。
常见缓存问题自查
- 错误状态被缓存：源站短暂 500 或超时，CDN 返回错误页并缓存下来，后续正常请求也拿到错误页。
- 404 页被长缓存：某个地址先被删除再恢复，但节点上还留着 404 响应。
- 更新后仍是旧内容：文章已改，缓存过期时间却设得很长，蜘蛛连续几天读到旧版本。
- 缓存键设置不严：忽略了查询参数或语言 Cookie，不同参数返回同一份内容，或内容互相串。
- 带状态的页面被缓存：登录后页面、后台预览链接、测试参数页进了公共缓存。
- 跳转被长期缓存：一次临时跳转被当成长期规则，蜘蛛一直跟着旧路径走。
- 节点之间不一致：不同地区节点返回的标题、正文甚至状态码不同。
怎么验证缓存是否正常
- 用命令行请求首页和一个内容页，查看响应头里的缓存命中信息、缓存年龄和过期时间。
- 在内容更新后，立即请求同一地址，确认返回的是新内容而不是旧版本。
- 换几个不同地区的节点或工具再请求一次，对比标题、正文和状态码是否一致。
- 找几个已下线的地址，确认返回的是 404，而不是被缓存下来的旧页面。
- 翻服务器日志，关注蜘蛛的响应码分布，如果 5xx 或 304 异常集中，可能和缓存层有关。
和蜘蛛抓取的关系
蜘蛛的抓取预算有限，如果它反复拿到错误页或未更新的内容，容易降低对该地址的访问意愿。反过来，缓存用得好，可以显著降低源站压力，让蜘蛛在高峰期也能稳定拿到 200 响应。关键是把缓存当成一层需要管理的服务，而不是开启后就不管。
缓存的目标是让正常内容更快返回，而不是把异常状态固定下来。凡是会变化的、带权限的、出错的响应，都值得单独确认一次。
日常维护建议
- 给 HTML 设置适中的缓存时间，内容更新时主动刷新相关路径。
- 错误状态、重定向、带查询参数的结果，尽量不进入长期缓存。
- 把 CDN 缓存规则写进上线流程，改版或批量更新时一起检查。
- 保留一份直连源站的验证方式，方便区分是源站问题还是缓存问题。
- 定期抽查若干页面的缓存状态，尤其是首页、栏目页和近期更新的内容页。
缓存不是开启之后就一劳永逸的功能，它需要配合发布节奏一起维护。把命中信息、过期时间和错误响应纳入日常检查，蜘蛛看到的页面才和你以为的一致。