入口页部署完成，域名解析正常，状态码、robots、sitemap 都检查过一遍，但你在日志里发现：蜘蛛确实来了，读到的却不是最新版本。这类问题里有相当一部分并不在源站，而在源站前面的那层 CDN 缓存。
CDN 为什么会让蜘蛛看到旧页面
开启 CDN 之后，蜘蛛请求的往往不是你的服务器，而是离它最近的一个边缘节点。该节点如果已经缓存过这个 URL 的响应，就会直接把缓存副本返回，源站根本收不到这次请求。对蜘蛛来说，它拿到的就是你上次回源时的那份 HTML，包括里面的链接清单、标题和正文。
入口页通常是链接清单型页面，改动频繁但体积很小，恰好最容易被缓存：内容小、命中率高、回源少，缓存节点自然倾向于一直留着。
缓存键里有哪些维度
路径与查询参数
- 默认情况下，带不同查询参数的 URL 一般被当成不同的缓存对象，也可能被配置成忽略参数。
- 如果入口页靠参数分页或分类，忽略参数会导致不同页面拿到同一份缓存内容。
Host、UA 与 Cookie
- 部分 CDN 支持按 UA、设备或 Cookie 分片缓存，蜘蛛的 UA 可能命中一个独立副本。
- 如果分片规则恰好把蜘蛛归到某个很少被刷新的分组，它看到的版本会比普通用户更旧。
怎么判断命中缓存还是回源
- 看响应头：Age 大于 0 基本就是缓存副本；X-Cache、CF-Cache-Status、X-Via 之类的字段会直接标出 HIT 或 MISS。
- 对照源站访问日志：如果某些入口页长期没有回源记录，但蜘蛛仍在持续抓取，多半说明它一直在读缓存。
- 用命令行带蜘蛛 UA 请求，并指定不同节点 IP，观察返回内容是否一致、是否落后于源站。
不要为了验证是否命中缓存而用带随机参数的 URL 去请求。蜘蛛会把这些参数当成新地址，最后你手里多出来的是一堆重复的入口页。
入口页更新后的处理顺序
- 先在源站确认新版本已经可以正常访问。
- 提交刷新（purge）该路径，必要时连目录一起刷。
- 刷新后主动请求一次做预热，避免蜘蛛第一个请求就打回源站造成超时。
- 对经常改动的入口页，适当下调 TTL，让缓存副本的过期时间短一些。
几个常见误区
- 改了源站就等于全网生效：不同节点的过期时间并不完全同步。
- 把缓存当成“稳定”：入口页需要更新时，稳定反而意味着蜘蛛看不到新链接。
- 用时间戳参数强行破缓存：短期看似有效，长期会制造大量内容相同的 URL。
- 只关注 HTML 缓存：robots.txt、sitemap，甚至 301 跳转本身也可能被缓存，改动它们时同样要刷新。
相对稳妥的做法
- 入口页与站内普通页面分开配置缓存策略，前者 TTL 短一些，后者可以长一些。
- 把“更新内容”和“刷新缓存”写进同一条操作流程，避免只做一半。
- 定期抽查几个入口页的 Age 和响应内容，确认蜘蛛看到的是当前版本。
- 缓存配置发生变更时记录时间和涉及的路径，方便事后对照日志排查。
CDN 缓存本身不是问题，问题在于它常常被漏在检查清单之外。当入口页、解析、状态码都排查过一遍仍然不对时，把缓存这一层单独拿出来看，往往能解释“蜘蛛来了，却没看到新东西”这种现象。