蜘蛛访问的不一定是你的源站
很多站点在源站前面加了 CDN 或反向代理，搜索蜘蛛请求时命中的往往是缓存层。如果缓存策略设置得不细，会出现两种典型情况：内容已经更新，但蜘蛛连续多天抓到旧副本；或者缓存把错误页、空列表页甚至带登录态的页面存了下来，再统一返回给所有访客。这两种情况都谈不上被惩罚，但会让抓取结果与你的预期长期错位，靠感觉判断很难发现问题。
先把缓存层级列清楚
自查的第一步不是改配置，而是画出完整的请求链路。
- 浏览器本地缓存：主要影响回访用户，对蜘蛛影响有限，但会干扰你自己的测试结果。
- CDN 边缘节点：蜘蛛最常命中的一层，需要重点看 TTL 与刷新机制。
- 反向代理或应用层缓存：例如 Nginx proxy_cache、Varnish、页面静态化。
- 对象存储与静态资源：文件名带哈希的版本化资源，可以放心设置较长缓存。
- 数据库与接口层缓存：影响列表页、聚合页的内容新鲜度。
把每一层的生效条件、过期时间和清理方式写下来，后面排查时才能定位到具体是哪一层在返回旧内容。
重点看这几个响应头
- Cache-Control：区分 max-age 与 s-maxage，前者面向浏览器，后者面向共享缓存；不确定的页面可以用 private 或 no-store。
- Age：告诉你这份响应在缓存里放了多久，内容更新后如果 Age 依旧很大，说明刷新没有生效。
- Vary：多语言、多终端站点要确认是否按 UA、Accept-Language 区分，避免不同版本互相覆盖。
- ETag 与 Last-Modified：条件请求的基础，缺失时蜘蛛可能整页重新下载。
- 自定义命中标识：部分 CDN 会返回 X-Cache 之类的头，便于快速判断命中还是回源。
内容更新后的缓存处理
建议在发布流程里固定三件事。
- 主动刷新：文章页、栏目页更新后调用 CDN 的刷新接口，按 URL 或目录清理。
- 版本化资源：CSS、JS、图片改名带哈希，用新地址替代刷新旧地址。
- 发布后验证：抽查若干 URL，确认返回的正文、标题、时间已经更新，Age 已归零或很小。
错误页面不要被长期缓存
5xx 通常是临时的，适合设置很短的 TTL 或不缓存，否则故障恢复之后，缓存层仍在返回错误状态。404 与 410 可以短时间缓存以减少源站压力，但不建议设置数月。同时注意缓存键是否忽略了无意义的追踪参数，否则同一篇内容会被拆成大量缓存副本，既浪费存储，也会让蜘蛛在不同时间拿到不同结果。
容易忽略的几个细节
- 不同地区、不同节点返回的内容是否一致，可以多地抽查同一个 URL。
- 带登录态或个性化推荐的页面是否被共享缓存，检查是否误返回 Set-Cookie。
- 分页、筛选参数的缓存策略是否与正文页相同，避免组合地址被缓存成大量重复页面。
- 站点改版或模板调整之后，旧缓存是否已经清理干净。
- 缓存命中率、回源率是否有监控，出现异常时能否及时发现。
缓存的目标是让内容更快到达用户和蜘蛛，而不是让旧版本停留更久。把刷新动作写进发布流程，比事后逐一排查省事得多。
建议的检查节奏
小型站点可以在每次较大范围更新后抽查一次；内容更新频繁的站点，建议把缓存刷新与发布流程绑定，并每月做一次多地节点对比。记录下每次异常的 URL、时间和处理方式，长期看比临时修改配置更有价值。