在搜尋蜘蛛的日常抓取活動中，服務器响應狀態碼是影响抓取效率的核心因素之一。大多數站長都熟悉200和404，却容易忽略304狀態碼的價值。304表示“未修改”，它允许蜘蛛在頁面内容没有變化时直接跳過正文传輸，僅获取一個轻量級的判定结果。虽然這一机制在浏览器缓存中很常见，但正确运用于搜尋蜘蛛抓取场景，却能顯著降低带宽消耗，間接加快新URL的發現速度。
為什么304能帮助蜘蛛更快發現URL
搜尋蜘蛛的抓取资源存在上限，业界常称之為“抓取预算”。每次重复抓取一個未更新的頁面，如果服務器返回完整的200响應，蜘蛛就必须消耗下载時間和带宽。而如果服務器能依據條件請求返回304，蜘蛛便能在极短時間内判断“無需重取”，從而把节省下来的预算用于發現和抓取站内的新連結。尤其對内容更新不频繁的站点，啟用304優化後，蜘蛛每日轮询的頁面數量可能提升百分之几十。
例如：站点有1萬個頁面，每天實际更新100個。如果蜘蛛需要每天重新下载全部頁面来確認變化，成本极高。通過304，蜘蛛只需發送带有校驗头的請求，服務器返回“未修改”，則蜘蛛可以保持原有缓存並繼續爬行。這样一来，蜘蛛能在同一次抓取周期内探訪更多深层URL，這相当于間接優化了站内連結的發現效率。
條件請求的實現基础
要實現304响應，需要静態或動態頁面正确提供两種头部信息：Last-Modified和ETag。服務器在初次返回頁面内容时附带這些头，蜘蛛後續抓取时會携带If-Modified-Since或If-None-Match头，服務器通過比較時間戳或實体标簽来决定是否返回304。
- Last-Modified：頁面最後修改時間，精确到秒。蜘蛛在第二次請求时會發送If-Modified-Since，如果服務器時間未超過该時間，則直接返回304。
- ETag：一個内容哈希或版本标识符，更精确。蜘蛛使用If-None-Match头與服務器目前生成的值比較，不同則返回200，相同則返回304。
常见配置方法
在Apache中，可通過mod_headers和mod_expires設定預設缓存头，同时使用FileETag MTime Size来生成ETag。在Nginx中，預設已開啟ETag和Last-Modified，但需要確認是否被代理或CDN剥离。若使用CDN，應确保CDN节点不刪除原始响應头，並在CDN缓存規則中優先透传源站的304驗證。
對于動態頁面如PHP，可在輸出时手動設定头部。例如：
header("Last-Modified: " . gmdate("D, d M Y H:i:s", filemtime($file)) . " GMT");並在頁面處理逻辑中檢測If-Modified-Since與文件修改時間的關系，相同則返回304並登出。
注意：304响應必须不包含頁面正文，只包含狀態行和必要的头部。生成时不要計算頁面内容，否則就失去了優化效果。
配置中的常见陷阱
ETag變化導致缓存失效
多台Web服務器组成的集群，如果每台服務器基于inode或時間戳生成不同的ETag，會導致蜘蛛對同一頁面反复收到200响應。解决方案是去除ETag中的inode字段，或使用统一的基于内容哈希的ETag。在Nginx中可配置etag off，然後统一生成自定义ETag；在Apache中設定FileETag MTime Size即可。
Last-Modified缺失
很多動態頁面預設不輸出Last-Modified头，即使内容是從資料库讀取的，也可能未被正确赋值。此时蜘蛛無法發起條件請求，只能每次下载完整頁面。建议對動態頁面根據資料更新時間强制輸出Last-Modified，或使用伪静態时由重寫模块附加。
與压缩协商冲突
当服務器同时啟用Gzip时，ETag生成需考虑内容编碼。如果压缩前後ETag不同，蜘蛛可能誤判。一般建议ETag基于原始内容而非压缩後内容，並且始终返回正确的Vary: Accept-Encoding头。
如何通過日誌驗證效果
配置完成後，需要观察蜘蛛的實际响應狀態。在服務器訪問日誌中，過滤百度蜘蛛或Googlebot的UA，統計304與200的比例。如果304占比達到70%以上，說明缓存命中率高。同时，你還可以對比優化前後蜘蛛單次抓取的URL數量是否上升，以此判断URL發現效率是否改善。若日誌中没有任何304，則需检查是否缓存插件或安全软件拦截了If-Modified-Since請求。
總结
304狀態碼配置不是一項复杂工程，却常被忽略。合理运用條件請求，可以让搜尋蜘蛛以更低的成本完成重复抓取，將有限的抓取预算導向真正需要發現和更新的頁面。每個站点都可以审视日誌，確認是否让蜘蛛做了一些“無意义”的完整下载。适度優化服務器响應，不僅降低了负载，也為站内新内容的穿透提供了更多机會。從實际运营角度出發，這是一項投入小、回报稳定的基础優化手段。