为什么入口页值得单独看 CDN 和缓存
蜘蛛池的入口页通常有几个共同特点：数量多、域名分散、单页内容不复杂、更新频率不高。这些特点决定了它对服务器压力的敏感程度，也决定了 CDN 和缓存能发挥多大作用。蜘蛛抓取一个入口页时，先要完成解析、建连、握手，然后才是拿到响应内容。如果每个请求都回源到源站，源站要处理的并发就会随入口页数量上升，超时、5xx、响应变慢的概率也会跟着变大。
CDN 在这里的作用不是“加速排名”，而是把重复请求拦在离蜘蛛更近的节点上，让源站只处理真正需要回源的那部分。对入口页来说，这是一层稳定性保障，而不是效果手段。
命中率、回源与抓取稳定性
缓存命中率和抓取成功率之间是间接关系，可以这样理解：
- 命中率高，源站压力小，响应时间稳定，蜘蛛在不同时间拿到的状态码更一致；
- 命中率低，回源频繁，源站一旦扛不住就会吐 5xx，同一批入口页的可用性会明显波动；
- 但如果缓存把偶发的错误状态码也存住，反而会在一段时间内持续对外输出错误结果。
所以目标不是把命中率做到最高，而是命中率高、错误缓存少、回源可控。
Cache-Control 与响应头的基本配置
入口页内容一般不需要秒级更新，比较常见的做法是：
- Cache-Control：给一个中等长度的 max-age，同时用 s-maxage 单独控制节点缓存时间，两者分开便于后续调整；
- 不要用 no-store：入口页一旦设成 no-store，每次抓取都回源，相当于自己把 CDN 关掉；
- Vary 头要谨慎：如果 Vary 里带上 User-Agent，节点缓存会被拆成很多份，命中率骤降，输出也会不稳定；
- 错误状态码：5xx 建议短缓存或不缓存，避免一次抖动被放大成持续不可用。
回源环节最容易出问题的地方
- URL 里带随机参数或时间戳，每个请求都是新地址，缓存永远不命中，等于直连源站；
- 回源超时设置过短，源站稍慢一点就返回 502，蜘蛛看到的是错误页；
- 源站返回 200 但内容是错误提示页，蜘蛛会当成正常页面处理；
- 同一域名一部分走 CDN、一部分直连，线路不一致，抓取结果也可能不一致。
要不要按蜘蛛 UA 做特殊处理
有些做法是识别到搜索蜘蛛就强制回源，或者绕过缓存返回一份“专门给蜘蛛看的版本”。这两类操作风险都不低：
- 强制回源：等于把 CDN 对蜘蛛屏蔽，源站压力集中在这部分请求上；
- 返回不同内容：和普通访客看到的差异过大时，容易被认为是作弊，入口页本身也可能因此失去价值。
更稳妥的做法是让蜘蛛和普通访客走同一套缓存与内容逻辑，只在日志层面区分，用来观测抓取情况。
几个常见误区
- 以为上了 CDN 收录就会变好：它只影响可访问性和响应速度，不影响内容质量；
- 缓存时间拉得很长却频繁改内容：蜘蛛拿到的还是旧版本，更新迟迟不生效；
- 整站开缓存却忘了排除后台或接口路径，导致数据错乱；
- 只测了浏览器访问，没测蜘蛛 UA 和不同节点的返回结果。
入口页的 CDN 配置，先保证稳定、可预期，再谈快不快。
一份可执行的检查清单
- 确认入口页状态码在节点与源站一致，都是 200；
- 给 HTML 设置合理的 max-age 与 s-maxage，避免 no-store；
- 检查 Vary 头，避免因 UA 把缓存拆散；
- 统一 URL，去掉无意义的随机参数；
- 5xx 短缓存，4xx 按语义处理；
- 回源超时给足，避免源站稍慢就报错；
- 用不同节点、不同 UA 各测一次，确认返回内容一致；
- 保留日志，观察回源比例与错误率的变化。
这些配置不会直接带来收录或排名，但能把入口页的可用性做扎实，减少因访问层问题导致的抓取失败。最终效果仍然取决于内容、结构和目标页本身。