很多站点接入 CDN 之后，访问速度上去了，但搜索蜘蛛那边却开始出现奇怪的抓取记录：同一个 URL 有时返回 200，有时返回 404；页面内容明明已经更新，蜘蛛拿到的还是几天前的版本；源站日志里看不到蜘蛛，CDN 日志里却有一堆 5xx。这类问题通常不是源站坏了，而是边缘缓存和回源策略没有对齐。
CDN 缓存为什么会影响抓取
搜索蜘蛛访问站点时，走的路径和普通用户基本一致，也会先到 CDN 节点。如果节点上有缓存，就直接返回缓存内容，不回源站。于是缓存什么、缓存多久、按什么维度区分缓存，都会直接影响蜘蛛看到的内容。
更麻烦的是，CDN 通常只按 URL 和少量请求头做缓存键。如果站点有移动端适配、多语言、登录态或 A/B 测试，缓存键没覆盖这些差异，蜘蛛可能拿到不匹配的版本。
常见的缓存与回源问题
- 错误状态码被缓存：源站短暂 404、500 或 503，被 CDN 按普通页面缓存下来，后续蜘蛛和用户持续看到错误页。
- 重定向被长期缓存：临时跳转或维护页被缓存，源站已经恢复，边缘节点还在返回 301、302。
- HTML 页面缓存过久：列表页、详情页内容更新频繁，但缓存 TTL 设置成几小时甚至几天，蜘蛛抓到的内容滞后。
- 回源失败返回旧内容：源站超时或不可用，CDN 配置了 stale-while-revalidate 或类似策略，蜘蛛拿到过期缓存，无法判断页面是否正常。
- 缓存键忽略关键维度：没有区分 Accept-Language、Cookie、设备类型，导致不同版本互相覆盖。
- 缓存刷新依赖人工：发布内容后忘记刷新，或者刷新只清了部分节点，蜘蛛从不同节点拿到不同结果。
自查清单：从缓存规则到日志对照
1. 检查不同资源类型的 TTL
静态资源如图片、CSS、JS 可以用较长缓存，但 HTML、接口 JSON、RSS、sitemap 这类需要动态更新的资源，建议设置较短 TTL 或不缓存。至少让栏目页、详情页的缓存时间与更新频率匹配，不要一套规则套全站。
2. 检查状态码是否进入缓存
在 CDN 配置里确认 404、410、500、503 是否被缓存，缓存多久。很多 CDN 默认会缓存 404 一段时间，源站修复后边缘节点仍在返回旧状态。建议对错误状态设置短缓存或不缓存，并保留主动刷新能力。
3. 检查缓存键与 Vary 头
如果站点存在多语言、移动端独立 URL 或基于 Cookie 的内容差异，确认缓存键是否包含相应请求头。不要为了命中率把所有差异都忽略掉，否则蜘蛛可能抓到错误语言或错误设备版本。
4. 检查回源配置与源站健康
查看回源超时、重试次数、回源协议和回源 Host。回源超时太短会让源站稍慢就返回 5xx；回源 Host 配错可能拿到默认站点内容。有条件的话，在源站和 CDN 两侧都保留监控，区分是源站故障还是回源链路问题。
5. 对照 CDN 日志与源站日志
把同一时间段的 CDN 访问日志和源站日志放在一起看。重点看搜索蜘蛛的请求：CDN 返回了什么状态码、是否命中缓存、有没有回源、源站返回了什么。如果 CDN 日志里蜘蛛状态码正常，源站却没有记录，说明请求被缓存挡掉了；反过来，源站 200 但 CDN 5xx，则要查回源链路。
6. 检查 robots.txt、sitemap 和验证文件
这些文件经常被 CDN 缓存。如果 robots.txt 更新后没有及时刷新，蜘蛛可能继续按旧规则抓取。sitemap 和搜索引擎验证文件同理，建议单独设置缓存策略，发布后主动刷新并抽查节点。
日常操作建议
- 把缓存规则按资源类型分层，不要全站一个 TTL。
- 发布内容后，除了刷新页面，也检查 CDN 缓存是否同步清除。
- 对搜索蜘蛛不要做特殊内容返回，保持与用户一致，避免被判定为 cloaking。
- 监控缓存命中率、5xx 比例和回源失败率，异常时先看边缘再查源站。
- 保留一份缓存配置变更记录，出问题时能快速回滚。
CDN 不是“设好就不用管”的组件。缓存策略、回源配置和日志对照需要定期检查，尤其在改版、迁移、批量更新内容之后。把边缘节点当成站点的一部分来运营，才能减少蜘蛛拿到旧版本或错误状态码的概率。