缓存头不决定收录，但会决定蜘蛛看到哪一版
在蜘蛛池场景里，入口页的主要任务是让搜索蜘蛛稳定地访问，并从页面里发现目标 URL。缓存头不会直接让页面被收录，却会改变搜索蜘蛛每次回访时拿到的是最新版本，还是 CDN 或浏览器缓存里的旧版本。入口页如果长期强缓存，新增链接可能迟迟不进入蜘蛛的解析队列。
Cache-Control 的常见写法与影响
- max-age=86400：资源在一天内被视为新鲜。如果入口页链接会频繁调整，这种设置会让部分抓取请求拿到旧内容，蜘蛛看到的新链接自然变少。
- no-cache：允许缓存，但每次使用前要向源站验证。对入口页比较友好，既能减少传输，又能让源站决定是否返回新内容。
- no-store：完全不缓存。蜘蛛每次访问都会完整拉取，源站压力更大，但内容实时性最好。适合链接变化非常频繁、且服务器能承受抓取的入口页。
- must-revalidate：过期后必须回源验证，不能使用过期副本。常与 max-age 搭配，避免过期内容被继续使用。
没有一套参数适合所有蜘蛛池。入口页更新频率、服务器承载能力和抓取频次，决定你该偏向实时还是偏向节省请求。
ETag 与 Last-Modified：条件请求的两种依据
ETag 和 Last-Modified 本身不会让蜘蛛多抓，但它们决定蜘蛛再次访问时，源站能否用 304 响应告诉它“内容没变”。如果入口页内容确实没变，304 可以节省带宽，也能让抓取预算用在其他 URL 上。但如果入口页已经新增了链接，源站却因为 ETag 生成规则不合理、Last-Modified 时间没更新而继续返回 304，蜘蛛就不会重新解析页面，新增的目标 URL 也就不会被发现。
常见问题出在动态生成的入口页：ETag 基于文件修改时间或固定字符串，内容变了但 ETag 不变；或者 Last-Modified 取的是模板时间，不是实际数据更新时间。这类情况下，蜘蛛看到的是“未修改”，实际页面已经变了。
为什么入口页不适合长期强缓存
有些运营者把入口页当作静态 HTML 放到 CDN 上，并设置很长的 max-age。这样做的好处是源站压力小，坏处是链接更新后，CDN 边缘节点仍可能返回旧版本。搜索蜘蛛如果通过不同节点访问，拿到的内容还可能不一致。入口页的核心价值在于“发现链接”，旧版本会让 URL 发现效率下降。
CDN 缓存对蜘蛛池的额外影响
使用 CDN 时，搜索蜘蛛请求的不一定是源站。CDN 的缓存策略、回源规则、Vary 响应头都会影响最终返回内容。如果 Vary 设置得太宽，或者按 User-Agent 返回不同页面，缓存系统可能把蜘蛛的请求和普通用户请求混在一起。排查时不要只看源站日志，也要看 CDN 的缓存命中情况和回源日志。
一个相对稳妥的入口页缓存配置思路
- 入口页优先使用 Cache-Control: no-cache 或较短的 max-age，例如 60 到 300 秒，让内容变化能较快传递。
- 保留 ETag 和 Last-Modified，但确保它们随内容变化而更新，不要用固定值。
- 如果入口页链接更新频繁，可以测试 no-store，同时观察源站负载和蜘蛛抓取频次。
- CDN 上对入口页单独设置缓存规则，避免被其他静态资源的长缓存策略覆盖。
- 修改缓存头后，用抓取工具或日志观察蜘蛛回访时拿到的状态码和内容版本。
缓存头是抓取效率的调节器，不是收录开关。把入口页当成会变化的页面来配置，通常比当成静态文件更符合 URL 发现的需要。
排查时看什么
如果新增目标 URL 后搜索蜘蛛长时间没有反应，可以先看入口页的响应头：Cache-Control 是否设置了很长的新鲜期，ETag 是否在内容变化后仍然相同，CDN 是否返回了旧版本。再对比源站日志和 CDN 日志，确认蜘蛛请求到底命中了哪里。多数情况下，调整缓存策略后需要一段时间观察，不要期待立即变化。