SEO のキャッシュ

TL;DR — キャッシュとは、ページやファイルのコピーを保存し、毎回ゼロから作って送らなくて済むようにすることです。人にも検索ボットにもサイトを速くし、変わっていないページの再ダウンロードをボットが省けるようにします。キャッシュだけでランキングが上がるわけではありません。しかし速度とクロール効率を通じて、どちらも間接的に役立ちます。

キャッシュとは

誰かがページを開くたび、サーバーはHTMLを作り、画像を送り、CSSとJavaScriptを配信しなければなりません。キャッシュはそれらの完成済みコピーを保存し、次の訪問で同じ作業をせず再利用できるようにします。

SEOに関係するコピーの保存場所は3つあります。

1. ブラウザーキャッシュ — 訪問者自身の端末に保存されるファイルです。2回目のページ表示や再訪では、ほぼ瞬時に読み込めます。
2. CDN（エッジ）キャッシュ — 世界中に分散したサーバーに保存されるコピーです。1台のオリジンサーバーではなく、ユーザー（またはボット）に物理的に近い場所からファイルを配信できます。
3. クローラー自身のキャッシュ — GooglebotとBingbotは前回からページが変わったかを記録し、変わっていなければ再ダウンロードを省きます。

SEOに重要な理由

理由は2つあり、分けて考える価値があります。

• 速度。 配信が速いほどCore Web Vitalsに役立ちます。特にサーバーの応答速度（TTFB）と主要コンテンツの表示速度（LCP）です。速度はGoogleのページエクスペリエンスシグナルの一部です。
• クロール効率。 ページが変わっていないとボットが分かれば、ダウンロードを無駄にしません。大規模サイトでは、ボットが新規・更新ページに時間を使えるようになります。

まず正しく理解すること

「Googleのキャッシュ」と「HTTPキャッシュ」は別物です。 古いcache:検索演算子、つまり「Googleが保存したページのコピーを見る」機能は2024年に廃止されました。この記事で扱うキャッシュとは無関係です。Cache-ControlとETagヘッダーは今も有効で重要です。Googleにページの「キャッシュ版」がないことから、キャッシュ設定が正しいかどうかは分かりません。

実際に行うこと

• 静的ファイル（画像、CSS、JavaScript、フォント）を長期間キャッシュする。
• 必要なときすぐ更新できるよう、バージョン付きまたはハッシュ付きファイル名を使う。
• CDNを使い、ユーザーの近くからファイルを読み込む。
• 古い共有キャッシュがボットに誤った内容を配信しないようにする（危険な失敗モードです。AdvancedとAnti-patternsタブを参照）。

ヘッダーの詳細、Cache-Controlディレクティブ、ETagとLast-Modifiedの違い、CDNのクロール速度、クロールを壊すキャッシュミスまで知りたいなら、Advancedタブへ切り替えてください。

TL;DR — SEOに関係するキャッシュは、ブラウザー、CDNエッジ、クローラー自身の条件付きリクエストキャッシュという3層で機能します。ランキング要因ではありませんが、ページ速度（TTFB／LCP、bfcacheによる再ナビゲーションのCore Web Vitals）とクロール効率を動かします。GoogleのクローラーはLast-ModifiedよりETagを優先し、max-ageを再クロールのヒントとしてだけ読みます。公式文書によれば*“other HTTP caching directives aren’t supported.”* (翻訳) 「その他の HTTP キャッシュディレクティブはサポートされません」です。CDNはキャッシュが温まった後に高いクロール速度の許容量を得ます。本当のリスクは、冷えたキャッシュの公開やボットを完全にブロックするCDN／WAFの設定ミスです。

キャッシュの3層

SEOにおけるキャッシュは1つではなく、少しずつ制御方法が異なる3つです。

1. ブラウザーキャッシュ — 訪問者の端末がファイルを保存し、再表示でネットワークを省きます。PageSpeed Insightsが「効率的なキャッシュポリシーで静的アセットを配信」と指摘するのはこれです。
2. CDN／エッジキャッシュ — コンテンツ配信ネットワークが世界中のエッジノードにコピーを保存します。Google自身の説明では、CDNはオリジンとユーザーの間の仲介者で、歴史的に”biggest focus is caching” (翻訳) 「最大の焦点はキャッシュです」 でした。URLの内容を保存し、しばらくサーバーが再配信せずに済むようにします。
3. クローラー側キャッシュ — GooglebotとBingbotが条件付きリクエストでコンテンツの変更を記録します。これはクロールバジェットのレバーで、仕組みは条件付きリクエストの記事に譲り、ここでは概要に留めます。

上で「ブラウザーキャッシュ」と呼んだものは、複数の仕組みをまとめた言い方です。MDNのHTTPキャッシュガイド で知っておくべきなのは、プライベートHTTPキャッシュ（ブラウザーごと、リクエスト単位でキー化され、現代のブラウザーではサイトをまたぐトラッキングを制限するためトップレベルサイトで分割）、現在のセッションに使うメモリ内キャッシュ、以下で扱うbfcache、そして別物としてサイト自身のJavaScriptが制御するサービスワーカーのCache Storageです。Cache-Controlヘッダーは直接管理しません。「ブラウザーキャッシュを確認する」は、どの仕組みが問題かで4通りのデバッグを意味します。

キャッシュがCore Web Vitalsに効く理由

ネットワーク経由のリソース取得は遅く、コストもかかります。キャッシュは変わっていないもののネットワーク遅延と転送コストをなくします。結果として、2つの指標に直接流れ込みます。TTFB（キャッシュ済みレスポンスならオリジンでの再生成を省く）とLCP（キャッシュ済みの画像／CSS／フォントが早く表示される）です。

重要なCache-Controlディレクティブ

Cache-Controlが主要なヘッダーです。知っておく価値があるものは次のとおりです。

• max-age=<seconds> — 新鮮なコピーが有効な期間。変更しないバージョン付きアセットには、ChromeのLighthouse文書が1年以上のキャッシュ を推奨します。例：Cache-Control: max-age=31536000。
• no-cache — 「キャッシュしない」ではありません。「保存するが、再利用前にサーバーで再検証する」という意味です。軽量な304フローは有効です。
• no-store — HTTPキャッシュにどのコピーも保存しない、という本当の意味です。一般的なプライバシースイッチではありません。RFC 9111によればブラウザー履歴を確実に消す方法ではなく、サービスワーカー自身のCache Storageについても何も述べません。
• public／private — CDNのような共有キャッシュがレスポンスを保存できるか、エンドユーザーのブラウザーだけが保存できるか。
• immutable — レスポンスが新鮮な間は再検証を完全に省きます。「決して古くならない」という意味ではなく、max-ageが切れれば通常の新鮮さのルールへ戻ります。
• must-revalidate — 時間軸の反対側で、レスポンスが古くなった後にだけ意味があります。古いコピーをそのまま配信せず、オリジンで再検証するようキャッシュに指示します。
• s-maxage、stale-while-revalidate、stale-if-error — CDNなど共有キャッシュ向けの細かな制御です（共有キャッシュ専用の新鮮期間、バックグラウンド取得中の限定的な古い再利用、オリジンエラー時の限定的な古い再利用）。サポートはブラウザー／CDNで異なるため、依存する前に確認します。なお、以下で見るように、Googleのクローラーはこの追加ディレクティブ群をどれも尊重しません。

バージョン付きファイル名でキャッシュを無効化する

積極的にキャッシュしながらすぐ更新する方法は、ファイル名にコンテンツハッシュを入れることです。style.x234dff.cssのようにします。URLがキャッシュキーなので、ファイルを変えるとURLも変わり、キャッシュは新バージョンをすぐ取得し、旧版は好きなだけキャッシュできます。Googleのweb.dev HTTPキャッシュガイド とBing自身のフロントエンドエンジニアリング記事 は同じパターンを説明しています。Bingはファイル内容をURLにハッシュし、“the URL acts as the cache key,” (翻訳) 「URL がキャッシュキーとして機能する」することでキャッシュを一貫させ、長い有効期間を可能にします。

bfcacheの落とし穴 — no-storeがひそかにCWVを損なう場所

見過ごされがちな問題です。back/forward cache（bfcache）は「戻る」でページを瞬時に復元します。bfcacheからの復元ではLCP／CLS／INPの測定を完全に省けるため、CrUXのフィールドデータには純粋なプラスです。しかしGoogleのbfcacheガイド によれば、ページ文書そのものにCache-Control: no-storeを設定すると、歴史的にブラウザーがそのページをbfcacheへ保存しなくなりました。HTML文書を新鮮に保ちつつ戻る／進むキャッシュの適格性を失いたくないなら、no-storeではなくno-cacheまたはmax-age=0を使います。

キャッシュが「十分に新鮮」と判断する方法

バリデーターが関与する前に、キャッシュは新鮮さを確認します。保存したレスポンスの経過時間が、Cache-Controlで与えられた新鮮期間を過ぎたか（明示的な期間がなければ、キャッシュが推測できるヒューリスティック期間を過ぎたか）を調べます。Ageレスポンスヘッダーは共有キャッシュがレスポンスを保持している時間を示すため、DevToolsやCDNログから残りの新鮮期間を判断できます。新鮮ならキャッシュはリクエストなしですぐ再利用できます。古ければ再利用前に検証すべきで、そこでETag／If-None-MatchとLast-Modified／If-Modified-Sinceが役立ちます。次に説明するGooglebot版の狭い仕組みの前提となる、一般HTTPの挙動です。

Googlebotがキャッシュを使う方法（クロール効率の観点）

Googleは2024年12月のCrawling December: HTTP caching 記事で、変更されていないページの再ダウンロードをクローラーが省けるよう、キャッシュを有効にしてほしいと異例なほど直接的に求めました。印象的なデータは、キャッシュ可能な取得が減少していることです。10年前は全取得の約0 026%がキャッシュ可能で、現在は0 017% でした。小さな数字ですが、Googleは明らかに反転を望んでいます。

ETagとLast-Modified — Googleが好むもの

Googleのクロール基盤は、2つの標準バリデーターをサポートします。ETag（If-None-Match）とLast-Modified（If-Modified-Since）です。Googleは、ETagの値が構造化されておらず日付文字列より解析ミスが起きにくいため、ETagを強く推奨 します。“We strongly recommend using ETag” (翻訳) 「ETag の使用を強く推奨します」。両方ある場合、HTTP標準どおりクローラーはETagの値を使います 。CMSなど他のアプリケーション が使うため、両方設定することもGoogleは勧めています。Last-Modifiedを使うなら、日付はHTTP形式（例：Fri, 4 Sep 1998 19:15:56 GMT）でなければ解析されません。

クローラーが保存したバリデーターと一致すると、サーバーは本文なしの304 Not Modifiedを返します。それが目的です。Google の説明どおり、“If the ETag value sent by the crawler matches” (翻訳) 「クローラーが送った ETag の値が一致すると」、本文がなければサーバーはコンテンツ生成 に計算資源を使わず、転送帯域も使いません。（304の仕組みは条件付きリクエストの記事で詳しく扱います。ここでは存在し、双方のコストを節約することを知れば十分です。）

ほとんどの人が見落とすニュアンス

Googleのクローラーは、ブラウザーやCDNと同じように完全なCache-Controlディレクティブ群に従うわけではありません。公式クローラー概要によれば、ETag／Last-Modified以外の”other HTTP caching directives aren’t supported.” (翻訳) 「その他の HTTP キャッシュディレクティブはサポートされません」 （その他のHTTPキャッシュディレクティブはサポートされない）ということです。部分的な例外は、URLをいつ再クロールするかの判断に役立つよう、任意でmax-ageを設定できる ことです。これは強制ロックではなく再クロールのヒントです。no-cache、s-maxage、stale-while-revalidateなどはブラウザーとCDNの動作を形作りますが、Googlebotのキャッシュ方法は変えません。無効化についてのGoogleの助言は合理的です。大きな変更では キャッシュ更新を要求し、フッターの著作権年だけの更新は大きな変更ではありません。

CDNとクロール

CDNがもたらすのは速度だけではありません。Googleのクロール基盤は、“Our crawling infrastructure is designed to allow higher crawl rates” (翻訳) 「Google のクロール基盤はより高いクロール率を許可するよう設計されています」 を許容するよう設計されています。URLを配信するIPアドレスから推測し、CDN背後のオリジンはより多くの同時リクエストを処理できると仮定します。

ただし、計画すべき落とし穴は冷えたキャッシュです。URLへの最初のアクセスでは、“the CDN’s cache is “cold"" (翻訳) 「CDN のキャッシュは「冷えた」状態です」 です。まだ誰もリクエストしていないため、オリジンはキャッシュを温めるため少なくとも1回配信しなければなりません。Googleは、多数のURLを同時公開するとクロールバジェットに本当の負荷がかかり、数日間クロール速度が高くなると警告します。大規模な公開やサイト移行では、CDNが助け始める前にURLごとオリジンが全負荷を受けることを予算化します。

CDNの設定ミスはクロールのリスク

キャッシュに隣接する最も怖い問題は、キャッシュ期間が短いことではなく、ボットをブロックするCDNとWAFの設定です。GoogleのCDN記事は、一時的なブロックには”HTTP 503/429 status codes” (翻訳) 「HTTP 503／429 ステータスコード」 だと明記しています。一方、ネットワークタイムアウトは、URLをインデックスから削除させる可能性のある終端の「hard」エラーとして扱われます。微妙なのはソフトブロック、つまりボット確認のインタースティシャルです。クローラーにはサイトではなくチャレンジページしか見えないため、自動クライアントには代わりに”In case of these bot-verification interstitials” (翻訳) 「このようなボット検証インタースティシャルの場合」 します。CDNがGoogleをひそかにブロックしていないかの”the easiest way to check if things are working correctly” (翻訳) 「正しく動作しているかを確認する最も簡単な方法」 はSearch ConsoleのURL Inspectionです。レンダリング画像を確認し、ボットチャレンジや空ページならCDNに相談します。

リダイレクトをCDNへオフロードする技術は、私が気に入っている方法です。Marketing Speakポッドキャストでは、**“One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.”* (翻訳) 「個人的なお気に入りの一つで、十分に使われていないと思うのは、リダイレクトを CDN レベルへオフロードすることです。」*（個人的なお気に入りの1つで、十分に使われていないと思うのが、リダイレクトをCDNレベルへオフロードすること）と話しました。引用箇所へ

クロールとインデックス登録を損なうキャッシュの落とし穴

これは「SEOのキャッシュ」記事の多くが飛ばす角度です。キャッシュは速くするだけではありません。誤ったキャッシュはボットに誤ったバイト列を配信し、クロールやインデックス登録を壊します。

実例：共有キャッシュがブロックするrobots.txtを配信。 テスト環境と本番環境の間にある共有CDNキャッシュが原因で、Googlebotが断続的にブロックされたケースを調べました。Indexed, though blocked by robots.txt で書いたように、**“One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.”* (翻訳) 「テスト環境と本番環境の間の共有キャッシュが原因かもしれません。テスト環境のキャッシュが有効なとき、robots.txt にブロックディレクティブが含まれる可能性があります。」*（原因の1つはテスト環境と本番環境の共有キャッシュかもしれない。テスト環境のキャッシュが有効なとき、robots.txtにブロックディレクティブが含まれる可能性がある）。修正はキャッシュを分けるか、テスト環境では.txtファイルをキャッシュから除外することです。キャッシュ設定の誤りが直接クロール障害を引き起こしました。実際に痛手となるリスクはこの種類です。

同じ系統の落とし穴はほかにもあります。

• 古いCDNキャッシュがボットに古いコンテンツを配信する。 エッジキャッシュが変更公開後も古い版を保持すると、ボットは古い版を見続けます。公開時にパージするか、ページが実際に変わる頻度にキャッシュ期間を合わせます。
• Vary／User-Agentによるキャッシュ分断。 共有キャッシュのキーは通常URLだけですが、VaryはUser-AgentやAccept-Languageなどのリクエストヘッダーをキーに加え、異なる派生を別々に保存します。レスポンスを変えるヘッダーを漏らすと、あるリクエスターが別の派生を受け取ります。モバイル／デスクトップやボット／人の取り違えです。Varyにヘッダーを増やしすぎると、ほぼ重複するキーが増えてヒット率がほとんど改善しません。さらに現代のブラウザーはプライバシーのためトップレベルサイトで自身のキャッシュも分割します。あるサイトに埋め込まれたリソースは、別サイトの埋め込みでは通常再利用されません。これはVaryとは別の仕組みなので、「なぜキャッシュされないのか」を調べるときに混同しないでください。

期間についての私の一般的な目安はLCPの仕事から来ています。AhrefsのLargest Contentful Paintガイドで、“Your cache time should be as long as you are comfortable with”* (翻訳) 「キャッシュ期間は、自分が安心できるだけ長くすべきです。」*（キャッシュ期間は安心できる限り長くすべき）と書きました。また、“An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.”* (翻訳) 「理想的な設定は長期間キャッシュし、ページを変更したときにキャッシュをパージすることです。」*（理想は非常に長くキャッシュし、ページを変更したときにキャッシュをパージすること）です。長いキャッシュと即時パージ。この組み合わせで速さと新鮮さを両立できます。引用箇所へ

キャッシュはランキング要因か

いいえ、直接ではありません。ETagを設定したことや良いCache-Controlポリシー自体にランキングシグナルはありません。キャッシュが行うのは、可視性に関係する2つ、ページ速度／Core Web Vitals（明示的なページエクスペリエンス入力）とクロール効率（新規・更新コンテンツが発見・更新される速度を左右し、鮮度が重要な結果に間接的に触れる）を支えることです。サイトを速くクロールしやすくするために設定し、直接ランキングが上がるとは期待しません。

AI要約

Advanced版を圧縮すると、次のようになります。

• SEOのキャッシュ＝3層。 ブラウザーキャッシュ、CDN／エッジキャッシュ、クローラー自身の条件付きリクエストキャッシュ。それぞれ少しずつ制御方法が異なります。
• ランキング要因ではない。 ただしページ速度（TTFB／LCP、bfcacheによる再ナビゲーションのVitals）とクロール効率という、重要な2つを動かします。
• Cache-Controlの基本： max-ageは新鮮さを設定（変更しないバージョン付きアセットは1年以上）。no-cacheは「保存して再検証」（「キャッシュしない」ではない）、no-storeは保存しない、public／privateは共有／CDNキャッシュを制御します。
• キャッシュ無効化： ファイル名にコンテンツハッシュを入れ、積極的にキャッシュしながらすぐ更新します（GoogleとBingがこのパターンを使う）。
• bfcacheの落とし穴： HTML文書のCache-Control: no-storeはページを戻る／進むキャッシュから除外し、CrUXのVitalsをひそかに損なう可能性があります。代わりにno-cacheまたはmax-age=0を使います。
• Googlebotが尊重するのはETagとLast-Modifiedだけ。 ETagを優先し、max-ageは再クロールのヒントとして読む。Googleによれば*“other HTTP caching directives aren’t supported.”* (翻訳) 「その他の HTTP キャッシュディレクティブはサポートされません」です。一致したバリデーターは本文なしの304 Not Modifiedを返し、計算資源と帯域を節約します。
• CDNは高いクロール速度の許容量を得る。 ただしキャッシュが温まった後だけです。冷えたキャッシュの公開ではURLごとにオリジンへ1回届くため、大規模公開や移行で計画します。
• 最大のリスクは遅いキャッシュではない。 ボットをブロックするCDN／WAF設定ミス（短時間のブロックは503／429を返す。ソフトブロックのインタースティシャルに注意）と、誤った内容を配信する古い／共有キャッシュ（ブロックするrobots.txtなど）です。

公式ドキュメント

検索エンジンと、そのツールチームによる一次資料です。

Google

• Crawling December：HTTPキャッシュ — Gary Illyesによる2024年12月の記事。ETagとLast-Modified、304の仕組み、減少するキャッシュ可能取得の統計、max-ageの再クロールヒント。
• Google Crawler（ユーザーエージェント）概要 — HTTPキャッシュ — ETagの優先ルールと「other HTTP caching directives aren’t supported」の文言を含む最新リファレンス。
• Crawling December：CDNとクロール — CDNキャッシュ、高いクロール速度の許容量、冷えたキャッシュの公開、ハード／ソフトブロックについてのSplittとIllyes。
• 効率的なキャッシュポリシーで静的アセットを配信 — Lighthouse／PageSpeed監査と、変更しないアセットは「1年以上」という指針。
• HTTPキャッシュで不要なネットワークリクエストを防ぐ — ディレクティブのリファレンスとハッシュ付きファイル名による無効化。
• Back/forward cache（bfcache） — HTML文書のno-storeがbfcache適格性を失わせる理由。
• Crawling Decemberシリーズの一覧 — Googlebot、HTTPキャッシュ、ファセットナビゲーション、CDNを扱う2024年シリーズ全体。

Bing／Microsoft

• Microsoft Bingの高速フロントエンドパフォーマンス — 一貫性と長い有効期間のためファイル内容をURLへハッシュするBingのエンジニアリングチーム、静的アセット配信を速めるCDNの役割。
• bingbotシリーズ：クロール効率の最大化 — キャッシュが支えるクロール鮮度の考え方（変わっていないときはクロールを減らす）。
• Bing Webmasterガイドライン — BingのCDN／パフォーマンス指針のハブ。

ソースからの引用

Googleと私自身の執筆による公式発言です。各リンクは引用箇所へ移動するディープリンクです。

Google — Crawling December：HTTPキャッシュ

• “While Google’s crawling infrastructure supports heuristic caching mechanisms, in fact always had, the number of requests that can be returned from local caches has decreased: 10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%.” (翻訳) 「Google のクロール基盤はヒューリスティックなキャッシュ機構をサポートしており、実際に以前からそうでしたが、ローカルキャッシュから返せるリクエスト数は減っています。」 引用箇所へ
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). And, if you have the option, set them both: the internet will thank you. Maybe.” (翻訳) 「ETag の使用を強く推奨します。」 引用箇所へ
• “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.” (翻訳) 「コンテンツに重要な変更があったらキャッシュ更新を必須にすることを推奨します。」 引用箇所へ

Google — クローラー概要（HTTPキャッシュ）

• “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 の値を使います。」 引用箇所へ
• “Other HTTP caching directives aren’t supported.” (翻訳) 「その他の HTTP キャッシュディレクティブはサポートされません。」 引用箇所へ

Google — Crawling December：CDNとクロール

• “Historically, CDNs’ biggest focus is caching, meaning that once a user requested a URL from your site, CDNs will store the contents of that URL in their caches for a time so your server doesn’t have to serve that file again for a while.” (翻訳) 「歴史的に、CDN の最大の焦点はキャッシュです。」 引用箇所へ

Patrick Stox — キャッシュとCDNについて

• “Your cache time should be as long as you are comfortable with.” (翻訳) 「キャッシュ期間は、自分が安心できるだけ長くすべきです。」 — AhrefsのLargest Contentful Paintガイドにおける私の言葉。 引用箇所へ
• “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (翻訳) 「テスト環境と本番環境の間の共有キャッシュが原因かもしれません。」 — 共有キャッシュが原因だった実際のクロール障害についての私の記述。 引用箇所へ
• “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (翻訳) 「個人的なお気に入りの一つで、十分に使われていないと思うのは、リダイレクトを CDN レベルへオフロードすることです。」 — Marketing Speakポッドキャストでの発言。 引用箇所へ

SEOのキャッシュ — チートシート

Cache-Controlディレクティブを読み解く

Googlebotが実際に尊重するもの

• ✅ ETag＋If-None-Match（Googleが推奨するバリデーター）
• ✅ Last-Modified＋If-Modified-Since（HTTPどおり日付をFri, 4 Sep 1998 19:15:56 GMT形式にする）
• ✅ max-age — ただしルールではなく再クロール時期のヒントとしてだけ
• ❌ それ以外すべて — “other HTTP caching directives aren’t supported” (翻訳) 「その他の HTTP キャッシュディレクティブはサポートされません」

早わかり

• GoogleはETagを優先します。両方あればETagが勝ちますが、両方設定します（CMSが使うため）。
• 一致するバリデーター → 本文なしの304 Not Modified → 計算資源と帯域を節約。
• Chrome／Lighthouse：変更しないアセットは1年以上キャッシュ。
• CDNは高いクロール速度の許容量を得ますが、キャッシュが温まった後だけです。
• 一時的なブロック？ 黙って200＋エラーやボットインタースティシャルではなく、503／429を返します。
• HTML文書のno-storeはbfcacheの資格を失わせる可能性がある → no-cache／max-age=0を使う。
• 「Googleのキャッシュ」（cache:演算子）は2024年に廃止。HTTPキャッシュとは無関係。

キャッシュの神話と間違い

それぞれ、なぜ誤りか、代わりに何をするかを説明します。

神話：「ページをキャッシュすればランキングが上がる」。 なぜ誤りか： キャッシュ設定にランキングシグナルはありません。GoogleのSearch Relationsチームは、キャッシュがランキング要因ではないと明確にしています。 代わりに： 本当の利益、つまりページ速度／Core Web Vitalsとクロール効率のためにキャッシュを設定します。どちらも可視性に間接的に触れます。直接の上昇は期待しません。

神話：「GoogleのキャッシュとHTTPキャッシュは同じ」。 なぜ誤りか： cache:検索演算子とキャッシュページビューアーはユーザー向けのスナップショット機能で、2024年に完全廃止されました。HTTPキャッシュ（Cache-Control／ETag）は別のインフラです。 代わりに： 「キャッシュ版」がないことは無視します。ヘッダーとクロール／パフォーマンスの挙動でキャッシュを評価します。

神話：「no-cacheはキャッシュしないという意味」。 なぜ誤りか： no-cacheは「保存するが、使う前にサーバーで再検証する」という意味です。304の再検証フローは有効です。本当に保存を防ぐディレクティブはno-storeです。 代わりに： 再検証しながら新鮮さを保ちたいならno-cacheを使います。決して保存してはいけない本当に機密なレスポンスだけにno-storeを使います。

神話：「キャッシュ期間を長くすると、Googleは永遠に古いコンテンツを見る」。 なぜ誤りか： Googleのクローラーはmax-ageに関係なく、再クロール時にETag／Last-Modifiedで検証します。max-ageは再クロールのヒントで、再取得を止めるロックではありません。 代わりに： 長くキャッシュし、大きなコンテンツ変更時には本当のキャッシュバスター（新しいETag／Last-ModifiedまたはURL）を起動します。Google自身の推奨どおりです。

神話：「CDNがクロールバジェットの問題を自動的に直す」。 なぜ誤りか： CDNが助けるのはキャッシュが温まった後だけです。オリジンはURLごとに少なくとも1回配信する必要があり、冷えたキャッシュの問題が残ります。設定ミスのCDNはクローラーをブロックし、悪化させます。 代わりに： 大規模な公開／移行ではオリジン負荷を計画し、CDNがボットをブロックしていないことを確認します（URL Inspectionを使い、一時ブロックには503／429を返す）。

神話：「設定したCache-ControlディレクティブはGooglebotのクロール方法を変える」。 なぜ誤りか： Googleの文書によれば、ETag／Last-Modified（と任意のmax-ageヒント）以外は*“other HTTP caching directives aren’t supported”* (翻訳) 「その他の HTTP キャッシュディレクティブはサポートされません」です。 代わりに： stale-while-revalidate、s-maxage、no-cacheなどでブラウザーとCDNを調整します。ただしGooglebotのキャッシュに影響させるにはETag／Last-Modifiedを使います。

キャッシュ設定：変更前と変更後

1. キャッシュポリシーのない静的アセット → PageSpeed警告が消える

• 変更前： Cache-Controlなしでstyle.cssを配信。Lighthouseが「効率的なキャッシュポリシーで静的アセットを配信」と警告し、再訪で再ダウンロード。
• 変更後： style.a1b2c3.cssに名前を変更し、Cache-Control: public, max-age=31536000, immutableで配信。再訪はダウンロードを省き、コンテンツ変更時は新しいファイル名で即時無効化。

2. 新鮮にしたいHTML文書 → bfcacheを失う

• 変更前： 新鮮さを強制するためHTMLにCache-Control: no-store。副作用でページがbfcacheから除外され、「戻る」ナビゲーションがLCP／CLS／INPを再測定し、CrUXのフィールドデータを悪化。
• 変更後： no-cache（またはmax-age=0）へ変更。新鮮さのため再検証しつつ、ページはbfcacheに適格なままで、再ナビゲーションは瞬時に復元。

3. ステージングと本番の共有キャッシュ → Googlebotが断続的にブロックされる

• 変更前： テスト環境と本番環境がCDNキャッシュを共有。テスト版が有効なとき、キャッシュされたrobots.txtにブロックディレクティブが入り、Googlebotが断続的に不要なDisallowを見る。
• 変更後： 環境間でキャッシュを分けるか、テスト環境のキャッシュから.txtファイルを除外し、本番のrobots.txtがステージングキャッシュから配信されないようにする。（これは私がIndexed, though blocked by robots.txt で書いた実例です。）

4. CDNの背後で大規模公開 → 予想外のクロール急増

• 変更前： CDNが負荷を吸収すると考え、50 000 URLを一度に公開。すべてのURLが冷えたキャッシュのミスとなり、オリジンが各URLを少なくとも1回配信するため、クロール速度が数日間高いまま。
• 変更後： 公開前にキャッシュを温める（または段階公開）うえで、CDNが遮蔽し始める前にオリジンがURLごと全負荷を受けることを予想し、容量を確保する。

HTTPキャッシュ設定チェックリスト

• 静的アセット（画像、CSS、JS、フォント）に長いmax-ageがある（変更しない／バージョン付きファイルは1年以上）。
• バージョン付き／ハッシュ付きファイル名を使い、積極的にキャッシュしながらすぐ無効化できる。
• ETagを設定（Googleが推奨するバリデーター）。Last-Modifiedも正しいHTTP日付形式で設定する。
• バリデーターが一致したとき、サーバーが本文なしの304 Not Modifiedを返す。
• 新鮮さが必要なHTML文書はno-storeではなくno-cache／max-age=0を使う（bfcache適格性を守る）。
• 大きなコンテンツ変更で本当のキャッシュバスター（新しいETag／Last-Modified／URL）が起動し、フッターの日付だけを変えるのではない。
• オリジンの前にCDNがあり、共有すべきものを共有キャッシュが保存できるようpublic／s-maxageを設定する。
• 公開時にキャッシュをパージし、ボットが古いコンテンツを受け取らない。
• ステージングと本番でrobots.txtや他の制御ファイルのキャッシュを共有しない。
• 一時ブロックは、黙った200＋エラーページやボットインタースティシャルではなく503／429を返す。
• Search ConsoleのURL Inspectionがチャレンジや空ページではなく実ページを表示し、CDN／WAFがGooglebotをブロックしていないことを確認する。

更新したファイルがデプロイ後も古いまま

症状： 訪問者が古いCSS、JavaScript、画像を受け取り続ける。主な原因： 長期間のキャッシュが変わったバイト列に同じURLを使っている。修正： コンテンツハッシュ付きファイル名で変更しないアセットを公開し、HTMLの参照を更新する。URL自体を再利用した場合だけ古いエッジオブジェクトをパージする。新URLが読み込まれることを確認する。

Googlebotが変わっていないページを再ダウンロードする

症状： 変わっていないHTMLに対する完全な200レスポンスがログに繰り返し現れる。主な原因： ETag／Last-Modifiedバリデーターがないか不安定。修正： 安定し、コンテンツに正しいバリデーターを出し、条件付きリクエストをテストする。表現が変わっていなければ、再検証は304を返します。

異なるユーザーが誤ったキャッシュ派生を受け取る

症状： 言語、端末、ログイン状態、パーソナライズされたコンテンツがユーザー間で漏れる。主な原因： 共有キャッシュキーにレスポンスを変える次元が含まれていない、またはプライベートコンテンツをpublicにした。修正： キャッシュキーとVaryの動作を直し、プライベートなレスポンスを適切に印付けし、汚染されたオブジェクトをパージし、複数の派生を再テストする。

CDNキャッシュがヒットを報告しない

症状： ヒットするはずの再リクエストがオリジンへ到達し続ける。主な原因： no-store／private、Cookie、細かすぎるキャッシュキー、またはエッジのバイパスルール。修正： レスポンスとCDNのcache-statusヘッダーを確認し、そのコンテンツ種別で安全なルールだけを変更する。同じキャッシュキーを2回リクエストしてヒットを確認する。

ファイル拡張子だけでなく表現のリスクでキャッシュする

ポリシーを割り当てる前に、すべてのレスポンスを分類します。

1. 変更しない公開アセット： コンテンツハッシュ付きCSS、JS、フォント、画像は、変更されたバイトに新しいURLが付くため長い期間を使えます。
2. 公開だが変化する文書： HTMLは短く保存するかETag／Last-Modifiedで再検証します。最大TTLより新鮮さと速い修正が重要です。
3. ユーザー固有のレスポンス： パーソナライズを表現から取り除くかキャッシュキーで正しく分けない限り、共有キャッシュは安全ではありません。
4. 機密レスポンス： コンテンツを公開するより、性能上のトレードオフを受け入れてデータに必要な厳格なポリシーを使います。

役立つ問いは「この種類をどれだけ長くキャッシュできるか」ではありません。「この変更後、この正確な表現がこのリクエスターに再利用されたら、何が間違うか」です。

新鮮さ、正確さ、効率

キャッシュポリシーは3つのテストに合格しなければなりません。新鮮さ（約束したときに変更が現れる）、正確さ（正しいリクエスターが正しい派生を受け取る）、効率（変わらないバイトを無駄に再生成・転送しない）です。誤ったレスポンスを配信するなら、高いヒット率でも成功ではありません。

HTTPキャッシュを調べるツール

• ブラウザーDevToolsのNetworkパネル — Cache-Control、ETag、Last-Modified、Age、Vary、レスポンスがメモリ、ディスク、ネットワークのどこから来たかを確認。
• curl — ブラウザーキャッシュの曖昧さなしにHEADと条件付きリクエストを送り、初回バリデーターとIf-None-MatchまたはIf-Modified-Sinceを比較。
• PageSpeed Insights／Lighthouse — 非効率なキャッシュポリシーの静的アセットを発見。記事には公式のLighthouseキャッシュポリシー指針 へのリンクがあります。
• CDNアナリティクスとログ — 公開レスポンスを実際に配信する層で、ヒット／ミス／バイパス、キャッシュキー、オリジンリクエスト、パージを確認。
• サーバーログ — 変わっていないページでGooglebotが完全な本文ではなく304再検証を受けていることを確認。

キャッシュ変更が機能することを証明する

条件付きリクエストテスト

実行するテスト： レスポンスを取得してETagをコピーし、If-None-Matchを付けてリクエストする。期待結果： 変わっていない表現が本文なしの304を返す。失敗の解釈： バリデーターが欠落、不安定、または無視されている。監視期間： 直ちに。ロールバック条件： 変更済みコンテンツに誤って304を返す、または派生間でバリデーターが衝突する。

バージョン付きアセットテスト

実行するテスト： 変更したバイトを新しいコンテンツハッシュURLでデプロイし、それを参照するページを再読み込みする。期待結果： 新URLが新しいアセットを返し、旧URLはキャッシュに残れる。失敗の解釈： HTMLがまだ旧アセットを参照するか、ビルドでハッシュが変わっていない。監視期間： HTML／CDN伝播直後。ロールバック条件： 新アセットでスタイルが壊れる、またはスクリプトエラーが出る。

共有キャッシュ派生テスト

実行するテスト： CDNを通して意味のあるすべての派生をリクエストし、それぞれを繰り返し、本文、キャッシュキー／ステータス、Varyを比較する。期待結果： 各リクエスターが正しい表現を受け取り、安全な派生だけが再利用される。失敗の解釈： キャッシュキーに次元がない、またはプライベートコンテンツが共有されている。監視期間： 直ちに、さらに本番ログを確認。ロールバック条件： あるユーザーが別ユーザーのパーソナライズ済み、または言語固有のレスポンスを受け取る。

自分で確認：SEOのキャッシュ

HTTPキャッシュ、CDN、クロールについての簡単な5つの質問です。それぞれ答えを選んでから、確認してください。

変更履歴