把蜘蛛池入口页放在 CDN 后面是常见做法，能扛并发、减少源站压力。但 CDN 上的缓存副本和源站内容并不是时刻一致的，搜索蜘蛛抓到的那份页面，有可能是几小时甚至几天前的旧版本。里面的链接列表、锚文本、跳转目标都会跟着一起被“冻住”，于是你在源站改了半天，蜘蛛那边看不到变化。
缓存命中时，蜘蛛拿到的到底是谁的版本
搜索蜘蛛发起请求后，请求会先落到 CDN 边缘节点。如果该 URL 在节点上还在缓存有效期内，节点会直接把缓存副本返回，请求根本到不了源站。整个过程对蜘蛛来说和正常访问没有区别：状态码 200、页面有内容、链接也在，只是这份内容是旧的。
所以判断这类问题，不能只看“源站更新了没有”，还要看“边缘节点什么时候回源”。
几个比较典型的表现
- 日志里蜘蛛请求频率正常，但抓走的 URL 列表和源站当前的不一致。
- 源站访问日志里看不到蜘蛛 IP，只有 CDN 回源节点的记录。
- 同一时间不同地区节点的抓取结果不同，有的还返回旧链接。
- 手动刷新缓存后短时间内内容更新，过一阵又回到旧版本。
排查顺序建议
- 用同一个 URL 请求一次，看响应头里的缓存标识（如 Age、X-Cache、CF-Cache-Status 等），确认是否命中缓存。
- 对照 CDN 控制台的缓存规则，看入口页路径是不是被套用了较长的 TTL。
- 检查源站日志里有没有 CDN 回源请求，以及回源的间隔。
- 把蜘蛛日志和 CDN 日志按时间对齐，找出内容“切换”的时间点。
- 确认这次改的是链接结构还是仅仅锚文本，改链接结构的影响更大，值得单独处理。
处理思路
比较稳妥的做法是让入口页的缓存时间短一些，或者对入口页这类需要经常变化的页面单独设规则，不和静态资源共用同一套 TTL。
- 改链接结构前，先刷新对应路径的 CDN 缓存，再等蜘蛛下一次抓取。
- 入口页的 HTML 不建议设“一年过期”这类长缓存，图片、脚本可以长，页面本身短一些。
- 如果入口页是动态生成的，检查 CDN 是否忽略了某些查询参数，避免不同参数被合并成同一条缓存。
- 多节点部署时，注意缓存刷新是否覆盖全部节点，部分服务商的刷新是按区域生效的。
缓存问题不一定让蜘蛛抓取失败，更常见的后果是“抓到了，但抓到的是旧链接”，从现象上看和抓取正常几乎一样，容易被忽略。
容易混淆的几种情况
并不是所有“蜘蛛拿到的链接不对”都出在 CDN 上。也可能是源站本身有页面级缓存（反向代理、框架缓存）；或是入口页的生成逻辑里读了会过期的数据；再或者蜘蛛抓的是一条早被替换掉的旧 URL，而那条 URL 在节点上还有缓存副本。
把这几层分开看，先确认请求链路上究竟哪一层返回了旧内容，再决定是刷缓存、调 TTL，还是改生成逻辑。
处理顺序上，先定位再动手会省很多时间。建议在改动入口页结构之前，先留一份简单对照记录：源站版本、缓存状态、蜘蛛最近一次抓取时间。后面再出问题时，不用重新推一遍。