搜尋蜘蛛對已经抓取過的 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 可發現，再確認服務器可達，最後核對條件請求和缓存头是否让回訪有效。
抓取预算不是靠單一响應头节省出来的，而是入口發現、服務器稳定性和内容更新信号共同作用的结果。條件請求配置正确时，它只是让回訪更准确，不會自動提升收錄或排名。