304 Not Modified は、If-None-Match や If-Modified-Since を含む条件付きの GET または HEAD リクエストに対し、クライアントが保存しているコピーがまだ最新であることが条件から判明した場合に返されます。サーバーはリソースを再送する代わりに 304 で応答し、クライアントはキャッシュ済みのコピーを使います。これにより、帯域幅と時間を節約できます。
304 にボディが含まれることはなく、ヘッダーの後の空行で終わります。サーバーは、Cache-Control、Content-Location、Date、ETag、Expires、Vary のうち、200 を返した場合に含めていたはずのヘッダーを送信する必要があります。これによってキャッシュは、保存しているレスポンスを更新できます。
304 は 3xx の範囲にありますが、リダイレクトではありません。Location はなく、クライアントは同じ URL にとどまります。条件付きリクエストを送っていないのに 304 を受け取った場合、相手のサーバーは正しく動作していません。
レスポンス例
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 はデフォルトでは条件付きヘッダーを送信しないため、304 ではなく 200 が表示されます。再検証をテストするには、「カスタムリクエストヘッダー」に、そのページの ETag を値とする If-None-Match ヘッダーを追加してください。
よくある原因と主な用途
- ブラウザーがキャッシュ済みのページ、画像、スクリプトを
If-None-Matchで再検証し、ETagがまだ一致している場合。 - クローラーやフィードリーダーが
If-Modified-Sinceを付けて再取得し、何も変わっていなかった場合。 - デプロイ後もサーバーが 304 を返し続け、訪問者に古いコンテンツが表示される場合。バリデーターが変わっていないことが原因で、たとえばファイルサイズと更新日時から生成された
ETagが、デプロイ後もそのまま残っているケースです。コンテンツが変わったら、必ずバリデーターも変わるようにしてください。