为什么蜘蛛看到的页面和你看到的不一样
不少站点接入 CDN 之后会出现一种情况：浏览器访问正常，但抓取日志里同一批 URL 的响应码、响应体大小反复跳动，甚至出现 404 与 200 交替。这通常不是源站本身出了问题，而是边缘节点的缓存状态和回源策略不一致造成的。抓取工具没有浏览器那样的本地缓存和 Cookie 环境，每次请求更接近冷启动，因此它对缓存配置的差异比真人用户敏感得多。
先分清三种响应来源
- 边缘命中：节点直接返回缓存副本，响应头里通常能看到 Age 递增或命中标识。
- 回源获取：节点没有可用副本，向源站请求后再返回，同时决定是否缓存。
- 绕过缓存：命中某些规则（Cookie、查询串、特定 UA）时不缓存直接回源。
蜘蛛在不同时间、不同节点拿到的，可能是这三种中的任意一种。如果三者返回的内容不一致，比如缓存里存着旧版页面而回源返回新版，就会出现抓取结果与线上不一致的现象。
常见配置坑
1. 缓存了不该缓存的状态码
部分 CDN 默认会缓存 404、410 甚至 301，并按配置的 TTL 保留。页面恢复后，边缘仍在返回旧的 404，蜘蛛会认为该 URL 已经失效。排查时看响应头里是否有较大的 Age 值，基本就能判断。
2. 缓存键包含 UA 或完整查询串
如果缓存规则按 User-Agent 区分，或者没有忽略营销参数，同一路径会被拆成多份副本，命中率骤降，回源压力上升。抓取频次稍高时，源站就容易出现响应变慢甚至超时。
3. Set-Cookie 导致 HTML 无法缓存
页面响应带上 Set-Cookie，多数 CDN 会直接判定为不可缓存。结果是每个请求都回源，服务器负载和响应耗时的波动会更明显。
4. TTL 过短或过长
过短等于没有缓存；过长则让更新内容迟迟无法被看到，蜘蛛反复抓到的都是旧版本，容易形成抓了但不更新的错觉。
一个可执行的排查顺序
- 固定同一 URL，用不同 UA（普通浏览器、蜘蛛 UA、空 UA）多次请求，对比响应码、内容长度与 Age。
- 查看响应头中的缓存标识字段，确认这次是命中、回源还是绕过。
- 把 CDN 访问日志与源站日志按时间对齐，看回源比例是否异常偏高。
- 检查缓存键规则：是否包含 UA、Cookie、全部查询串。
- 检查是否缓存了 4xx、5xx 与 301、302，以及这些规则的 TTL 设置。
- 确认源站在高峰时段的响应耗时是否稳定，排除带宽与连接数限制。
缓存的作用是降低回源压力，而不是改变页面语义。任何让蜘蛛长期拿到与源站不一致内容的配置，都会给收录判断增加额外成本。
配置上的几个稳妥做法
- HTML 使用较短的 TTL，配合过期后被动更新的策略，兼顾新鲜度与回源压力。
- 4xx 的缓存 TTL 设置得比 200 更短，避免错误状态被长期固化。
- 缓存键忽略与内容无关的查询参数，减少副本数量。
- 不要在 CDN 层对蜘蛛 UA 做单独封禁或降级；确实需要限流时，优先按 IP 与并发维度控制。
- 改版或下线路径时，先确认边缘缓存已刷新，再观察抓取日志中的状态码变化。
观察效果时看什么
不必期待抓取量短期内有明显变化，重点看三个指标的趋势：回源请求占比是否下降、响应耗时分布是否收窄、日志中同一 URL 的状态码是否稳定。这三项稳定之后，抓取节奏通常也会更有规律。至于具体抓取频次和收录结果，由搜索引擎自行判断，站点能做的是让每次请求都拿到一致、可达的响应。