304 Not Modified 用於回應條件式的 GET 或 HEAD 要求（也就是帶有 If-None-Match 或 If-Modified-Since 的要求），在條件顯示用戶端儲存的副本仍是最新版本時傳送。伺服器不會再次傳送資源，而是回應 304，讓用戶端使用快取中的副本，藉此節省頻寬與時間。
304 永遠沒有回應主體，會在標頭之後的空白行結束。在 Cache-Control、Content-Location、Date、ETag、Expires 與 Vary 這些標頭中，凡是 200 回應原本會包含的，伺服器都必須一併傳送，讓快取能夠更新已儲存的回應。
雖然 304 位於 3xx 範圍，但它並不是重新導向。回應中沒有 Location，用戶端也會停留在同一個網址。如果用戶端沒有送出條件式要求卻收到 304，代表對方的伺服器有問題。
回應範例
HTTP
HTTP/1.1 304 Not Modified
Date: Fri, 06 Nov 2026 10:15:32 GMT
ETag: "5f2b-1a3c"
Last-Modified: Wed, 28 Oct 2026 08:02:11 GMT
Cache-Control: public, max-age=600
Vary: Accept-EncodingSEO 與重新導向檢查
304 有助於檢索。Google 的檢索器支援條件式要求，而 304 會告訴 Googlebot 內容自上次檢索以來沒有變更。這能節省檢索容量與伺服器負載，網頁在索引中的位置也不受影響，因此值得提供可靠的 ETag 或 Last-Modified 標頭，大型網站尤其如此。
TrueURL 預設不會傳送條件式標頭，因此您看到的會是 200 而不是 304。若要測試重新驗證，請在「自訂要求標頭」中加入帶有該網頁 ETag 的 If-None-Match 標頭。
常見原因與使用情境
- 瀏覽器以
If-None-Match重新驗證快取中的網頁、圖片或指令碼，而ETag仍然相符。 - 爬蟲或訂閱閱讀器以
If-Modified-Since再次擷取，而內容沒有任何變更。 - 部署之後訪客看到的仍是舊內容，因為伺服器持續回應 304：它的驗證器沒有改變，例如以檔案大小和修改時間產生的
ETag，而部署過程保留了這兩項資訊。請確保內容變更時，驗證器也會跟著改變。