蜘蛛不是只来一次。一個 URL 被發現後，會在一段時間内被反复訪問。但反复訪問不等于反复完整下载。很多搜尋引擎蜘蛛在第二次、第三次訪問时，會先發一個條件請求，询問服務器内容有没有變化。理解這段交互，能减少不必要的传輸，也能避免让蜘蛛誤判頁面更新频率。
條件請求是怎么發出来的
当蜘蛛第一次抓取某個 URL 时，服務器通常在响應头里带上 Last-Modified 或 ETag。下次蜘蛛再訪問同一個 URL 时，請求头里就可能出現：
- If-Modified-Since：對應 Last-Modified，告诉服務器“我上次抓到的時間是這個”。
- If-None-Match：對應 ETag，告诉服務器“我上次拿到的标识是這個”。
服務器收到後，可以判断内容是否變化。如果没變，返回 304 Not Modified，正文不传輸；如果變了，返回 200 和新的正文。
304 對蜘蛛意味着什么
304 不是“不抓取”，而是一次有效的訪問记錄。蜘蛛確認 URL 可訪問、狀態正常，但不需要重新下载和解析正文。對站点来说，這能减少带宽和服務器压力；對蜘蛛来说，也能把省下的传輸時間用在其他 URL 上。
把 304 当成“拒绝抓取”是一種誤解。它只是告诉蜘蛛：内容没變，不用再传一遍。
配置时容易踩的坑
Last-Modified 不稳定
有些程序在每次請求时動態生成 Last-Modified，或者时区處理不對，導致每次返回的時間都不一样。蜘蛛會以為頁面一直在更新，于是反复完整抓取，反而增加消耗。
ETag 每次都變
部分框架會用文件 inode、進程 ID 或随机值拼 ETag。同一份内容在不同請求里得到不同 ETag，條件請求就永遠對不上，304 也就無法生效。
CDN 與源站响應头不一致
如果源站返回了稳定的 ETag，但 CDN 层又覆盖或剥离了相關头，蜘蛛在不同時間可能看到不同版本。需要確認最终到達客戶端的响應头是否稳定。
和抓取预算的關系
304 能节省传輸，但不會凭空增加蜘蛛的抓取配額。蜘蛛仍然要為這次訪問排队、建连、等待响應。真正影响抓取量的，還是 URL 發現是否充分、站点响應是否稳定、抓取路径是否清晰。條件請求更像是锦上添花：让重复訪問更轻，而不是让蜘蛛来得更勤。
一個简單的检查清單
- 用 curl -I 连續請求同一個 URL，观察 Last-Modified 和 ETag 是否稳定。
- 在日誌里統計 304 的比例。如果長期為零，可以检查是否响應头配错或被中間层改掉。
- 確認 404、410 等失效頁面不要返回 304，避免蜘蛛誤以為它們仍然有效。
- 對需要實时更新的頁面，不要强行長期返回 304；對稳定頁面，則适合让缓存头正常工作。
條件請求不是抓取優化的核心，但它属于服務器與蜘蛛之間最基础的對话。把响應头配稳，蜘蛛重复来訪时就能少下载、少折腾，站点也能把资源留给更需要的請求。