304 Not Modified（変更なし）

TL;DR — 304 Not Modified レスポンスは、サーバーが「you already have this — your copy is still good, don’t download it again.」 (翻訳)「すでに持っているので、そのコピーはまだ有効で、もうダウンロードしなくてよい」と伝える方法です。エラーではありません。3xxの「リダイレクト」ファミリーに属していても、誰も新しいURLへ送ることはありません。クライアント（ブラウザーやクローラー）が最初に「前回から変わったか」と尋ねる条件付きリクエストを送った場合にだけ発生します。SEO上、ランキングを動かすものではありませんが、大規模サイトでは検索エンジンがリソースをより効率的に使う助けになります。

304とは何か

サーバーが返すすべてのレスポンスは、3桁のステータスコードで始まります。200 OKは「here’s the page, body and all.」 (翻訳)「これがページです。ボディもすべて含まれます」という意味です。304 Not Modifiedは、より具体的な意味を持ちます。クライアントが条件付きリクエスト――「このページを返してほしい。ただし変更されている場合だけ」というリクエスト――を行い、サーバーが変更されていないと判断したため、本来なら返したはずの200の代わりに、ボディなしの304を返します。これが実際のルールです。304は、条件が偽になった条件付きGET/HEADへの応答としてのみ返されます。

そうなる典型例が2回目の訪問です。ブラウザーやクローラーが初めてページを取得すると、完全なコンテンツを持つ通常の200に、いくつかの小さな「指紋」ヘッダーが加わって返ります。次の訪問で、クライアントはその指紋をサーバーに示し、「still the same?」 (翻訳)「まだ同じですか？」と尋ねます。何も変わっていなければ、サーバーは304を返してページボディを送らず、クライアントは手元にあるコピーを再利用します。ただし「2回目の訪問」は例であってプロトコルのルールではありません。304を発生させるのは条件付きリクエストそのものであり、どのように届いたかは問いません。 Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

「リダイレクト」ファミリーに属してもリダイレクトではない理由

304は3で始まります。HTTPがリダイレクトに使うクラスです。そのため、常に人を混乱させます。しかし304には**Locationヘッダーがなく**、別のアドレスへ送ることもありません。誰もどこへも移動しません。クライアント自身が保存したコピーを使うよう指し示すだけです。つまり「redirect family」 (翻訳)「リダイレクトファミリー」は番号付け上の事情であり、動作を表しているわけではありません。

304は問題か

いいえ。ブラウザーのNetworkタブやクロールレポートで304が見えるのは、キャッシュが動作しているサインです。まさに望ましい状態です。世の中には「304 error, how to fix it」 (翻訳)「304エラーをどう直すか」という助言があり、手元で何かが壊れているように扱うものも多いですが、そうではありません。適切に動作するキャッシュが返す、正しく意図された結果です。

SEOに役立つか

ランキングに直接は影響しません。Googleは前回ページをクロールしたときのコンテンツをすでに持っています。304は変更されていないことを確認するだけなので、Googleは保存済みの内容を使い続けます（SearchがURLのシグナルを再計算することはありますが、304自体がランキングやインデックスのボーナスになるわけではありません）。304が役立つのはリソース効率です。検索エンジンが変更されていないページを再ダウンロードせずに済めば、両端の帯域幅と計算資源を節約できます。Googleは、これによりクロールが間接的に効率化する可能性があると説明していますが、節約した処理が新規または更新ページへ自動的に振り向けられる保証ではありません。ページ数が多く、めったに変更されないURLが多い大規模サイトで特に意味があります。

実際の仕組み――ETag、If-None-Match、強い／弱いバリデーター、実装方法、Googleが実際に述べたこと――を知りたいなら、Advancedタブに切り替えてください。

TL;DR — 304は、条件が偽と評価され、本来なら200になっていた条件付きGET/HEADへのレスポンスです（RFC 9110 §15.4.5）。3xxクラスですがリダイレクトではありません。Locationも新しいURLもなく、規範上ボディもありません（「it cannot contain content or trailers」 (翻訳)「コンテンツやトレーラーを含めることはできない」）。条件はIf-None-Match（ETagと照合）および／またはIf-Modified-Since（Last-Modifiedと照合）で運ばれます。バリデーターがまだ一致すると、サーバーは304を返し、クライアントはキャッシュを再利用します。SEOへの影響は直接的なランキング効果なしです。Googleはすでにコンテンツを持っていますが、SearchがURLのシグナルを再計算することはあります。大規模サイトではリソースを節約でき（Googleはクロール効率を間接的に改善する可能性があると述べています）、クロールバジェットが他のURLへ自動再配分されることまでは約束していません。Googleのクロール基盤は両方のバリデーターに対応し、日付形式の落とし穴がないETagを第一選択として推奨しています。301/302/307/308（URLを移動させる）や204（送るものが本当にないためボディなし）と区別してください。

仕様上の304の意味

RFC 9110（HTTP Semantics）§15.4.5は、304を正確に定義しています。「The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.」 (翻訳)「304（Not Modified）ステータスコードは、条件付きGETまたはHEADリクエストを受信し、条件が偽と評価されなければ200（OK）レスポンスになっていたことを示す」。これが規範上の実際のトリガーです。条件が偽になり、本来なら200になった条件付きGET/HEADです。平たく言えば、クライアントは「変更された場合だけこのページを返して」と要求し、サーバーは変更されていないと判断したためボディ送信を省略します。「2回目の訪問」はリクエストが条件付きになる日常的な例です（以前のレスポンスから保存したバリデーターをクライアントが添付します）が、教えやすい例であってルールではありません。仕様は前回訪問を要求せず、条件付きリクエストだけを要求します。 Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

仕様はこの節で「redirecting」という語も使っています。「the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response」 (翻訳)「したがってサーバーは、保存された表現を200（OK）レスポンスのコンテンツであるかのように利用するよう、クライアントをリダイレクトしている」とあります。しかし注意深く読むと、クライアントを別URLへではなく、自身のキャッシュへ戻しています。Locationヘッダーも新しいアドレスもありません。304が「リダイレクトか」をめぐる混乱の大半はこの一文が原因です。HTTPの意味ではリダイレクトではありません。

規範上、さらに2点が重要です。

• ボディは絶対にない。 RFC 9110は「A 304 response is terminated by the end of the header section; it cannot contain content or trailers.」 (翻訳)「304レスポンスはヘッダーセクションの終わりで終了し、コンテンツやトレーラーを含めることはできない」としています。ボディを送る304は仕様違反であり、一部のクライアントは誤動作します。これはスタイルの好みではなく、厳格なルールです。
• 200と同じメタデータを運ぶ。 サーバーは「MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary,」 (翻訳)「同じリクエストへの200（OK）レスポンスで送られたはずの次のヘッダーフィールドを生成しなければならない：Content-Location、Date、ETag、Vary」。該当する場合はCache-ControlとExpiresも加わります。304はペイロードを除いた200のヘッダーです。

304の実際の動作：条件付きリクエスト

サーバーが突然304を送ることはありません。必ず条件付きリクエストへのレスポンスです。これはクライアントが、以前のレスポンスから保存したバリデーターを添付して条件付きにしたリクエストです。バリデーターは2種類あります。

ETagとIf-None-Match

ETag（エンティティタグ）は、サーバーが200レスポンスに付ける不透明なトークンです。URLのその表現そのものに対するバージョン指紋だと考えてください。次にそのURLをリクエストすると、クライアントは保存した値をIf-None-Matchヘッダーで送り返します。サーバーが比較し、現在のETagがまだ一致すれば何も変わっていないため304を返します。一致しなければ、新しいコンテンツと新しいETagを持つ新鮮な200を返します。

Last-ModifiedとIf-Modified-Since

日付を使う代替方法では、サーバーが200に**Last-Modified**タイムスタンプを付けます。次回、クライアントはそれをIf-Modified-Sinceヘッダーで送り返し、サーバーが日付を比較します。そのタイムスタンプ以降にリソースが変更されていなければ、304です。これは単純ですが粗く（タイムスタンプの粒度にしかなりません）、正確なHTTP-date形式に敏感で、バグの一般的な原因です。両方のバリデーターがある場合は、If-None-Match（ETag）がIf-Modified-Sinceより優先されます。

強いETagと弱いETag

ETagには強いものと弱いものがあり、その違いは重要です。MDNの条件付きリクエストの説明によれば、「strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.」 (翻訳)「強い検証とは、リソースが比較対象とバイト単位で同一であることを保証する」です。弱いETagにはW/が付く（例：ETag: W/"abc123"）ため、意味上の同等性だけを示します。MDNの例では、「a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation.」 (翻訳)「フッターの日付や広告だけが異なるページは、弱い検証では他方と同一とみなされる」。強いETag（接頭辞なし）はバイト単位の一致が必要な範囲リクエストなどで必要です。圧縮、空白、実体のない軽微な差で全再取得を強制したくない場合は弱いETagが有用です。実務上の落とし穴は、コンテンツをgzip/Brotliで再圧縮するたびにETagが変わったり、負荷分散サーバー間で変化したりすると、不要な再クロールを引き起こすことです。強いか弱いかを意図的に選び、本当に変わっていないコンテンツでは値を安定させてください。

完全なハンドシェイクを手順で見る

1. 最初のリクエスト → サーバーがコンテンツとETagおよび／またはLast-Modifiedを付けた200 OKを返す。
2. クライアントが保存 → コンテンツとバリデーターを保存する。
3. 次のリクエスト → クライアントが保存済みの値とともにIf-None-Matchおよび／またはIf-Modified-Sinceを送る。
4. サーバーが判断： 変更なし → ボディなしの304 Not Modifiedを返し、クライアントはキャッシュを再利用する。変更あり → 新しいボディと新しいバリデーターを持つ200 OKを返す。 Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

キャッシュとバリデーターをクロール効率の手段として詳しく扱う内容――条件付きリクエスト全体とクロールバジェットとの関係――は別の関連記事に譲ります。この記事はステータスコードに焦点を当てた内容です。

304とSEO：ランキング効果はないが、クロール効率には実効性がある

SEOについての全体像は、ブログの定型文が示すより狭いものです。304に直接的なランキング効果はなく、ステータスコードがクロールとインデックスに与える影響についてGoogle自身の説明も、インデックスへの効果を限定しています。SearchがURLのシグナルを再計算することはありますが、それ以外では304はページのインデックス方法を変えません。Googleは前回クロール時のコンテンツをすでに持っています。304は何も変わっていないことを確認するだけなので、持っているものを使い続けます。304を返してもランキングボーナスはありません。

304が実際にもたらすのは、クロール効率を間接的に改善できるリソース節約です。Googleの2024年12月のSearch Centralブログ記事「HTTP caching」で、Gary Illyesは次のように明確に述べています。「Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.」 (翻訳)「個別URLのコンテンツがめったに変わらない大規模サイトでは、ローカルキャッシュを許可するとサイトがより効率的にクロールされる可能性があります。Googleのクロール基盤はHTTPキャッシュ標準で定義されたヒューリスティックなHTTPキャッシュをサポートし、具体的にはETagレスポンス／If-None-Matchリクエストヘッダーと、Last-Modifiedレスポンス／If-Modified-Sinceリクエストヘッダーを通じて行います。」

同じ記事は、304の正確な仕組みについて、空のボディがなぜ要点なのかを明記しています。クローラーが送ったETagが「matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body,」 (翻訳)「サーバーが生成した現在の値に一致するなら、サーバーはHTTPボディなしのHTTP 304（Not modified）ステータスコードを返すべき」となった場合、「no HTTP body」 (翻訳)「HTTPボディなし」が重要なのは、「your server doesn’t have to spend compute resources on actually generating content」 (翻訳)「サーバーがコンテンツ生成に計算資源を使う必要がなく」、さらに「doesn’t have to transfer the HTTP body」 (翻訳)「HTTPボディを転送する必要もない」からです。両端の計算と帯域幅を節約できます。下流の効果についてGoogle自身の表現は条件付きです。そのリソース節約がクロール効率を間接的に改善する可能性があります。節約した処理が新規または更新URLへ自動的に再配分されるとは約束していないため、妥当ではあるものの保証されない波及効果を持つリソース節約の仕組みとして扱ってください。

大規模サイトで重要になる理由

数百ページ程度なら、これはほぼ理論上の話です。Googleはどちらにせよサイト全体を問題なくクロールできます。規模に応じて効果は大きくなります。数十万、数百万のURLがあり、その多くがめったに変更されないサイトでは、クローラーが変更のないページの再取得を省けるため、実質的な恩恵があります。Googleの記事はこの読者を想定しており、304を小規模サイト向けの施策として誇張しないのが正直な説明です。

ETagかLast-Modifiedか、そして「変更」の意味

GoogleはETagを第一のバリデーターとして推奨しています。「We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).」 (翻訳)「ETagはLast-Modifiedの値と違って構造化されておらず、エラーやミスが起きにくいため、強く推奨します」。両方を設定するのは問題なく、推奨もされています。Last-Modifiedを使う場合、日付は「must be formatted according to the HTTP standard」 (翻訳)「HTTP標準に従ってフォーマットしなければならない」とされます。Googleが推奨する形式は「Weekday, DD Mon YYYY HH:MM:SS Timezone,」 (翻訳)「曜日、DD Mon YYYY HH:MM:SS タイムゾーン」です。例は「Fri, 4 Sep 1998 19:15:56 GMT」 (翻訳)「Fri, 4 Sep 1998 19:15:56 GMT」で、そうしないと黙って無視される可能性があります。Googleは、クローラーが再クロール時期を判断しやすいよう、Cache-Controlのmax-ageフィールドを設定することも勧めています。

キャッシュを無効にする価値のある変更を何とするかは、あなたが決めます。Googleの助言は実体のある変更に限定することです。「Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.」 (翻訳)「コンテンツに重要な変更があった場合にキャッシュ更新を要求することを推奨します。ページ下部の著作権日付だけを更新したなら、おそらく重要ではありません。」

GooglebotとBingbotが実際にどう扱うか

すべてのクローラーリクエストが条件付きになるわけではありません。Googleのクローラー文書によれば、個々のGoogleクローラーやフェッチャーは、提供するプロダクトによってキャッシュ対応が異なります。GooglebotはSearch向けにURLを再クロールするときのキャッシュに対応しますが、他のGoogleフェッチャーは特定の条件でのみ対応する場合があります。そのため、ヘッダーを正しく設定しても、100%のリクエストにIf-None-Match/If-Modified-Sinceが付くとは考えないでください。Bingについても、条件付きリクエストはGoogleだけの機能ではありません。Bingのクローラーは、少なくとも2008年のLive Searchブログ記事以来、条件付きGET（If-Modified-Sinceと、利用できる場合はIf-None-Matchを送信し、コンテンツが変わっていなければ304を受け入れる）に対応しています。ただし、BingはGoogleの2024年記事に相当する最新の説明を公開していません。仕組みは両検索エンジンに適用される一般的なHTTP動作として扱ってください。

304対応を実装する方法

1. 200でバリデーターを送る。 サーバー、CDN、アプリを設定し、通常の200レスポンスにETag（推奨）および／または正しくフォーマットしたLast-Modifiedヘッダーを付けます。多くのサーバーやフレームワークは静的ファイルのETagを自動で付けますが、動的レスポンスでは通常、明示的な設定が必要です。
2. 条件付きヘッダーを受信時に尊重する。 リクエストにIf-None-Match/If-Modified-Sinceが付いてきたら、現在のバリデーターと比較し、一致する場合は（ボディなしの）304、一致しなければ新しい200を返します。静的ファイルサーバーはこれを処理することが多い一方、アプリのルートやエッジワーカーでは接続しない限り処理しないことがよくあります。
3. 「変更」の意味を決める。 本当に変わっていないコンテンツでETagを安定させ、再圧縮やサーバーごとの差で不必要に変えないようにします。
4. 典型的な設定ミスを監視する：
   • 常に200 — バリデーターを一度も出さないため、条件付きリクエストが発生せず、効率化の恩恵も得られない。
   • 不安定なETag — コンテンツが変わっていないのに値が変わる（ロードバランサー、再圧縮など）ため、常に再取得を強いる。
   • 古い304 — 危険なものです。コンテンツが実際に変わった後もサーバーが304（または変わらないETag）を返し続け、クローラーとキャッシュが更新を取得できない。ログ分析で捕捉すべきバグであり、304固有の欠陥ではありません。

304と他のステータスコードの違い

304と301／302／307／308

それらが実際のリダイレクトです。301/308（恒久的）または302/307（一時的）はLocationヘッダーを持ち、クライアントを別のURLへ移動させます。301/308は正規化シグナルも渡します。304にはLocationがなく、誰も移動せず、ランキングシグナルも渡しません。同じ3xxファミリーでも番号が同じだけで、役割はまったく異なります。コード別リダイレクトの詳しい説明は各記事にあります（301 redirectの記事とリダイレクトサブハブを参照）。

304と204 No Content

どちらもボディなしですが、理由は完全に異なります。204 No Contentは、サーバーに本当に送るものがないため意図的に空のボディを返す2xx成功です。成功したAPIのDELETE/PUTや、アナリティクスビーコンなどが該当します。304もボディを送りませんが、送るものがないからではなく、「you already have it and it’s still valid.」 (翻訳)「すでに持っていて、まだ有効だから」です。混同しないでください。ページURLの204はインデックス可能なコンテンツがないためソフト404のように扱われることがありますが、304はGoogleがすでに持っているコンテンツの有効性を確認するものです。このコードの全体像は204 No Contentの記事で説明しています。

304に関するよくある誤解

1. 「304 is a redirect.」 (翻訳)「304はリダイレクトだ」。Locationヘッダーはなく、誰も移動しません。クライアントは自分のキャッシュコピーを再利用します。RFC 9110の「保存された表現を利用するようクライアントをredirecting」という表現は、別URLではなくキャッシュを指しています。
2. 「304 is an error I need to fix.」 (翻訳)「304は修正が必要なエラーだ」。動作する条件付きリクエスト設定が返す、正しく意図された結果です。クロールやDevToolsで304が見えるのは、キャッシュが動作しているサインです。SERPで最も一般的な誤解の1つです。
3. 「304 helps rankings.」 (翻訳)「304はランキングに役立つ」。直接的なランキング効果はなく、Googleはインデックスへの効果も限定しています。SearchがURLのシグナルを再計算することはありますが、304はそれ以外のインデックス方法を変えません。効果はGoogleが大規模サイトでクロール効率を間接的に改善する可能性があると述べるリソース節約であり、ランキングシグナルでも、節約分が他のURLへ移る保証でもありません。
4. 「If my server returns 304, Google will use stale content forever.」 (翻訳)「サーバーが304を返すと、Googleは古いコンテンツを永久に使う」。バリデーターが一致している間だけ304が返ります。コンテンツが実際に変わった瞬間、正しく実装されたサーバーは新しいバリデーター付きの新しい200を返します。本当のリスクは、コンテンツ変更後も304を返し続ける設定ミスのサーバーです。304の性質ではなく、バグです。 Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. 「ETag and Last-Modified are interchangeable.」 (翻訳)「ETagとLast-Modifiedは互換可能だ」。両方ともバリデーターですが、Last-Modifiedは日付形式に敏感でタイムスタンプの粒度までしかなく、ETagは不透明で正確です（不注意な実装ではサーバー間や再圧縮後に扱いにくく変化することがあります）。GoogleはETagを第一選択として推奨し、可能なら両方を使うよう勧めています。

FAQ

HTTP 304はエラーですか？ いいえ。キャッシュが動作していることを示す成功シグナルです。クライアントのキャッシュコピーがまだ有効だという意味です。

304 Not Modifiedはリダイレクトですか？ いいえ。番号上は3xxクラスですが、Locationヘッダーがなく、クライアントを新しいURLへ移動させません。

304はSEOやランキングに役立ちますか？ 直接的なランキング効果はなく、GoogleがURLのシグナルを再計算する可能性を除けば、インデックスへの効果もありません。変更されていないページをクローラーがスキップできるため帯域幅と計算資源を節約し、Googleが言うように大規模サイトのクロール効率を間接的に改善する可能性があります。

ETagとLast-Modifiedの違いは何ですか？ ETagはIf-None-Matchで照合する不透明なバージョン指紋です。Last-ModifiedはIf-Modified-Sinceで照合するタイムスタンプです。Googleはエラーが起こりにくいETagを推奨しています。

弱いETagと強いETagとは何ですか？ 強いETagはバイト単位で同一のコンテンツだと示します。W/が接頭辞に付く弱いETagは、圧縮やフッター日付の変更など軽微な差を許容した意味上の同等性を示します。

ログやクロールレポートで304sが見えるのはなぜですか？ クライアントが条件付きリクエストを行い、サーバーがコンテンツに変更がないことを正しく確認しているからです。期待される、良い状態です。

サーバーに304を正しく返させるには？ 200でETag/Last-Modifiedを送り、次のリクエストのIf-None-Match/If-Modified-Sinceを尊重します。バリデーターが一致したら、ボディなしの304を返します。

304と204の違いは？ どちらもボディなしです。204は送るものがないため、304はすでに有効なコピーを持っているためボディがありません。

Googlebotはすべてのリクエストで条件付きヘッダーを送りますか？ いいえ。キャッシュ対応はクローラーによって異なるため、ヘッダーを設定していてもすべてのリクエストが条件付きになるわけではありません。

304レスポンスはボディを持てますか？ いいえ。RFC 9110によれば「it cannot contain content or trailers.」 (翻訳)「コンテンツやトレーラーを含めることはできません」。ボディ付きの304は仕様違反です。

AIによる要約

Advanced版の要点をまとめると、次のとおりです。

• 304 Not Modifiedは、条件が偽と評価され、本来なら200になっていた条件付きGET/HEADへのレスポンスです（RFC 9110 §15.4.5）。3xxクラスですがリダイレクトではありません。Locationヘッダーも新しいURLもなく、規範上ボディもありません。「it cannot contain content or trailers.」 (翻訳)「コンテンツやトレーラーを含めることはできない」。2回目の訪問はリクエストが条件付きになる典型例であり、プロトコルのルールではありません。
• 条件付きリクエストへの応答です。 If-None-Match（ETagと照合）および／またはIf-Modified-Since（Last-Modifiedと照合）を持つGET/HEADです。バリデーターが一致すれば、サーバーは304を返し、クライアントはキャッシュコピーを再利用します。
• 仕様の「redirecting」は比喩です。 クライアントを別URLではなく自身のキャッシュへ戻します。この一文が「304はリダイレクトか」という混乱の大半を生みます。
• ETagとLast-Modified： ETagはIf-None-Matchで照合する不透明なバージョントークン、Last-ModifiedはIf-Modified-Sinceで照合する日付です。正確なHTTP-date形式が必要です。両方ある場合はIf-None-Matchが優先されます。強いETagはバイト同一、弱いETag（W/接頭辞）は意味上の同等性です。
• 直接的なランキング効果はなく、GoogleがURLのシグナルを再計算する可能性を除けばインデックスへの効果もありません。 Googleはすでにコンテンツを持ち、304は変更がないことを確認するだけです。Gary Illyesの表現では、キャッシュは「may help your site be crawled more efficiently」 (翻訳)「サイトがより効率的にクロールされる助けになる」可能性があります。大規模サイトでのリソース節約がクロール効率を間接的に改善する可能性であって、クロールバジェットの再配分保証でもランキングシグナルでもありません。
• GoogleはETagを第一選択として推奨します（「less prone to errors and mistakes」 (翻訳)「エラーやミスが起きにくい」）。両方設定して問題ありません。Last-Modifiedは「Weekday, DD Mon YYYY HH:MM:SS Timezone」 (翻訳)「曜日、DD Mon YYYY HH:MM:SS タイムゾーン」形式を使う必要があり、フッターの著作権日付ではなく実体のある変更時だけキャッシュを無効化します。
• キャッシュ対応はクローラーによって異なります。 すべてのGooglebotリクエストが条件付きになるわけではありません。Bingは2008年のLive Search記事以来、条件付きGETをサポートしています。一般的なHTTP動作です。
• 301/302/307/308（URLを移動させる実際のリダイレクト）や、204 No Content（送るものが本当にないためボディなし）と混同しないでください。
• 本当のリスクは304自体ではなく、コンテンツ変更後も304を返す設定ミスのサーバーです。 ログ分析で捕捉します。何も悪くないのに、一部のクライアントライブラリやプラットフォームキャッシュ層では、有効な304がエラーのように見えることもあります。

公式ドキュメント

304とは何か、検索エンジンがどう利用するかについての一次情報です。

HTTP仕様とブラウザのリファレンス

• RFC 9110 §15.4.5 — 304 Not Modified — 条件付きリクエスト、ボディなし、必須ヘッダーを定義する権威ある仕様です。
• MDN — 304 Not Modified — 平易な説明、If-None-Match/If-Modified-Sinceのトリガー、304が持つべきヘッダー一覧です。
• MDN — HTTP conditional requests — 強い／弱い検証を説明しています。
• MDN — ETag — 弱い（W/）／強い構文を含むETagヘッダーの説明です。

Google Search Central

• Crawling December: HTTP caching — Gary Illyesによる2024年12月9日の記事。ETag／If-None-MatchとLast-Modified／If-Modified-Sinceが304を動かす仕組みと、クロール効率に役立つ理由です。
• Google Crawler (User Agent) Overview — キャッシュに対応するGoogleクローラーと、Last-ModifiedよりETagを推奨する理由です。
• How HTTP status codes affect Google’s crawlers — 304の現在の行。304はそれ以外のインデックス効果がない一方、SearchがURLのシグナルを再計算する可能性があるという但し書きも含みます。
• Troubleshoot Google Search crawling errors — 条件付きリクエストによるリソース節約が「may indirectly」 (翻訳)「間接的に」クロール効率を改善する可能性があること、Googleがすべてのクロール試行で条件付きヘッダーを送るわけではないことの出典です。

Bing

• Live Search向けクローラー改善のお知らせ — 条件付きGET対応（If-Modified-Since/If-None-Match → 304）が2008年からあることを確認する、古いBing／Live Search記事です。

ソースからの引用

記録に残る発言です。各リンクは、ソースが裏付ける引用箇所へ移動するディープリンクです。

HTTP仕様

• 「The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.」 (翻訳)「304（Not Modified）ステータスコードは、条件付きGETまたはHEADリクエストを受信し、条件が偽と評価されなければ200（OK）レスポンスになっていたことを示します。」 — RFC 9110, HTTP Semantics, §15.4.5。 セクションを読む
• 「A 304 response is terminated by the end of the header section; it cannot contain content or trailers.」 (翻訳)「304レスポンスはヘッダーセクションの終わりで終了し、コンテンツやトレーラーを含めることはできません。」 — RFC 9110, §15.4.5（規範上の「ボディは絶対にない」ルール）。 セクションを読む

MDN Web Docs

• 「The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.」 (翻訳)「HTTPの304 Not Modifiedリダイレクトレスポンスステータスコードは、要求されたリソースを再送する必要がないことを示します。」 引用へ移動
• 「Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.」 (翻訳)「強い検証とは、リソースが比較対象とバイト単位で同一であることを保証することです。」 — MDN「HTTP conditional requests」。 ガイドを読む

Gary Illyes、Google — 「Crawling December: HTTP caching」（2024年12月9日）

• 「Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.」 (翻訳)「個別URLのコンテンツがめったに変わらない大規模サイトでは、ローカルキャッシュを許可するとサイトがより効率的にクロールされる可能性があります。Googleのクロール基盤はHTTPキャッシュ標準で定義されたヒューリスティックなHTTPキャッシュをサポートし、具体的にはETagレスポンス／If-None-MatchリクエストヘッダーとLast-Modifiedレスポンス／If-Modified-Sinceリクエストヘッダーを通じて行います。」 記事を読む
• 「We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).」 (翻訳)「ETagはLast-Modifiedの値と違って構造化されておらず、エラーやミスが起きにくいため、強く推奨します。」 記事を読む
• 「If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.」 (翻訳)「クローラーが送ったETagの値がサーバーの生成した現在の値に一致するなら、サーバーはHTTPボディなしのHTTP 304（Not modified）ステータスコードを返すべきです。」 記事を読む
• 「Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.」 (翻訳)「コンテンツに重要な変更があった場合にキャッシュ更新を要求することを推奨します。ページ下部の著作権日付だけを更新したなら、おそらく重要ではありません。」 記事を読む

Patrick Stox — Ahrefsによる補足

• 「304 Not Modified – Says the page hasn’t been modified. Typically used for caching.」 (翻訳)「304 Not Modified — ページが変更されていないことを示します。通常はキャッシュに使われます。」 — 私のHTTPステータスコードとSEOへの影響 ガイドより（この案内に含まれる短い説明を深掘りしたのがこの記事です）。 引用へ移動

304の文脈：混同されるボディなしコードと3xxコード

304と似たコードの違い

落とし穴は、304と204がどちらもボディなしで、304/301/302/307/308がすべて3xxだということです。しかし304は両方の軸で例外です。誰も移動させない唯一の3xxであり、「送るものがない」ではなく「すでに持っている」という意味を持つ唯一のボディなしコードです。

2つのバリデーター

両方が存在する場合は、If-None-MatchがIf-Modified-Sinceより優先されます。

要点

• 304にはボディが絶対にない — RFC 9110が規範として定めています。
• 304は3xxコードですがリダイレクトではない（Locationなし、新しいURLなし）。
• 直接的なランキング効果はなく、GoogleがURLのシグナルを再計算する可能性を除けばインデックス効果もありません。メリットはリソース節約で、大規模サイトのクロール効率を間接的に改善する可能性があります。
• GoogleはETagを第一選択として推奨します。ETagとLast-Modifiedの両方を設定して問題ありません。
• Last-Modifiedは「Weekday, DD Mon YYYY HH:MM:SS Timezone」 (翻訳)「曜日、DD Mon YYYY HH:MM:SS タイムゾーン」を使わないと無視されることがあります。
• フッターの著作権日付ではなく、実体のあるコンテンツ変更時にキャッシュを無効化します。
• すべてのクローラーリクエストが条件付きになるわけではない — キャッシュ対応はクローラーによって異なります。
• Bingは条件付きGET → 304に2008年から対応しています。一般的なHTTP動作です。
• 本当のリスクは古い304（コンテンツ変更後もサーバーが304を返すこと）です。ログ分析で捕捉します。

条件付きリクエストのハンドシェイクを生のHTTPで見る

304がどのように発生するかを示す具体的なリクエスト／レスポンスの連鎖です（ヘッダー値は例示です）。

ETag / If-None-Match — 最初の取得（200）

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

クライアントはボディとETagの値を保存します。

ETag / If-None-Match — 次の取得、コンテンツ変更なし（304）

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

ボディはありません。ETagが一致したため、サーバーはページ生成の計算資源と送信帯域幅を節約しました。クライアントはキャッシュコピーを再利用します。

Last-Modified / If-Modified-Since — 日付ベースの代替

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

正確なHTTP-date形式「Weekday, DD Mon YYYY HH:MM:SS Timezone」 (翻訳)「曜日、DD Mon YYYY HH:MM:SS タイムゾーン」に注目してください。Googleは解析上の問題を避けるため、この形式を推奨しています。

コンテンツが変更された場合 — 304ではなく新しい200

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

保存されたETagがもう一致しないため、サーバーは新しいコンテンツと新しいバリデーターを送ります。キャッシュが更新されます。これが、正しく実装された304がクローラーを古いコンテンツに「閉じ込める」ことがない理由です。コンテンツが変わった瞬間、バリデーターも変わり、次のリクエストは実体のある200を受け取ります。

弱いETagと強いETag

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

経験則： 変更頻度の低いURLが多い大規模サイトを運営しているなら、200に安定したETagを送り（If-None-Matchを尊重し）、安価なボディなし304で「still the same」 (翻訳)「まだ同じ」をクローラーに確認させると、帯域幅と計算資源を節約できます。Googleはこれがサイトの残りの部分のクロール効率を間接的に改善する可能性があると述べています。ETagが再圧縮のたびに、または負荷分散サーバー間で変わるなら、その恩恵を失います。

条件付きキャッシュを壊す304のミス

表現が変わっていないのにETagを変更する

サーバーインスタンス、圧縮処理、リクエスト時刻に結び付いたETagはバリデーターを無効にします。変更されていないコンテンツが完全な200を返し続けるためです。表現から安定したバリデーターを生成するか、バイト単位の差が意味を持たない場合は意図的に弱いETagを使います。

コンテンツ変更後に304を返す

古いバリデーターは、クライアントやクローラーから実際の更新を隠すことがあります。表現が変わるたびにETagを無効化するかLast-Modifiedを進め、古い条件付きリクエストが新しい200とボディを受け取ることを確認してください。

一致する条件付きリクエストなしで304を送る

サーバーはクライアントがキャッシュコピーを持っていると推測してはいけません。If-None-MatchまたはIf-Modified-Sinceを評価した後にだけ304を返します。通常の初回リクエストには完全なレスポンスが必要です。

304をリダイレクトや空のページとして扱う

304にはLocationヘッダーもレスポンスボディもありません。リダイレクトのロジックを通さず、実際のレスポンスを表すステータスを使ってください。実体のある空のリソースを304に置き換えてはいけません。

304でよくある問題

サーバーが常に200を返す

症状： 何も変わっていないのに、繰り返しのリクエストで完全なボディをダウンロードします。 考えられる原因： 初回レスポンスにバリデーターがないか、アプリケーションが条件付きリクエストヘッダーを無視しています。修正： ETagおよび／または有効なLast-Modifiedを送り、一致するIf-None-MatchまたはIf-Modified-Sinceのチェックを実装します。変更されていないリクエストがボディなしの304を返すことを確認してください。

オリジンサーバーごとに異なるETagを生成する

症状： 同じ変更されていないURLが、ロードバランサーの背後で200と304を交互に返します。考えられる原因： 各ノードが独自のバリデーターを生成しています。修正： ETagを配信ノードではなく共有コンテンツの状態から導出し、同じ条件付きリクエストを複数のレスポンスに対して繰り返します。

更新したコンテンツが304を返し続ける

症状： デプロイ後もブラウザーやクローラーが古い表現を保持します。考えられる原因： バリデーターがコンテンツとともに無効化されていません。修正： キャッシュキーまたはデプロイのロジックを修正し、必要なら影響を受けるキャッシュを消去します。古いETagが新しいバリデーター付きの200を受け取ることを証明してください。

Last-Modifiedが無視されているように見える

症状： If-Modified-Sinceで304が返りません。考えられる原因： HTTP-dateが無効、タイムスタンプの精度不足、またはETagが優先されています。修正： 生のヘッダーを調べ、日付形式を修正し、各バリデーターを個別にテストします。

304がアプリケーションコードのエラーに見える

症状： 実際には304を受け取ったリクエストで、スクリプトやアプリが例外を投げたり「エラー」をログに記録したりします。考えられる原因： 一部のHTTPクライアントライブラリは、有効な304を含む200以外のステータスを、リダイレクトに従うかNot Modifiedレスポンスを許可するよう明示的に設定しない限り、例外のように扱います。これはプロトコルやサーバーの問題ではなく、クライアントライブラリの癖です。修正： 4xx/5xxのエラー処理だけでなく、304を特にどう扱うかを確認し、サーバーの問題と判断する前に、生のHTTPレスポンスが正しくボディなしの304であることを確認してください。

プラットフォームのキャッシュ層（例：IIS出力キャッシュ）が状況を曖昧にする

症状： オリジンアプリは正しく見えるのに、304の動作がまだおかしいように見えます。考えられる原因： ホスティングプラットフォーム固有のキャッシュ層（文書化された例としてIIS出力キャッシュ）が、アプリとクライアントの間にあり、独自に304レスポンスを生成または横取りしています。修正： これを複数ある層（オリジンアプリ、CDN、ロードバランサー、プラットフォームキャッシュ）の1つの可能性として扱い、既定の容疑者にしないでください。各層でバリデーターを1つずつ変える制御テストで切り分け、どの層が原因かを判断します。

条件付きリクエストのトレースを監査するプロンプト

初回取得と再取得のリクエスト／レスポンスヘッダーを貼り付けます。

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

ETag実装をレビューするプロンプト

関連するアプリケーション、CDN、またはサーバー設定を貼り付けます。

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell：ETagを条件付きリクエストとして再生する

macOS/Linuxのターミナルで実行します。引用符を含め、ETagを正確にコピーしてください。

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

最初のレスポンスにはバリデーターが現れるはずです。2回目は、表現が変わっていない場合は304、貼り付けたETagが古い場合は200を返すはずです。

PowerShell：Last-Modifiedをテストする

URLとタイムスタンプを置き換えてから、PowerShellで実行します。

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

DevTools Console：ページリソースのバリデーターを一覧表示する

ブラウザーのConsoleで実行します。リソースタイミングのエントリーを報告するため、Networkパネルで実際のETag、Last-Modified、ステータスヘッダーを調べてください。

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

304の動作を調べるツール

• HTTP Header Checker：バリデーターを再生する前に、通常のレスポンスのETag、Last-Modified、Cache-Control、Vary、CDN／エッジの指紋を調べます。
• ブラウザーDevTools Networkパネル： 「Disable cache」を無効にして再読み込みし、リクエスト／レスポンスヘッダーを比較します。DevToolsではHSTSとローカルキャッシュの動作も見えるため、オリジンが送ったものとブラウザーの動作を区別してください。
• curl： ブラウザーのキャッシュ状態に左右されず、正確なIf-None-MatchまたはIf-Modified-Sinceヘッダーを送ります。
• アクセスログ： 条件付きだったクローラーリクエストの数と、304で終わったか完全な200で終わったかを定量化します。

変更後に条件付きレスポンスが動作することを証明する

変更されていない表現のテスト

実行するテスト： URLを取得し、ETagをコピーしてから、curl -I -H 'If-None-Match: "VALUE"' URLで再実行します。期待結果： 304、一致するバリデーター、ボディもLocationもない。失敗の解釈： サーバーが条件を無視したか、不安定なバリデーターを生成しています。監視期間： 直ちに。ロールバックのトリガー： キャッシュ変更によって通常のリクエストが完全な200レスポンスを失うこと。

変更された表現のテスト

実行するテスト： 実際のコンテンツ変更をデプロイし、古いETagを再生します。期待結果： 更新済みボディと新しいバリデーター付きの200。失敗の解釈： キャッシュ無効化が古いままです。監視期間： デプロイがすべてのオリジンに届いた直後。ロールバックのトリガー： ロールアウト完了後も、いずれかのオリジンが古いバリデーターに対して304を返すこと。

複数オリジンの安定性テスト

実行するテスト： 同じ通常リクエストと条件付きリクエストを、配信プールに届く回数だけ繰り返し、ETagとステータスを記録します。期待結果： 変更されていない表現は互換性のあるバリデーターを使い、一貫して304を返します。失敗の解釈： 一致するVary戦略なしに、バリデーターがノードやエンコーディングごとに変わっています。監視期間： デプロイ済みプール全体で直ちに。ロールバックのトリガー： 新しいバリデーターのロジックが古いコンテンツを返す、またはクライアント間で表現を混在させること。

条件付きキャッシュの健全性を測る

条件付き再検証の成功率

指標： 完全な200に対する、304で終わった条件付きリクエストの割合。わかること： 変更されていないリソースが不要な転送を避けているか。取得方法： If-None-MatchまたはIf-Modified-Sinceを含むアクセスログのリクエストを、レスポンスステータスとURLクラスでグループ化します。ベンチマーク／現実的な範囲： コンテンツタイプごとにベースラインを設定します。頻繁に変わるページを静的アセットと同じ割合に無理に近づけてはいけません。頻度： ロールアウト中は毎週、その後は毎月。

変更されていない取得で避けられたバイト数

指標： 有効な304レスポンスで転送されなかったレスポンスボディの推定バイト数。わかること： クロール効率の恩恵のうち、帯域幅に関する側面。取得方法： 304のログ件数を、同じURLクラスの直近の完全なレスポンスサイズに結合します。ベンチマーク／現実的な範囲： サイト固有の変更前ベースラインと比較します。すべてのコンテンツ構成に合う普遍的な目標はありません。頻度： 毎月。

古いバリデーターの失敗

指標： 変更されたURLが古いバリデーターを受け入れ続ける件数。わかること： 最新性を犠牲にせずに効率化できているか。取得方法： デプロイ前のETagを再生する小規模なデプロイ後サンプルを実行します。ベンチマーク／現実的な範囲： 古いレスポンスが1件でも確認されたら調査が必要です。頻度： キャッシュまたはバリデーター生成を変更するすべてのデプロイ時。

確認テスト：304 Not Modified

304の意味と仕組みについての簡単な5問です。それぞれ答えを選んでから、確認してください。

変更履歴