条件付きリクエスト：ETagとIf-Modified-Since、304 Not Modified

TL;DR — 条件付きリクエストとは、Googlebotが再ダウンロードする前に、サーバーへ「前回取得してからこのページは変わりましたか」と確認する仕組みです。変わっていなければ、サーバーは本文のない小さな304 Not Modifiedを返し、クローラーは保存済みのコピーを再利用します。双方の作業を減らせますが、意味のある効果が出るのは主に大規模サイトで、ランキングを上げる仕組みではありません。

条件付きリクエストとは

通常、Googlebotがページを取得するときは全体をダウンロードします。条件付きリクエストでは、クローラーが「前回訪問したときから実際に変わっている場合だけ送ってください」と伝えます。

そのために、前回のクロールで覚えておいた少しの情報を使います。

• 日付 — 「前回このページを取得したとき、最終変更日はこの日付だと伝えられました。もっと新しくなっていますか？」
• フィンガープリント — 「前回このページにID（ETag）を付けてもらいました。そのIDはまだ同じですか？」

何も変わっていなければ、サーバーは**304 Not Modified**を返します。ページ本文は付かず、「前回と同じ」という短いメッセージだけです。Googlebotは毎回すべてを再ダウンロードせず、前回保存したコピーを使います。

変化があれば、サーバーは通常どおり完全なページ（200 OK）を返し、クローラーは新しいコピーを取得します。

なぜ気にするのか

ほとんど変わらない商品ページが百万件ある大規模なオンラインストアを考えてください。条件付きリクエストがなければ、Googlebotは毎回同じページを再ダウンロードし、帯域とサーバー処理を浪費します。条件付きなら、多くの訪問は「変更なし」という小さな返答になり、クローラーは変更されたページや新しいページに時間を使えます。

効果の本質は効率です。これはクロールバジェット、つまり検索エンジンがサイト上で行うクロール量の一部です。

正直な注意点

期待を膨らませる前に、知っておくべきことが2つあります。

1. 主に大規模サイト向けです。 小規模サイトでは削減量が小さく、設定の手間に見合わないことが多いでしょう。以前書いたとおり、小規模サイトにとって304がもたらすキャッシュ機会は*“not that crucial”* (翻訳)「それほど重要ではありません」。
2. ランキングは改善しません。 クロール効率を上げても検索結果で上位になるわけではありません。大規模サイトが新規・変更ページを少し速くクロールされやすくするだけです。

正確なヘッダー、Googleが実際に対応すると述べている内容、サイトが静かに壊れる3つの方法、そしてクロール速度・クロール頻度との違いを知りたいですか？ Advancedタブへ進んでください。

TL;DR — 条件付きリクエストにより、Googlebotはキャッシュ済みのコピーを再ダウンロードせずに検証できます。If-Modified-Since（Last-Modifiedヘッダーと照合）やIf-None-Match（ETagと照合）を送り、変化がなければ本文のない304 Not Modifiedを返してクローラーがコピーを再利用します。完全なページが100 KB以上なのに対し、返答はおよそ1 KBです。両方のバリデーターがある場合はETagが優先され、Googleは日付形式の問題がないETagを推奨しつつ両方の設定を勧めています。Googleはすべてのクロールでヘッダーを送るわけではなく、条件によってはヘッダーなしで304を先回りして返すこともできます。304はインデックスシグナルを固定しません。常に本文付き200を返すこと、変動するETag、実際の変更を追わないLast-Modifiedという3つの設定ミスが仕組みを壊します。これは大規模サイト向けのクロール効率策であり、ランキング要因ではありません。 Evidence for this claim Google may send If-Modified-Since or If-None-Match, but a site must not assume every crawler request will contain either conditional header. Scope: official protocol/provider documentation and production verification Confidence: high · Verified: 2026-07-18 Troubleshoot Google Search crawling errors

仕組みを正確に見る

クロール速度がGooglebotの取得の速さ、クロール頻度が戻ってくる頻度であるのに対し、条件付きリクエストは個々の再クロールにどれだけ少ないコストで答えられるかの仕組みです。クローラーとサーバーの間で行う検証ハンドシェイクで、HTTPヘッダーの2組を基盤にします。

流れを段階ごとに見てみましょう。

1. 最初のクロールでは、サーバーが200 OKとともにページ、Last-Modifiedの日付、そして／またはETagのフィンガープリントを返します。
2. 後のクロールでGooglebotはIf-Modified-Since（最後に見た日付を返す）やIf-None-Match（ETagを返す）を送ることがあります。
3. サーバーが検証します。意味のある変更がなければ、本文なしの304 Not Modified（ステータスとヘッダーだけ）を返します。
4. Googlebotは前回クロールしたバージョンを再利用します。変更があれば、サーバーは完全な本文付き200 OKを返します。

Googleはこのハンドシェイクをほぼ逐語的に説明しています。“Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. 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.” (翻訳)「キャッシュに対応するGoogleのクローラーは、対象URLを前回クロールしたときに返されたETag値をIf-None-Matchヘッダーで送ります。クローラーが送ったETag値がサーバーが生成した現在の値と一致する場合、サーバーは本文なしのHTTP 304（Not modified）ステータスコードを返すべきです。」 Evidence for this claim Google documents heuristic HTTP caching and support for ETag and Last-Modified validators for crawlers that support caching. Scope: official protocol/provider documentation and production verification Confidence: high · Verified: 2026-07-18 Things to Know about Google web crawling

ETagとLast-Modified — GoogleがETagを好む理由

両方のバリデーターに対応します。Googleのクロール文書は次のように明記しています。“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.” (翻訳)「Googleのクロール基盤は、HTTPキャッシュ標準で定義されるヒューリスティックHTTPキャッシュに対応しています。具体的には、ETagレスポンスヘッダーとIf-None-Matchリクエストヘッダー、Last-ModifiedレスポンスヘッダーとIf-Modified-Sinceリクエストヘッダーを使います。」 Evidence for this claim Google documents heuristic HTTP caching and support for ETag and Last-Modified validators for crawlers that support caching. Scope: official protocol/provider documentation and production verification Confidence: high · Verified: 2026-07-18 Things to Know about Google web crawling

両方がある場合は**ETagが優先**されます。“If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (翻訳)「HTTPレスポンスにETagとLast-Modifiedの両方がある場合、GoogleのクローラーはHTTP標準に従いETag値を使います。」これはGoogle独自の癖ではなくHTTP仕様の優先順位で、Ahrefsの304 Not Modified用語集 で説明しているとおり、If-None-MatchとIf-Modified-Sinceを両方使う場合はIf-None-Matchが優先されます。

ETagを優先する理由は、日付を解釈する必要がない不透明な文字列、つまりコンテンツのフィンガープリントだからです。Googleの推奨は次のとおりです。“For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” (翻訳)「Googleのクローラーには、キャッシュの希望を示すためLast-ModifiedヘッダーではなくETagを使うことを推奨します。ETagには日付形式の問題がないためです。」Last-Modifiedを使うなら、HTTP標準の形式（Weekday, DD Mon YYYY HH:MM:SS Timezone）にします。Googleが解釈できない可能性があるためです。実務上は、可能なら両方を設定するのが安全です。

補助的なシグナルとしてCache-Control: max-ageもあります。Googleは必須ではないとしつつ、コンテンツが変更されないと予想する秒数を設定すれば、再クロール時期の判断材料になります。ただし非対称性に注意してください。Googleのクロール基盤はmax-ageをヒントとして尊重しますが、ブラウザーのように他のCache-Controlディレクティブを扱うわけではありません。

304がすること、しないこと

ネットワーク上の効果は大きくなります。304には本文がないため、Gary Illyesの概算では完全なページの100 KB以上に対して約1 KBです。完全なレンダリングやデータベースクエリが不要なので生成も安く、本文の再解析・再レンダリング・インデックス処理全体の再実行が不要なのでGoogle側の処理も軽くなります。

ただし、304がすることを正確に理解してください。ランキングシグナルを固定するものではありません。 Googleのステータスコード文書は、本文を再取得しなくてもインデックス処理パイプラインがURLのシグナルを「“may recalculate signals for the URL,” (翻訳)「再計算する可能性がある」」と説明しています。304が省略するのはコンテンツのダウンロードと再処理であり、後続の評価すべてではありません。「304を返してランキングを固定する」方法はありません。

Googleが常に要求するわけではない — 正常です

多くの解説が見落とす点です。Googlebotはすべてのリクエストで条件付きヘッダーを送るわけではありません。Googleのクロールエラー文書には次のようにあります。“Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” (翻訳)「GoogleはクロールにIf-Modified-SinceとIf-None-MatchのHTTPリクエストヘッダーを一般にサポートします。ただし、すべてのクロール試行でクローラーがヘッダーを送るわけではなく、リクエストの用途によります。たとえばAdsBotは両方のヘッダーを設定する可能性が高くなります。」

ログを見てGooglebotがIf-None-Matchをほとんど送っていなくても、設定が壊れているとは限りません。そのクロールではGoogleが要求していないだけかもしれません。Googleは、個々のクローラーやフェッチャーが提供する製品に応じてキャッシュを使う場合と使わない場合があるとも説明しています。

反対に、あまり知られていない実装方法もあります。条件付きヘッダーをまったく受け取らなくても、コンテンツがGooglebotの前回訪問から変わっていなければ304を返せます。Googleの説明は次のとおりです。“Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” (翻訳)「リクエストヘッダーとは独立して、コンテンツがGooglebotの前回の訪問から変わっていなければ、任意のGooglebotリクエストに本文なしの304（Not Modified）HTTPステータスコードを返せます。サーバーの処理時間とリソースを節約し、間接的にクロール効率を改善する可能性があります。」これは高度なCDN／エッジ技法ですが、変更済みコンテンツに304を返すとバリデーターが嘘をつくため危険です。

クロールバジェットに重要な理由

Googleのクロールバジェット指針が対象にする、変更頻度の低いURLが多い大規模サイトで最も効果が積み重なります。ロングテールの商品SKU、ニュースや出版社のアーカイブ、大規模なドキュメントサイトでは、前回とバイト単位で同じページの再ダウンロードにクロールバジェットが使われます。そうしたページに304で答えれば、新規・変更ページのためにバジェットを空けられます。

正直に言えば、Googleは採用を増やしてほしいと求めているのであって、誰もがすでに実施していると報告しているわけではありません。Illyesによると、Googlebotの取得のうちキャッシュ可能な割合はウェブが成長した過去10年で約0,026%から約0,017%へ低下しました。つまり未利用のレバーです。「Crawling December」記事の見出しは、ほぼ文字どおりの願いです。“Allow us to cache, pretty please.” (翻訳)「どうかキャッシュさせてください。」多くのサイトはまだ設定できていません。

条件付きリクエストを壊すよくある設定ミス

バリデーターを設定することと、その恩恵を受けることは同じではありません。サイトがこれを静かに壊す方法は、3つ（正確には4つ）あります。

1. 常に本文付き200を返す

最も一般的な失敗は何もしないことです。サーバーがバリデーターを設定しない、または検証しないため、何も変わっていなくても毎回フル再ダウンロードになります。多くの場合、キャッシュ層を設定していないCMS／サーバースタックです。これはIllyesが解消を促している初期状態です。

2. リクエストごとに変わるETag

この問題は正しく見えるため厄介です。ETagを埋め込みタイムスタンプ、リクエスト／セッションごとのトークン、リクエストID、ビルド時刻を埋め込む成果物など、変動するものから計算すると、表示内容が同じでも毎回「新しい」ETagになります。If-None-Matchは一致せず、304を返す根拠がなくなります。対策は、リクエストごとに変わる値ではなく、実際のレスポンス本文のハッシュまたは安定したコンテンツバージョンIDからETagを作ることです。

3. CDN／クラスターのノードごとのばらつき

近い問題として、同じコンテンツなのに異なるオリジンノードが異なる（弱い）§ETag§を生成する場合があります。CDNやクローラーがノードを行き来すると、安定した値を見られず、304に到達しないまま検証を繰り返します。コンテンツから決定的にETagを作るか、フリート全体でETag生成を中央化してください。

4. 実際の変更を反映しないLast-Modified

Last-Modifiedを毎回のレンダリング時刻で更新したり、フッターの自動更新年のような些細な変更で進めたりすると、無意味なフル再クロールを誘発します。逆に古い値や作為的な値はGoogleのシグナルへの信頼を損ないます。これはサイトマップのlastmodにGoogleが求める正直さと同じ原則です。Last-Modifiedヘッダーも、検証可能な重要な変更がある場合だけ更新します。（lastmod）

Illyesのエッジケース：304が壊れたページを固定するとき

これは独立して取り上げる価値があります。直感に反し、ほとんど解説されないからです。Illyesは、304が「“backfire spectacularly” (翻訳)「激しく裏目に出る」」ことがあると説明しています。サーバーのバグで壊れた空ページを200で返し、クローラーが一時的なエラーとして再クロールを予定した後、まだ壊れたページが304（変更なし）を正しく返すと、クローラーはエラー状態こそ永続的な「本当の」コンテンツだと判断し、再確認の頻度を下げる可能性があります。彼の説明は、クローラーが「“learn[ing] the error is persistable.” (翻訳)「エラーは永続するものだと学習する」」というものです。本人の注意書きは、“but it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” (翻訳)「ただ、デバッグがまったく悪夢になるので、心の奥に置いておく価値はあります。」です。基盤の生成が壊れているサイトに条件付きリクエストを追加してはいけません。

Bingはどう扱うか

これはGoogleだけの機能ではなく、Bingの対応はより古く、明示的とも言えます。Bing（Live Search時代）は2008年にRFC-2616準拠の条件付きGETを発表し、変更がなければページを再ダウンロードしないと説明しました。“generally will not download the page unless it has changed since the last time it crawled it” (翻訳)「前回のクロールから変更されていない限り、通常はページをダウンロードしません」。最後のダウンロード時刻をIf-Modified-Sinceで送り、利用可能ならIf-None-MatchとETagも使います。現在のBingはこれをクロール効率という追跡可能な指標として扱い、Fabrice Canelはそれを「“how often we crawl and discover new and fresh content per page crawled.” (翻訳)「1ページをクロールするたびに、どのくらいの頻度で新しく新鮮なコンテンツを発見するか」」と定義します。不要な再クロールはスコアを直接下げます。 Evidence for this claim Conditional requests use validators such as ETag and Last-Modified with If-None-Match or If-Modified-Since. Scope: Current official or standards documentation. Confidence: high · Verified: 2026-07-14 RFC 9110: Conditional requests

ランキングに影響するか

いいえ。クロール速度とクロールバジェットの記事と同じ規律を守ってください。条件付きリクエストはクロール効率とリソースのレバーであり、ランキング要因ではありません。公式資料はETag、If-Modified-Since、304をランキングと結び付けていません。間接的には、大規模または頻繁に更新されるサイトが新規・変更コンテンツを早くクロール・インデックスされやすくしますが、クロール効率自体はランキングシグナルではありません。

動作を検証する方法

真実はサーバーログにあります。GooglebotがIf-None-Match／If-Modified-Sinceリクエストヘッダーを送り、サーバーが304を返しているかを確認します。実世界のデータは少ないため、Dave Smartによるサーバーログ調査 は有用です。検証済みGooglebotトラフィックを監視したところ、304になったリクエストは約1,3%で、大半は200でした。If-None-Matchのリクエストは、前回取得の直後にURLが再要求されたときに集中する傾向がありました。結論は、サイトが小さければ稀ですが、規模があれば「“significant savings” (翻訳)「大幅な削減」」になり得るという指針と一致します。小規模サイトで高い304率を期待せず、規模が大きくなれば意味が出ると考えてください。

条件付きリクエスト、速度、頻度、バジェットの違い

クロールバジェット周辺の用語を整理しましょう。

• クロール速度 — Googlebotがどれだけ速く取得するか（供給側で、サーバーの健全性により抑制されます）。
• クロール頻度 — 既知のURLをどれだけ頻繁に再取得するか（人気度と古さによります）。
• クロールバジェット — 需要と容量の範囲、つまりGoogleがクロールでき、クロールしたいURLの集合です。
• 条件付きリクエスト — 個々の再クロールにどれだけ安く答えられるかです。クロールの速さや頻度は変えませんが、変更のないページへの訪問をほぼ無料にし、同じコンテンツへのバジェット浪費を止めます。

AI要約

Advanced版の要点をまとめます。

• 条件付きリクエスト＝「変わりましたか」 — GooglebotはIf-Modified-Since（Last-Modifiedと照合）やIf-None-Match（ETagと照合）を送り、変更がなければ本文なしの**304 Not Modified**を返してコピーを再利用します。
• 両方があればETagが優先 — Googleは日付形式の問題がないETagを推奨しますが、両方を設定するよう説明しています。Cache-Control: max-ageは再クロール時期の補助ヒントです。
• 304は約1 KB対100 KB以上 — 再ダウンロードと再処理を省きますが、インデックスシグナルを固定せず、Googleは再計算できます。
• ヘッダーは常に送られない — 用途に依存し、AdsBotの方が送る可能性があります。条件付きヘッダーなしで304を先回りして返せる場合もあります。
• 3つの設定ミス — 常に本文付き200、変動するETag（タイムスタンプ、リクエストごとのトークン、ノードごとのCDN差異）、実際の変更を追わないLast-Modifiedです。
• エッジケース — 壊れた空ページに対する304が、Googlebotにエラーを永続的な状態だと判断させることがあります（Illyes）。
• Bing — 2008年からRFC準拠の条件付きGETに対応し、クロール効率として追跡しています。
• 採用率は低下 — 10年間でキャッシュ可能な取得が約0,026%から約0,017%へ低下しました。大規模サイト向けの未利用レバーで、ランキング要因ではありません。
• ログで検証 — 304率とIf-None-Matchの有無を見ます。Tame the Botsの実測では、小規模サイトでは稀ですが規模があれば意味があります。（lastmod）

公式ドキュメント

条件付きリクエストとクローラーのキャッシュに関する一次資料です。

Google

• Googleのウェブクロールについて知っておくこと — 現在のHTTPキャッシュ契約、ETag／If-None-Match、Last-Modified／If-Modified-Since、ETagの優先順位、Cache-Control: max-ageのヒントを説明します（古い検索ドキュメントのパスから移動しましたが指針は同じです）。
• Crawling December：HTTPキャッシュ — ドキュメント更新の背景にあるGary Illyesの2024年12月の記事です。「どうかキャッシュさせてください」という見出しを扱います。
• Google検索のクロールエラーをトラブルシュート — If-Modified-Since／304の仕組み、AdsBotの例、条件付きヘッダーなしで304を返す許可を説明します。
• HTTPステータスコード、ネットワーク、DNSエラー — 304でシグナルが再計算される可能性と、インデックスへの悪影響がないことを説明します。
• クロールバジェットを最適化する — 親概念と、誰が気にすべきかを扱います。
• サイトマップを作成して送信する — Last-Modifiedと同じく、lastmodを正直に設定する原則を示します。（/search/docs/...）

Bing／Microsoft

• Live Searchのクローラー改善を発表 — 2008年のRFC-2616準拠条件付きGETの発表で、If-Modified-SinceとIf-None-Match／ETagを扱います。
• bingbotシリーズ：クロール効率を最大化する — Bingの「クロール効率」指標と、変更のない再クロールがそれを下げる理由です。
• Bing Webmaster Tools — クロール制御 — 速度側のレバーを扱い、条件付きリクエストの1回あたりの効率と対比します。

出典からの引用

GoogleとBingによる記録に残る発言です。各リンクは引用箇所へ移動する深いリンクです。

Google — 対応内容を正確に見る

• “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.” (翻訳)「Googleのクロール基盤は、HTTPキャッシュ標準で定義されるヒューリスティックHTTPキャッシュに対応します。具体的にはETagレスポンス／If-None-Matchリクエストヘッダーと、Last-Modifiedレスポンス／If-Modified-Sinceリクエストヘッダーを使います。」 — Google『Googleのウェブクロールについて知っておくこと』。 引用へ移動
• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (翻訳)「HTTPレスポンスにETagとLast-Modifiedの両方がある場合、GoogleのクローラーはHTTP標準に従いETag値を使います。」 引用へ移動
• “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” (翻訳)「Googleのクローラーには、キャッシュの希望を示すためLast-ModifiedではなくETagを使うことを推奨します。ETagには日付形式の問題がないためです。」 引用へ移動
• “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. 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.” (翻訳)「キャッシュに対応するGoogleのクローラーは、URLを前回クロールしたときのETag値をIf-None-Matchヘッダーで送り、現在の生成値と一致すれば本文なしのHTTP 304（Not modified）を返すべきです。」 引用へ移動

Google — ヘッダーを送る条件と先回りの304

• “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” (翻訳)「GoogleはクロールにIf-Modified-SinceとIf-None-MatchのHTTPリクエストヘッダーを一般にサポートします。ただし、すべてのクロール試行で送るわけではなく、用途によります。たとえばAdsBotは両方を設定する可能性が高くなります。」 — Google『Google検索のクロールエラーをトラブルシュート』。 引用へ移動
• “If our crawlers send the If-Modified-Since header, the header’s value is the date and time the content was last crawled. Based on that value, the server may choose to return a 304 (Not Modified) HTTP status code with no response body, in which case Google will reuse the content version it crawled the last time.” (翻訳)「GoogleのクローラーがIf-Modified-Sinceヘッダーを送る場合、その値はコンテンツを最後にクロールした日時です。その値に基づき、サーバーは本文なしの304（Not Modified）を返せます。その場合、Googleは前回クロールしたコンテンツのバージョンを再利用します。」 引用へ移動
• “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” (翻訳)「リクエストヘッダーとは独立して、コンテンツがGooglebotの前回訪問から変わっていなければ任意のGooglebotリクエストに本文なしの304を返せます。サーバーの処理時間とリソースを節約し、間接的にクロール効率を改善できます。」 関連資料

Gary Illyes（Google）— 304が裏目に出る失敗モード（LinkedIn）

• “HTTP 304 (not modified) is super useful to signal crawlers that the content they’re accessing hasn’t changed since it was last crawled, but it can also backfire spectacularly.” (翻訳)「HTTP 304（not modified）は、アクセス中のコンテンツが前回のクロールから変わっていないとクローラーに伝えるのに非常に便利ですが、激しく裏目に出ることもあります。」 記事を読む
• どのくらい起きるかについて：“Does this ever happen? Yes. Often? Absolutely not. But it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” (翻訳)「これは起きますか。はい。頻繁ですか。まったく違います。ただ、デバッグが悪夢になるので心の奥に置いておく価値があります。」 記事を読む

Bing（Live Search）、Fabrice Canel（2008年の条件付きGET発表）

• “Live Search supports conditional get as defined by RFC 2616 (Section 14.25), and generally will not download the page unless it has changed since the last time it crawled it.” (翻訳)「Live SearchはRFC 2616（Section 14.25）で定義される条件付きGETに対応し、前回クロールから変更がない限り通常はページをダウンロードしません。」 引用へ移動

条件付きリクエストを実装すべきか

すべてのサイトに必要なわけではありません。サーバー設定に触る前に、自分のサイトで時間を使う価値があるかを判断してください。

SOP：条件付きリクエストを正しく実装する

大規模サイトで条件付きリクエスト対応を追加または修正するための再現可能な手順です。測定、実装、検証の順に進めます。

1. 本当に問題があるか確認する。 サーバーログから検証済みGooglebotトラフィックを取り出します。変更のないURLへのリクエストの多くが本文付き200で、If-None-Match／If-Modified-Sinceヘッダーがほとんどなければ改善余地があります。変更のないページですでに304が返っているなら止めてください。得られるものは少ないかもしれません。

2. 安定したコンテンツベースのETagを生成する。 実際のレスポンス本文のハッシュまたは安定したコンテンツバージョン識別子からETagを計算します。タイムスタンプ、リクエスト／セッションごとのトークン、リクエストID、サーバーノードごとに変わる値から作ってはいけません。同じ変更のないURLを2回要求し、両方のETagが同一であり、CDN／オリジン群でも同一であることを確認します。

3. 正直なLast-Modifiedを設定する。 Last-Modifiedは、最後に重要なコンテンツ変更があった日時にします。現在のレンダリング時刻や、フッターの年・タイムスタンプだけが変わったときに進む値は使いません。HTTP標準の形式（Weekday, DD Mon YYYY HH:MM:SS Timezone）にします。可能ならETagとLast-Modifiedの両方を設定し、GoogleがETagを優先することを確認します。

4. 304を正しく返す。 受信したIf-None-Matchが現在のETagと一致する、またはIf-Modified-SinceがLast-Modifiedより古くなく、変更もない場合は、本文なしの304 Not Modified（ステータスとヘッダーだけ）を返します。多くのウェブサーバーやフレームワークが自動処理できますが、オリジン前段のプロキシやCDNがそれを除去していないか確認します。

5.（任意）Cache-Controlのmax-ageヒントを追加する。 コンテンツが変更されないと予想する秒数をCache-Control: max-age=<seconds>に設定し、再クロール時期の補助シグナルにします。ヒントであり、保証ではありません。

6. ログで検証したら、触りすぎない。 数週間後にログを再確認します。変更のないページではGooglebotのIf-None-Matchリクエストが304になり、実際に変更された場合だけ200になることを確認します。小規模サイトで高い304率を期待せず、規模があれば意味が出ると考えてください。

**ガードレール：**実際に変更されたページに304を返してはいけません。また、不安定なオリジンへ条件付きリクエストを追加してはいけません。壊れた空ページに対する304は、Googlebotにエラーを永続的なものだと判断させる可能性があります。

避けるべき神話とミス

努力を浪費したり、静かな破損を生んだりする繰り返しの誤解です。

「Googlebotは常にIf-Modified-Since／If-None-Matchを送るので、ログに見えなければサーバーが壊れている。」誤りです。Googleはすべてのクロールでヘッダーを送るわけではなく、用途に依存すると明記しています。メインの検索クローラーは一貫して送らず、AdsBotの方が送る可能性が高いとされます。Tame the Botsの実測サイトでは304になったリクエストは2%を大きく下回りました。

「304ならGoogleはランキング／シグナルを再評価しない。」誤りです。Googleの文書は、304でもインデックス処理パイプラインがURLのシグナルを再計算する可能性があり、本文のダウンロードと再処理だけが省略されると説明します。

「ETagを設定すれば自動的に304になる。」変動するETagなら誤りです。タイムスタンプ、リクエストごとのトークン、ノードごとの状態から作ったETagは毎回変わり、If-None-Matchが一致しません。

「Last-Modifiedは存在すればよく、どの日付でもよい。」誤りです。実際の変更を追わない値は無駄な再クロールを誘発し、Googleのシグナルへの信頼を損ないます。サイトマップlastmodと同じ原則です。

「304は条件付きGETへの反応としてしか返せない。」誤りです。サーバーがコンテンツ不変を独自に知っていれば、任意のGooglebotリクエストに本文なし304を先回りして返せます。

「条件付きリクエストでランキングが上がる。」公式資料はそう述べていません。文書化された利点はクロールとサーバーの効率で、大規模サイトの新コンテンツのクロールを助けるだけです。

「巨大なエンタープライズサイトだけに関係する。」緊急度については概ねそうですが、仕組みと設定ミスはどのサイトにも当てはまります。小規模サイトでは設定の価値が出にくいだけです。

curlでURLのキャッシュバリデーターを確認する

サーバーが送るバリデーターと、それを返したときに§304§になるかを確認します。

**1）レスポンスヘッダーを見る（ETagとLast-Modifiedを探す）

curl -sI https://example.com/some-page | grep -iE 'etag|last-modified|cache-control'
# ETag: "a1b2c3d4e5"
# Last-Modified: Thu, 22 Jan 2026 01:28:49 GMT
# Cache-Control: max-age=94043

2）ETagを条件付きで送り、304を確認する

curl -sI https://example.com/some-page \
  -H 'If-None-Match: "a1b2c3d4e5"'
# HTTP/2 304        ← correct: server confirms nothing changed, sends no body
# HTTP/2 200        ← if you get this on an unchanged page, your validators aren't working

3）代わりに日付を条件付きで送る

curl -sI https://example.com/some-page \
  -H 'If-Modified-Since: Thu, 22 Jan 2026 01:28:49 GMT'
# HTTP/2 304

変動するETagを検出する

同じ変更のないURLが連続するリクエストで異なるETagを返すなら、ETagは変動しています（タイムスタンプ／トークン由来）。If-None-Matchは一致しません。

# Request twice; the two ETag values should be IDENTICAL for an unchanged page
for i in 1 2; do curl -sI https://example.com/some-page | grep -i '^etag:'; done
# ETag: "a1b2c3d4e5"
# ETag: "a1b2c3d4e5"   ← good (stable)
# ETag: "9f8e7d6c5b"   ← BAD if different: your ETag changes every request

アクセスログで304をスポットチェックする

Googlebotによる実際の条件付きリクエスト活動を確認します。フィールド位置はログ形式に合わせて調整してください（ここでは複合ログ形式のステータスフィールドを想定します）。

# Count status codes returned to Googlebot
grep -i 'googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
#   4211 200
#     53 304        ← these are the conditional-request wins
#     12 301

# See which URLs are getting 304s
grep -i 'googlebot' access.log | awk '$9==304 {print $7}' | sort | uniq -c | sort -rn | head

ユーザーエージェント文字列を信頼する前に、リバースDNSとフォワードDNSで本当にGooglebotか確認してください。偽のGooglebotトラフィックはよくあります。

ブラウザーでDevToolsコンソールをすばやく確認する

Chrome DevToolsコンソールに貼り付け、現在のページが受け取ったバリデーターを読み取ります。

// Reads the ETag / Last-Modified the server sent for THIS page
fetch(location.href, { method: 'HEAD' }).then(r => {
  console.log('ETag:', r.headers.get('etag'));
  console.log('Last-Modified:', r.headers.get('last-modified'));
  console.log('Cache-Control:', r.headers.get('cache-control'));
});

バリデーター → リクエスト → レスポンスの枠組み

1. **バリデーター：**最初の200レスポンスがETag、Last-Modified、または両方を返します。
2. **リクエスト：**後の取得がその値をIf-None-MatchまたはIf-Modified-Sinceで返します。
3. **レスポンス：**変更のないコンテンツは本文なし304、変更されたコンテンツは新しい本文とバリデーター付き200になります。
4. **安定性チェック：**バリデーターは表現内容が変わったときに変わるべきで、別のサーバーに当たったことやタイムスタンプを含むことを理由に変わってはいけません。

条件付きリクエストのヘッダー早見表

バリデーターを確認するツール

• HTTP Header CheckerはETag、Last-Modified、キャッシュヘッダー、リダイレクト間のヘッダー変更を表示します。
• ブラウザーDevToolsのNetworkパネルで、初回のバリデーターと再リクエスト時の条件付きヘッダーを確認できます。
• curlは再現可能な最も明確なテストです。バリデーターを取得して送り返し、変更のないレスポンスが304になることを確認します。
• アクセスログ分析で、クローラーの条件付きリクエストが規模のあるサイトで実際に304を受け取っているか確認します。

条件付きリクエストの健全性を測る指標

条件付きヒット率

指標：304を返した適格な条件付きリクエスト。**分かること：**バリデーターが変更のない本文転送を避けているか。取得方法：If-None-MatchまたはIf-Modified-Sinceを含むアクセスログリクエストをレスポンスステータスごとに集計します。**ベンチマーク：**テンプレートと変更頻度ごとに基準値を作ります。頻繁に更新されるページは自然に変わります。**頻度：**毎月、またはキャッシュ／CDN変更後。

304で避けたバイト数

**指標：**転送しなかったレスポンス本文の推定バイト数。**分かること：**レスポンス数だけでなく帯域の効果。**取得方法：**各304URLをログまたはクロール出力の最新200本文サイズと比較します。**ベンチマーク：**サイト自身の前期間と比較し、普遍的な目標値は設定しません。**頻度：**毎月。

バリデーターの不安定性

【指標：】チェック間でETagまたはLast-Modifiedが変わる変更のないURL。**分かること：**リクエストごと、またはノードごとのばらつきが再検証を妨げているか。**取得方法：**固定サンプルへ同じヘッダーリクエストを繰り返します。**ベンチマーク：**表現が不変ならバリデーターも安定するはずです。**頻度：**デプロイ、CDN変更、ロードバランサー変更の後。

時間を使う価値のある資料

私の関連記事

• 304 Not Modifiedとは？ （Ahrefs SEO Glossary）— 条件付きリクエストの流れ、If-None-Match優先規則、小規模サイトでは「それほど重要ではない」が大規模サイトでは「大きな機会」になる304を解説します。
• クロールバジェットを心配すべきとき — 親概念であるクロールバジェット、需要と容量、条件付きリクエストを絞り込む前に気にすべき対象を扱います。
• Googlebotとは何か、どう動くか — Googlebotが何をどの速さでクロールするか、そのスケジューラーの背景です。
• テクニカルSEO初心者ガイド — クロール効率がテクニカルSEO全体のどこに位置するかを説明します。

私の講演

• How Search Works （SlideShare）— クロール、レンダリング、インデックス、ランキングと、再取得対象を決めるクロール需要の要因を解説します（常設の注意書き：「これはシステムについての私の理解であり、100%完全または正確ではありません。」）。

業界の資料

• Crawling December：HTTPキャッシュ （Google Search Central）— サイト所有者へキャッシュを有効にするよう求めるGary Illyesの記事で、採用率低下の統計の出典です。
• GooglebotはETagヘッダーを使うか （Dave Smart）— Googlebotの条件付きリクエストを実サーバーログで調べた稀な研究です。
• Googleがクローラーのキャッシュ制御ヘッダー処理を明確化 （Barry Schwartz、Search Engine Land）— 2024年12月の文書更新とETag／Last-Modifiedの引用を扱います。
• Googleの更新クローラー指針がETagを推奨 （Roger Montti、Search Engine Journal）— GoogleがETagを好む理由と、クローラーごとにキャッシュ利用が異なる点を説明します。
• Live Searchのクローラー改善を発表 （Fabrice Canel、Bing Webmaster Blog）— 2008年のRFC-2616準拠条件付きGET発表とサンプルを扱います。
• bingbotシリーズ：クロール効率を最大化する （Bing Webmaster Blog）— 変更のない再クロールが指標を下げるBingの「クロール効率」を説明します。
• MDN：HTTP条件付きリクエスト （Mozilla）— バリデーターと304の仕組みを確認できる中立的な仕様資料です。

自分で確認：条件付きリクエスト

ETag、If-Modified-Since、304 Not Modifiedについての短い5問です。各問の答えを選んでから確認してください。

変更履歴