把入口页挂在 CDN 后面之后，常会遇到一种别扭的情况：源站已经加了新的目标链接，本地浏览器打开也能看到，可搜索蜘蛛抓到的还是几天前那一版 HTML。目标 URL 于是就卡在“没被发现”的状态里。
这类问题多数不是蜘蛛不来，而是它来的那一刻，CDN 直接把缓存里的旧页面返回了。要判断和处理，需要先把“蜘蛛拿到的是哪一份 HTML”这件事弄清楚。
缓存命中时，蜘蛛看到的是过期副本
CDN 的常规逻辑是：请求到达边缘节点，如果缓存中有一份未过期的响应、且缓存键匹配，就直接返回，不回源站。搜索蜘蛛的请求如果没有被特殊标记，通常和普通访客一样命中这份缓存。
也就是说，源站更新了链接，不代表边缘节点立刻更新。缓存没到期、也没被主动清除之前，蜘蛛每次来拿到的都可能还是旧 HTML，里面自然没有你新加的 URL。
容易造成新旧错位的几种设置
- 入口页缓存时间设得太长：比如把 HTML 的边缘缓存或浏览器缓存设成几天，链接改动后要等很久才会回源。
- 按 User-Agent 做了差异化缓存：给蜘蛛返回的是一个简化版或空壳页，而这份版本本身又被缓存，之后就一直返回同一份。
- Vary: Cookie 之类的响应头：蜘蛛不带 Cookie，会被分到另一份缓存，有可能正好是不含新链接的那份。
- 缓存清除只清了主 URL：入口页带 utm 或其它查询参数时会被当成不同的缓存键，旧副本仍然留在边缘节点。
- 把 HTML 当成静态资源长期缓存：某些规则里 HTML 也被打上了长缓存，更新后页面内容迟迟不换。
怎么确认蜘蛛拿到的是不是旧版
- 用搜索蜘蛛的 User-Agent 请求入口页，把返回的 HTML 抓下来，直接搜目标链接是否在里面。
- 观察响应头里的缓存状态字段，例如 Age、X-Cache、CF-Cache-Status，判断这次是 HIT 还是 MISS。
- 对比同一时刻直连源站 IP 的返回内容，看看两边是不是同一份 HTML。
- 核对 Last-Modified、ETag 是否随改动变化，长期不变往往意味着拿到的是缓存副本。
确认是缓存问题之后的处理
- 发布链接改动后，主动对入口页 URL 做一次缓存刷新，缩短等待时间。
- 给 HTML 类型的响应设置更短的边缘缓存时间，必要时用 stale-while-revalidate 之类的策略平衡回源压力。
- 检查是否存在按 UA 分流的规则，避免蜘蛛被分到一个内容不全的版本。
- 把带参数和不带参数的入口页归到同一缓存键，或在参数变更后一并清除。
- 改动完成后重新观察搜索蜘蛛的访问记录，确认它下次取到的是新 HTML。
缓存刷新解决的是“蜘蛛读到的 HTML 是不是最新”这一环。至于它拿到新链接之后会不会去抓、什么时候抓，还受抓取预算、目标页质量、robots.txt 等条件影响，不能把它当成结果上的保证。
小结
入口页加了链接却迟迟没有动静时，先别急着怀疑蜘蛛池本身。用带蜘蛛 UA 的请求确认拿到的是源站 HTML 还是缓存副本，往往几分钟就能排除一大半可能性。真正需要长期维护的，是入口页的缓存策略，以及更新内容后及时刷新的习惯。