搜索蜘蛛对已经抓取过的 URL 通常会安排回访。为了减少重复传输，蜘蛛在回访时会带上 If-None-Match 或 If-Modified-Since 请求头，询问页面是否发生变化。如果服务器能正确返回 304，蜘蛛只需确认“没有更新”，不必再次下载完整正文；如果响应头或缓存策略异常，蜘蛛可能每次都拿到 200 和完整内容，造成回访抓取空转，挤占有限的抓取预算。
条件请求在抓取回访中起什么作用
可以把条件请求理解为一次轻量确认。蜘蛛首次抓取后会保存响应的 ETag 或 Last-Modified。下次访问时，它把这些值放回请求头。源站如果判断资源未变，返回 304 Not Modified，并允许不带正文；如果已变，则返回 200 和新内容。这个过程对站点运营的价值在于：减少服务器带宽消耗，也让蜘蛛把时间花在真正更新的 URL 上。
容易造成空转的几种响应异常
- 始终返回 200：源站不识别条件请求头，无论内容是否变化都重新输出完整页面。
- ETag 不稳定：ETag 中包含时间戳、随机串或每次请求都变化的进程 ID，导致蜘蛛每次拿到的标识都不同。
- 304 响应头缺失：返回 304 却没有配套的 ETag，或状态码写成 200 但正文为空，蜘蛛难以判断抓取结果。
- CDN 与源站不一致：边缘节点返回一套缓存头，回源后又拿到另一套 Last-Modified，造成版本判断混乱。
- Vary 头缺失：同一 URL 因 User-Agent、Accept-Encoding 返回不同内容，缓存系统却按同一版本处理。
排查顺序与核对方法
- 先挑选更新频率不同的页面，分别用 curl -I 请求，记录首次响应的 ETag、Last-Modified 和 Cache-Control。
- 带上首次拿到的 If-None-Match 或 If-Modified-Since 再次请求，观察是否返回 304；如果返回 200，检查响应正文长度是否与首次一致。
- 对同一 URL 连续请求多次，确认 ETag 是否保持不变。若每次变化，需要检查生成逻辑。
- 分别直连源站和经过 CDN 请求，比较两边的响应头，尤其是 Age、Via、X-Cache 等字段。
- 在服务器访问日志中查看蜘蛛回访时返回的状态码分布，确认 304 占比是否合理。
修复与配置建议
优先让源站输出稳定的验证标识。对静态文件，可用文件修改时间或内容摘要生成 ETag；对动态页面，如果内容由数据库和模板共同决定，可以用影响输出的字段更新时间生成 Last-Modified。确认未变化时，返回 304 并且不发送正文。CDN 侧要统一缓存策略，避免边缘节点把不同版本混在一起。
需要提醒的是，304 不是“少抓取”的技巧。如果页面内容已经变化却仍返回 304，蜘蛛会继续使用旧版本，反而影响 URL 发现和内容更新。条件请求的目标是准确反映变化，而不是隐藏变化。
与 Sitemap 和内链发现的关系
Sitemap 的 lastmod 和页面响应头应尽量一致。若 Sitemap 声明某页近期更新，但服务器回访时一直返回 304，蜘蛛可能降低对该 Sitemap 时间戳的信任。内链结构则决定蜘蛛能否稳定到达这些 URL；即使缓存头配置正确，入口本身抓不到也无法完成回访。因此排查顺序通常是：先确认 URL 可发现，再确认服务器可达，最后核对条件请求和缓存头是否让回访有效。
抓取预算不是靠单一响应头节省出来的，而是入口发现、服务器稳定性和内容更新信号共同作用的结果。条件请求配置正确时，它只是让回访更准确，不会自动提升收录或排名。