CDN と SEO

TL;DR — CDN（コンテンツ配信ネットワーク）は世界中に分散したサーバー群で、ページのコピーを保持し、各訪問者に近い場所から配信します。そのためサイトは速く、信頼性も高くなります。CDN自体がランキングを直接押し上げるわけではありませんが、速く信頼できるサイトはGoogleが実際に測定する要素を助けるため、通常は有利です。CDNがSEOを損なう主な原因は、検索エンジンのボットを誤ってブロックすることです。これは修正できます。

CDNとは

通常、サイトの各訪問者は、物理的にどこにあるかにかかわらず、1台のサーバー、つまりオリジンへ接続します。世界の反対側にいる人は、データが遠くまで移動するため、リクエストごとに長く待つことになります。

CDNは、コンテンツのコピーを異なる場所にある多数のサーバー（エッジサーバー）へ置くことでこれを解決します。訪問者にはオリジンではなく最寄りのサーバーから配信されます。訪問者には速く、オリジンサーバーの負荷も減ります。Cloudflare、Fastly、Akamai、Amazon CloudFront、Bunnyなどが一般的な例です。

CDNはSEOに役立つか？

短く言えば、CDN自体はランキング要因ではありませんが、ランキングに関係する要素を助けます。 Googleは「CDNを使っている」ことに報酬を与えません。CDNがするのは次のことです。

• ページを速く読み込む — Googleが見るページ体験指標であるCore Web Vitalsを改善します。
• サイトを稼働させ続ける — CDNはトラフィック急増や短い障害の間もキャッシュ済みページを配信でき、攻撃も吸収します。
• 検索エンジンが少し速くクロールできるようにする — GoogleはCDNが背後にあると検出すると、サイトをどの程度強くクロールするかの上限を実際に引き上げます。

正確な捉え方は、CDNはSEOを支える優れたツールであって、魔法のランキングボタンではない、ということです。

CDNがSEOを損なう主な方法

CDNにはボット保護があり、大量の悪質なトラフィックをブロックします。しかし、ときにはその保護が良いボットまで捕らえ、GooglebotやBingbotが通過できない「人間であることを証明してください」というチャレンジに閉じ込められます。そうなるとGoogleはページを見られず、ランキングが下がる可能性があります。

良い知らせは、修正できることです。URL InspectionツールをGoogle Search Consoleで使えば、Googleが見る形のページを確認できます。Googleにコンテンツではなく空白ページ、エラー、ボットチャレンジが見えているなら、CDNがブロックしています。あなたまたはCDNプロバイダーがファイアウォールルールを修正します。

ほかにも心配されることがありますが、多くは問題ではありません。

• 共有CDN IPアドレス（多くのサイトも使うもの）は問題ありません。GoogleのJohn Muellerは、自分専用のIPブロックを買う必要はないと述べています。
• CDNによる**「重複コンテンツのペナルティ」**は実在しません。最悪の場合でも、設定ミスによってGoogleがURLの誤った版を選ぶだけで、canonicalタグで直せます。ペナルティを恐れる必要はありません。

クロールバジェットと冷えたキャッシュ、ハード／ソフトのボットブロック、Googleの2024年12月の指針、HTTPSの落とし穴、エッジを通るcanonical化の詳しい説明は、Advancedタブへ切り替えてください。

TL;DR — CDNはリクエスト元それぞれに近いエッジサーバーからコンテンツをキャッシュして配信し、TTFBを短縮してCore Web Vitalsを改善し、稼働時間とフラッド保護を加え、Googleのクロールを速くします（CDN配下のサイトでは、配信IPから推測してクロール速度のしきい値を上げます）。ただしランキング要因ではありません。落とし穴はすべて運用にあります。冷えたキャッシュでは新しいURLごとにオリジンが少なくとも1回配信する必要があり、大規模公開ではクロールバジェットのコストになります。CDNのWAFやボット検証インタースティシャルはクローラーを黙ってブロックできます。これはCDNとSEOで最も大きな実世界の障害です。canonicalタグとHTTPS設定はエッジ層を通過しなければならず、Googleは2024年12月に、重要なJS／CSSをCDNサブドメインへ分割する方針を1週間未満で撤回しました（重要でない動画などの大きなアセットには引き続き使えます）。一次資料はGoogleの「Google の 2024 年 12 月 CDN・クロール記事」です。

CDNが実際にすること

CDNは、オリジンサーバーとURLを要求するすべての人（訪問者もクローラーも）の間に入る仲介者です。Google自身の2024年12月のGoogle の 2024 年 12 月記事記事は、CDNをオリジンサーバーとエンドユーザーの間の仲介者 と明確に説明しています。CDNは一部のファイルを代わりに配信し、歴史的にはキャッシュが最大の焦点でした。URLが要求されると、その内容をしばらく保存するため、サーバーは同じファイルを再配信せずに済みます。Googleは全体の目的を、サイトの遅延を減らすこと、つまり大きなトラフィック中でもコンテンツを速く届けることだとしています。

Martin SplittとGary Illyesによるこの1本の記事は、どちらの検索エンジンが公開したCDNとSEOに関する資料よりも権威があり、最新です。競合記事のほとんどは使っていません。以下のほぼすべてはこの資料に基づきます。

用語が曖昧に使われるため、CDNが何であるかを正確にしておく価値があります。CDNとは、オリジンとリクエスターの間にある、キャッシュ／配信ノードの分散エッジサーバートポロジーです。一般的なWebホスティングと同義ではなく、HTTPキャッシュ自体とも同義ではありません（どのサーバーやプロキシでもレスポンスをキャッシュできます）。Web Application Firewall保護とTLS終端もCDNの中核機能ではありません。多くのCDNベンダーが同梱するため用語が混ざりますが、エッジ配信の上に重なる別の機能です。

CDNはSEOに役立つか？正直な答え

CDNはランキング要因ではありません。 Googleが実際に重視する複数の要素に影響する、パフォーマンスと信頼性のレバーです。重要なのは3つです。

より速いTTFBとCore Web Vitals

近くのエッジキャッシュから配信すると往復時間が短くなり、Time to First Byte（TTFB）が下がります。TTFBは最大のCore Web VitalであるLCPの先端部分です。Googleの説明では、メディア、JavaScript、CSS、さらにはHTMLをCDNのキャッシュへオフロードするとサーバー負荷が減り、ユーザーのブラウザーでページが速く読み込まれ、コンバージョン向上と相関する とされています。これはCDNについて最も明確で防御しやすいSEOの主張です。このクラスターのcaching、resource hints、web performance toolsの関連記事とも重なります。CDNは悪いCWVやPageSpeedスコアを直す最大級のレバーです。 “Caching on the CDN” (翻訳) 「CDN 上のキャッシュ」

ただし、その効果には条件があります。リクエスト元の近くでキャッシュヒットすれば往復時間が短くなりますが、ミス、キャッシュされない個別化レスポンス、配置の悪いエッジノードではTTFBが変わらないか、かえってオーバーヘッドが増えます。CDNはあらゆる地域やリクエストでTTFBが下がることを保証しません。エッジが実際にレスポンスを配信できる場合に保証するだけです。

CDN配下サイトのクロール速度しきい値が高くなる

見過ごされがちな利点です。GoogleはURLを配信するIPからサーバーの余力を推測し、CDNに支えられたサイトでより高いクロール速度を許容する ようにクロール基盤を設計しています。CDN配下だと検出した場合、サーバーがより多くの同時リクエストを処理できると仮定するため、スロットリングのしきい値ははるかに高くなります。“The threshold for this throttling is much higher” (翻訳)「このスロットリングのしきい値ははるかに高い」。大規模または頻繁に更新されるサイトでは、より多くのページを速くクロールできる、文書化された本当の利点です。ただし保証内容を正確に捉えてください。これは推測された容量しきい値であり、クロールバジェット、インデックス登録、ランキングの約束ではありません。Googleはサイト固有のクロール需要シグナルに基づいて、その上限をどれだけ使うかを決めます。上限まで使われても、ランキングシグナルではなくクロールバジェットの効率向上です。

信頼性、稼働時間、フラッド保護

Googleはさらに2つの利点を挙げています。トラフィックフラッド保護では、CDNが過剰または悪意あるトラフィックを識別してブロック するのが得意で、悪質なボットがサーバーを過負荷にしてもサイトを使える状態に保ちます。信頼性では、サイトが停止していてもユーザーへ配信できるCDNがあります。少なくとも静的コンテンツだけでも、訪問者が離れるのを防ぐには十分な場合があります。CDNは保護されていないオリジンを数秒で停止させるマルチテラビット級のDDoSフラッドを自律的に検出・軽減しています。Googlebotへエラーを返す長期停止はインデックス上の損失になります。 “Traffic flood protection” (翻訳) 「トラフィックフラッド保護」

クロールバジェットの落とし穴：新しいURLの冷えたキャッシュ

ほぼすべての競合記事が見落とすニュアンスです。CDNがあるからといって、オリジンが新しいURLを配信しなくてよいわけではありません。URLへの最初のリクエストではCDNキャッシュが冷えています。まだ誰も要求していないためキャッシュされておらず、オリジンは温めるため少なくとも1回配信しなければなりません。Googleの例は百万超のURLを公開するWebショップです。CDN配下でも、サーバーは1 000 007個のURLを少なくとも1回配信する必要があります。これはクロールバジェットへの本当の負荷で、Googleはクロール速度が数日間急増する可能性を警告しています。

**実務上の要点：**新しいサイトセクション、移行、大規模な商品カタログなどを一度に多数のURLで公開するなら、初回クロールをオリジンが処理できるよう計画します。CDNが守るのは温まった後であり、温めている最中ではありません。これはsite migrationsで問題になる「負荷が実際にどこへかかるか」という考え方と同じです。

静的アセットをCDNサブドメインに置くべきか？

繰り返し出てくるアーキテクチャ上の問いは、CSS／JS／画像をcdn.example.comのような別ホスト名で配信するか、メインホストをCDNで支えるかです。Googleはどちらも機能し、クロール基盤はどちらの構成も問題なくサポートする と述べています。リソースを別ホスト名へ分けるとWeb Rendering Serviceが効率よくレンダリングできる場合がありますが、Google自身が、別ホスト名への接続オーバーヘッドでページパフォーマンスが低下する可能性 を注意点として挙げています。 “In the end, choose the solution that works best for your business” (翻訳) 「最終的には、ビジネスに最適な解決策を選ぶ」

ここでGoogleは1週間未満で公に方針を変えました。2024年12月3日の関連投稿は、クロールバジェットの懸念をリソースホストへ移すため別ホスト名でリソースをホストすること を最初に提案しました。3日後、別ホスト名への接続オーバーヘッドでページパフォーマンスが低下する可能性 があるため、JavaScriptやCSSのような重要な描画リソースには推奨しないという訂正を加えました。動画やダウンロードのような大きく重要でないアセットなら検討できます。メインホストをCDNで支えているなら、1つのホスト名だけを問い合わせ、重要なリソースをCDNキャッシュから配信できるため、トレードオフを避けられます。WRSはHTTPキャッシュヘッダーに関係なくJS／CSSを最大30日キャッシュ するため、リソース変更が遅れることにも注意してください。 “Host resources on a different hostname from the main site” (翻訳) 「メインサイトとは異なるホスト名でリソースをホストする」

CDNがSEOを損なうとき：ボットブロック（最大の実リスク）

現実のCDN／SEO問題の第1位は重複コンテンツではなく、CDNがクローラーを黙って締め出すことです。Googleはフラッド保護のため、サイトに来てほしいボットがCDNのブロックリストに入ることがある と率直に説明しています。通常はWeb Application Firewall（WAF）内で起き、サイトが検索にまったく出なくなる可能性があります。Googleは障害をハードブロックとソフトブロックに分けています。

ハードブロック — 返すステータスコードが極めて重要

• HTTP 503／429 — 一時的なブロックを伝える正しい方法です。インデックスから削除される前に対応する時間を稼げます。これを優先します。
• ネットワークタイムアウト — 悪い状態です。Googleはこれを終端の「ハード」エラー として扱います。結果がインデックスからの削除、クロール速度の低下、または両方になるかは、現在のHTTPステータスコードとネットワーク／DNSエラー の文書どおり、ステータス／ネットワークエラーの分類、継続時間、再発の有無に依存します。単発のタイムアウトは持続するパターンよりはるかに小さなリスクです。
• 200ステータスでランダムなエラーメッセージ（「ソフトエラー」）を返す — 最悪です。Googleがハードエラーと読めばURLを削除し、読めなければ同じエラー本文を共有する全ページを重複として排除する可能性があります。 “network errors are considered terminal” (翻訳) 「ネットワークエラーは終端エラーとして扱われる」

この結果の順位は、記事全体で最も実行しやすい要点です。きれいな503は「技術的には稼働している」200のエラーページより優れています。

ソフトブロック — ボット検証インタースティシャル

CDNが「人間ですか」というチャレンジを出すと、クローラーが見るのはページではなくそのインタースティシャルだけです。Googleの修正方法は明確です。ボット検証インタースティシャルには、503 HTTPステータスコードという明確なシグナルを送る ことを強く推奨し、自動クライアントへコンテンツが一時的に利用できないと伝えます。

デバッグ方法

Googleがハード／ソフト両方のブロックに勧める手順は、Search ConsoleのURL Inspectionツール を使い、レンダリング済みスクリーンショットを見ることです。ページが表示されれば問題ありません。空白、エラー、ボットチャレンジならCDNに相談します。次に公開IPレンジでクローラーを確認し、必要ならWAFルールからブロックIPを削除するか許可リストへ入れます。Googleは、IPが知らないうちに自動でブロックリストへ入ることがある と警告しているため、WAFのブロックリストを定期確認する価値があります。GoogleはGooglebotのIPレンジ を公開しており、Bingにも同等のものがあります。 “the easiest way to check if things are working correctly is to use the URL Inspection tool in Search Console” (翻訳) 「正常に動作しているか確認する最も簡単な方法は Search Console の URL Inspection ツールを使うこと」

これは、私がスタック全体で問題が壊れるのを見てきた場所でもあります。私のSMX Advanced 2018「Solving Complex SEO Problems」資料 では、DNS、CDN、ミドルウェア、サーバー、HTTPヘッダー、ロケールなど、ロジックが存在し得る層を示しています。CDNエッジもその1つです。ブラウザーとGooglebotでリダイレクトやブロックの挙動が違うとき、驚きの原因はエッジに隠れていることがよくあります。

CDNを通るキャッシュヘッダーとcanonical化

CDNによる重複コンテンツはペナルティではなく、管理可能なリスクです。実際に壊れる方法は次のとおりです。

• CDNがオリジンのcanonicalタグやヘッダーを反映せず独自ドメインから配信し、エッジURLが本来のURLと競合する。
• 複数リージョンのノードが適切なhreflangなしに地域ごとに異なるコンテンツを配信し、ページを地域版へ分割する。
• クエリ文字列やキャッシュキー処理がパラメーターによる重複を作る。

修正方法はcanonical化と重複コンテンツの記事が扱うのと同じ規律です。canonicalタグとヘッダーがエッジを完全に通過するようにし、CDNデプロイの前ではなく後に確認します。canonical化はシグナルの統合です。canonicalを削除または上書きするCDNは、誤った方向へ引っ張るもう1つのシグナルにすぎません。

ここで1つの神話を終わらせます。Varyヘッダーはキャッシュの正確性に関する懸念で、SEOシグナルではありません。Vary: User-Agentは、CDNが変化するレスポンスをキャッシュしない場合にキャッシュヒット率を壊すことがありますが、GoogleはVaryをモバイル／デスクトップのインデックスシグナルとして使いません。これは運用の問題であり、ランキングの問題ではありません。

CDNを通るHTTPS／TLS

CDNは暗号化に2つ目の区間を加えます。オリジン↔エッジとエッジ↔クライアントです。両方をHTTPSにする必要があります。典型的な設定ミスは「Flexible SSL」モードで、訪問者にはHTTPSが見えるのにCDNはオリジンへ平文HTTPで話します。CDN設定に埋め込まれたHTTP専用のアセットURLは混合コンテンツ警告を生みます。HSTSやCSPなどのセキュリティヘッダーもエッジを通過させます。HTTPSはそれ自体が軽量なランキングシグナルで、CDNはそれを誤って取り消しやすい場所です。URLを変えずにCDNを新設または切り替えるならホスティング変更として扱い、GoogleのWebホスティング変更 の指針に従います。

共有IPと、重要でないこと

• 共有CDN IPアドレスはランキング上の問題ではありません。 GoogleのJohn Muellerは、サイト所有者がIPアドレスブロックを人工的に買う必要はなく、他社と共有するCDN IPになるのは予想される正常な状態だと述べています。
• cdn.example.comと第三者CDNドメインの選択は、コンテンツがクロール可能である限り、SEOではなく技術／パフォーマンスの判断です。これはGoogleがどちらのホスト名構成もサポートしていることから直接導けます。

Bingの場合

BingにはGoogleほど詳しい「CDNとSEO」の単独解説はありませんが、同じ問題と修正方法が当てはまります。GoogleのWAF指針に直接対応するものとして、Bingは公式のBingbot IPレンジと検証ツールを公開しています。CDNやボット管理層の背後にいるサイト所有者が、許可リストや拒否リストに入れる前に本物のBingbotだと確認できるようにするためです。Verify Bingbot とVerify Bingbotツール を参照してください。MicrosoftはGoogleと同じく、BingbotのIPアドレス一覧をJSONファイルとして公開 しています。Bingの一般的な指針も最適化要素としてサイト速度を挙げ、読み込み時間を改善する戦術の1つにCDNを含めています。BingのFabrice Canelも、CDNやクラウドにキャッシュ・ホスティングされたコンテンツが、プラットフォームをまたぐ測定とコンテンツ管理に新しい課題を作ることを大枠で話しています。これはランキングの主張ではありませんが、運用上の現実を妥当に表します。

この記事の位置付け

CDNの判断はweb performanceクラスターのほぼすべてに触れます。CDNはcaching、resource hints、Core Web Vitals、TTFBのすべてに対する最大級のレバーだからです。クロール（crawl budget、冷えたキャッシュ）、インデックス登録（canonicalization、重複処理）、HTTPS、site migrationsにも及びます。繰り返すテーマは、canonicalタグ、HTTPS設定、クローラーアクセスをエッジ越しに保てるなら、CDNは重要なシグナルに対する素直な勝利になることです。保てなければ「コンテンツなしでインデックス登録」の主因になります。

AI要約

Advanced版を短くまとめると、次のとおりです。

• CDNはランキング要因ではない — TTFB → LCP／Core Web Vitals、稼働時間、HTTPS配信、クロール効率など、GoogleとBingが実際に使う要素を動かすパフォーマンス／信頼性のレバーです。
• GoogleはCDN配下サイトのクロール速度しきい値を上げる — 配信IPから推測される、大規模または頻繁に更新されるサイトの文書化された利点です。ただし推測された容量上限であり、クロールバジェット、インデックス登録、ランキングの保証ではありません。Googleが使っても、ランキングシグナルではなく効率向上です。
• 冷えたキャッシュの落とし穴： CDNは新しいURLごとに、温めるためオリジンが少なくとも1回配信することを避けません。大規模公開や移行では数日間クロールバジェットに大きな負荷がかかります。
• 重要なJS／CSSをCDNサブドメインへホスト名分割することは、今は推奨されない — Googleは2024年12月、追加ホスト名への接続オーバーヘッドを理由に1週間以内で自身の指針を撤回しました。大きく重要でない動画／ダウンロードなら引き続き使えます。
• 実世界で最大の障害は重複コンテンツではなくボットブロックです。ハードブロックは503／429なら良く回復可能、ネットワークタイムアウトは継続時間と頻度に応じて削除、クロール速度低下、または両方になり得る終端エラーです。200の「ソフトエラー」ページは最悪です。ソフトブロック（CAPTCHAインタースティシャル）はクローラーに503を返して修正します。
• デバッグはURL Inspectionのレンダリング済みスクリーンショット、GoogleとBingの公開IPレンジによるクローラー検証、WAFブロックリストの定期確認（IPが自動ブロックされる可能性があります）で行います。
• canonical化／重複は管理可能なリスクです（canonicalタグ／ヘッダーをエッジで保持し、クエリ文字列と複数リージョンのコンテンツを監視します）。VaryはSEOシグナルではなくキャッシュの懸念です。
• HTTPSはオリジン↔エッジとエッジ↔クライアントの両方を暗号化します。「Flexible SSL」の混合コンテンツを避けます。共有CDN IPはランキング上問題ありません（Muellerによる）。

公式ドキュメント

検索エンジンによる一次資料です。

Google

• Google の 2024 年 12 月記事：CDN とクロール （SplittとIllyes、2024年12月）— キャッシュ、フラッド保護、より高いクロール速度、冷えたキャッシュ、ハード／ソフトブロック、URL Inspectionのデバッグ手順を扱うCDN／SEOの一次資料。
• Googlebot のクロール方法と理由 （2024年12月3日、12月6日更新）— リソースのホスト名分割、重要なJS／CSSに関する12月6日の訂正、WRSによる30日間のリソースキャッシュ。
• HTTP ステータスコード、ネットワーク、DNS エラー — ハードブロック、タイムアウト、ソフトエラーの後に何がいつ起きるかの現在の文書。
• クロールバジェットを最適化する — CDN記事が参照するクロール容量の上限とスロットリングモデル。
• Web ホスティングを変更する — CDNの追加や切り替えに当たる「URL変更なし」のサイト移転。
• Googlebot の IP レンジ（googlebot.json） — Googlebotを検証し、WAFの誤ブロックを解除する公開IP。

Bing／Microsoft

• Verify Bingbot（ヘルプ） — CDNのWAFでクローラーを許可または拒否する前に、本物のBingbotか確認します。
• Verify Bingbot（ツール） — 公開の検証ツール。
• Bing Webmaster Guidelines — サイト速度の考慮事項を含む一般指針。

出典からの引用

Googleによる記録された発言です。各リンクは出典ページの引用箇所へ移動するディープリンクです。（BingとJohn Muellerの立場はAdvancedタブで要約しており、引用ではありません。以下の注意書きを参照してください。）

Google — CDNとは何か、なぜ役立つか

• “Content delivery networks (CDNs) are particularly well suited for decreasing latency of your website and in general keeping web traffic-related headaches away. This is their primary purpose after all: speedy delivery of your content even if your site is getting loads of traffic.” (翻訳) 「コンテンツ配信ネットワーク（CDN）は、サイトの遅延を減らし、ウェブトラフィックに関する問題を全般に遠ざけるのに特に適しています。結局のところ、サイトに大量のトラフィックが来てもコンテンツを速く届けることが主目的です。」 — Martin Splitt & Gary Illyes, Google Search Central Blog, Dec 2024. 引用箇所へ
• “CDNs are basically an intermediary between your origin server (where your website lives) and the end user, and serves (some) files for them.” (翻訳) 「CDN は基本的に、サイトが置かれているオリジンサーバーとエンドユーザーの間に入り、ファイルの一部を代わりに配信する仲介者です。」 引用箇所へ
• “Traffic flood protection: CDNs are particularly good at identifying and blocking excessive or malicious traffic, letting your users visit your site even when misbehaving bots or no-good-doers would overload your servers.” (翻訳) 「トラフィックフラッド保護：CDN は過剰または悪意あるトラフィックを識別・ブロックすることに特に優れ、問題のあるボットなどがサーバーを過負荷にしてもユーザーがサイトを訪問できるようにします。」 引用箇所へ
• “Reliability: Some CDNs can serve your site to users even if your site is down. This of course might only work for static content, but that might already be enough to ensure they don’t take their business somewhere else.” (翻訳) 「信頼性：サイトが停止していてもユーザーへサイトを配信できる CDN があります。もちろん静的コンテンツに限られる場合がありますが、それだけでもユーザーが別の場所へ移るのを防ぐには十分かもしれません。」 引用箇所へ

Google — クロール速度と冷えたキャッシュのコスト

• “Our crawling infrastructure is designed to allow higher crawl rates on sites that are backed by a CDN, which is inferred from the IP address of the service that’s serving the URLs our crawlers are accessing.” (翻訳) 「私たちのクロール基盤は、クローラーがアクセスする URL を配信するサービスの IP アドレスから CDN 配下だと推測されるサイトで、より高いクロール速度を許容するよう設計されています。」 引用箇所へ
• “In short, even if your webshop is backed by a CDN, your server will need to serve those 1,000,007 URLs at least once.” (翻訳) 「要するに、Web ショップが CDN 配下であっても、サーバーはその 1,000,007 個の URL を少なくとも 1 回は配信する必要があります。」 引用箇所へ

Google — ボットブロック（実世界で最大のリスク）

• “Due to the CDNs’ flood protection and how crawlers, well, crawl, occasionally the bots that you do want on your site may end up in your CDN’s blocklist, typically in their Web Application Firewall (WAF).” (翻訳) 「CDN のフラッド保護とクローラーの動作のため、サイトに来てほしいボットが CDN のブロックリスト、通常は Web Application Firewall（WAF）に入ってしまうことがあります。」 引用箇所へ
• “In case of these bot-verification interstitials, we strongly recommend sending a clear signal in the form of a 503 HTTP status code to automated clients like crawlers that the content is temporarily unavailable.” (翻訳) 「このようなボット検証インタースティシャルでは、コンテンツが一時的に利用できないことを明確に示すため、クローラーなどの自動クライアントへ 503 HTTP ステータスコードを返すことを強く推奨します。」 引用箇所へ
• “Remember that the IPs may end up on a blocklist automatically, without you knowing, so checking in on the blocklists every now and then is a good idea for your site’s success in search and beyond.” (翻訳) 「IP が知らないうちに自動でブロックリストへ入ることがあるため、時々ブロックリストを確認することは検索とその先でのサイトの成功に役立ちます。」 引用箇所へ

Google — ホスト名分割と12月6日の方針修正

• “Splitting out resources to their own hostname or a CDN hostname (cdn.example.com) may allow our Web Rendering Service (WRS) to render your pages more efficiently. This comes with a caveat though: this practice may negatively affect page performance due to the overhead of a connection to a different hostname.” (翻訳) 「リソースを独自ホスト名または CDN ホスト名（cdn.example.com）へ分けると、Web Rendering Service（WRS）がページをより効率的にレンダリングできる場合があります。ただし、別ホスト名への接続オーバーヘッドでページパフォーマンスが低下する可能性があります。」 引用箇所へ
• “Update on December 6, 2024: This can result in slower page performance due to the overhead of connection to a different hostname, so we don’t recommend this strategy for critical resources (such as JavaScript or CSS) that are needed for rendering a page.” (翻訳) 「2024 年 12 月 6 日の更新：別ホスト名への接続オーバーヘッドでページパフォーマンスが低下する可能性があるため、ページのレンダリングに必要な重要リソース（JavaScript や CSS など）にはこの戦略を推奨しません。」 引用箇所へ

CDNとSEOの監査 — チェックリスト

CDNがSEOを静かに損なわず、実際に助けていることを確認するための一巡です。

• クローラーアクセス： GSCのURL Inspectionで、レンダリング済みスクリーンショットに実ページが表示される（空白ページ、エラー、ボットチャレンジではない）。
• WAFブロックリストを確認： 誤ってブロックしたGooglebot／Bingbot IPを探し、Googleのgooglebot.jsonとBingの公開レンジで検証する。
• 一時ブロックは503／429を返す： ネットワークタイムアウトや200のエラーページは返さない。
• ボット検証インタースティシャルは自動クライアントに503を返す： コンテンツが自動的にインデックスから外れないようにする。
• canonicalタグ／ヘッダーがエッジを通過する： CDNデプロイの前ではなく、後に確認する。
• 両区間でHTTPS： オリジン↔エッジとエッジ↔クライアントをHTTPSにし、「Flexible SSL」の混合コンテンツをなくす。HSTS／CSPヘッダーを通す。
• 偶発的な重複URLがない： CDNドメイン、複数リージョンのコンテンツ、クエリ文字列／キャッシュキー処理による重複がなく、地域でコンテンツが変わるならhreflangも正しい。
• 大規模公開を冷えたキャッシュ前提で計画： オリジンが新しいURLごとの初回配信を処理できる。
• 重要なJS／CSSを別CDNサブドメインへ分割しない： Googleの2024年12月の訂正に従う。重要でない大きなアセットならサブドメインでよい。
• キャッシュヘッダー： クローラーに古い、または誤ったコンテンツを誤って配信せず、Varyがキャッシュヒット率を下げない。

メンタルモデル

1. CDNはシグナルではなくイネーブラー。 「CDNでランキングが上がるか」と尋ねるのをやめ、「どのシグナルを動かすか」と尋ねます。TTFB／CWV、稼働時間、HTTPS、クロール効率です。それらを最適化し、CDNは手段と捉えます。

2. エッジはロジックが存在するもう1つの層。 DNS、CDN、ミドルウェア、サーバー、HTTPヘッダー、ロケールのどこでも、リダイレクト、ブロック、ヘッダー書き換えが起こります。ブラウザーとGooglebotで挙動が違うときはエッジを疑います。

3. 温かいキャッシュと冷えたキャッシュ。 CDNが守るのは最初のヒットの後であり、その最中ではありません。新しいURLの冷えたキャッシュはオリジン容量とクロールバジェットを消費するため、公開や移行は温める期間を前提に計画します。

4. 静かに失敗せず、大きく、回復可能に失敗させる。 エッジがクローラーを一時的に退ける必要があるなら、きれいな503／429はタイムアウトや200のエラーページより優れています。明確で一時的な応答は回復できます。静かで偽物の応答はインデックスから外されます。

5. シグナルはエッジを通過しなければならない。 canonicalタグ、HTTPS、セキュリティヘッダー、クローラーアクセスはすべてCDNを通ります。「CDN後もこれは機能するか」を必須の検証手順として扱い、前提にしません。

CDNとSEOのチートシート

CDNがクローラーを退ける必要があるとき — 正しいレスポンスを選ぶ

CDNがSEOについてすること／しないこと

早わかり

• 一次資料：Googleの**Google の 2024 年 12 月記事：CDN とクロール** （2024年12月）。
• ボットブロックはURL Inspectionのレンダリング済みスクリーンショットでデバッグする。
• クローラーを**googlebot.json** とBingの公開IPレンジで検証する。
• HTTPSは両区間（オリジン↔エッジ、エッジ↔クライアント）で必要。

神話と間違い、そして修正

これらはCDNとSEOについてよくある思い込みです。なぜ誤りなのか、代わりに何をするかを示します。

神話：「CDNはランキングを直接押し上げる」 誤りの理由： Googleは「CDNを使う」ことに報酬を与えません。CDNはパフォーマンスと信頼性のシグナルを可能にするもので、ランキング要因ではありません。 代わりに： CDNでTTFB／Core Web Vitals、稼働時間、クロール効率を改善し、それらを測定します。

神話：「CDNを使うと自動的に重複コンテンツのペナルティを受ける」 誤りの理由： 重複コンテンツのペナルティはありません。最悪でもCDNとオリジン間のcanonical設定ミスにより、Googleが予期しないcanonical URLを選ぶだけです。 代わりに： canonicalタグ／ヘッダーがエッジを通過することを確認し、各CDNデプロイ後に検証します。これはペナルティリスクではなく、canonical化の衛生管理です。

神話：「共有CDN IP（低品質サイトも使うもの）がランキングを下げる」 誤りの理由： GoogleのJohn Muellerは、他社とCDN IPブロックを共有するのは想定内で問題なく、ペナルティはないと述べています。 代わりに： SEOのために専用IPブロックを買うという無駄な出費をやめます。

神話：「静的アセットをcdn.example.comサブドメインに置けば、常にクロールバジェットに良い」 誤りの理由： Googleは2024年12月に1週間以内でこの指針を撤回しました。重要な描画ブロッキングJS／CSSでは、別ホスト名への接続オーバーヘッドがクロールバジェットの節約を上回ります。 代わりに： 重要なリソースはメインのCDN配下ホストに置き、動画やダウンロードのような大きく重要でないアセットだけを別ホスト名で配信します。

神話：「CDNが200ステータスで奇妙なエラーページを返しても、サイトは技術的に稼働しているので無害」 誤りの理由： Googleはこれをソフトエラーと呼び、最悪のケースとして扱います。URLを削除したり、同じエラー本文を共有するページを重複として排除したりできます。 代わりに： 一時的なブロックにはきれいな503／429を返し、200のエラーページは決して返しません。

神話：「CDNは開発／運用の問題でSEOとは無関係」 誤りの理由： CDNの設定ミスは、「コンテンツなしでインデックス登録」、クローラーのブロック、ページ体験の回帰を引き起こす現実の主要因です。 代わりに： CDN変更をSEOに関係する変更として扱い、クロールとインデックス登録の担当者を巻き込み、変更後にクローラーアクセス、canonical、HTTPSを再検証します。

CDNを通過してクローラーが実際に受け取るものを確認する

Googlebotとしてリクエストを送り、通常のリクエストと比較します。CDNがボットにチャレンジまたはブロックすると、ステータスコード、チャレンジ本文、インタースティシャルへのリダイレクトなどに差が出ます。

macOS / Linux

# Fetch as Googlebot — watch the status line and headers
curl -sSI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/some-page/

# Compare against a normal browser UA
curl -sSI -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  https://example.com/some-page/

Windows / PowerShell

$gb = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/some-page/" -UserAgent $gb -Method Head |
  Select-Object StatusCode, Headers

ボットUAだけに返される403、チャレンジページ、または本文が不自然に小さい200は、CDNのWAF／ボット管理が邪魔をしていることを示します。

許可／拒否リストへ入れる前に本当にGooglebotか確認する

ユーザーエージェント文字列だけを根拠にWAFエントリーを許可リストへ入れてはいけません。簡単に偽装できます。逆引きDNSと正引きDNSを確認します。

macOS / Linux

# Reverse-DNS the IP from your logs — should end in googlebot.com or google.com
host 66.249.66.1
# Forward-DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

逆引き結果がGoogleドメインで終わらない、または正引き結果が元のIPと一致しないなら、それはGooglebotではありません。Googleの公開レンジ（googlebot.json）や、Bingが公開するBingbot IP一覧とも照合できます。

CDN設定に埋め込まれた混合コンテンツをDevTools Consoleで見つける

ページのChrome DevTools Consoleに貼り付けると、平文HTTPで読み込まれたアセットを一覧できます。「Flexible SSL」でよく起きる症状です。

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure:', u));

ログに出たものはHTTPで要求されています。HTTPS CDNの背後では混合コンテンツ警告が発生します。

月次CDNクローラーアクセス確認

1. 重要テンプレートをサンプルする。 ホームページ、カテゴリ、記事、コンバージョンURLを少なくとも1つずつ選び、実務上可能なら2つ以上のリージョン／PoPとキャッシュ状態（ヒット、ミス、古い状態）で確認します。完了とは、すべてのCDNキャッシュまたはWAFルールセットをサンプルがカバーすることです。
2. 各URLをGoogleとして検査する。 URL Inspectionのライブテストを実行してレンダリングページを確認します。完了とは、Googleがエラーやチャレンジではなくページを受け取ることです。
3. WAFイベントを確認する。 月のブロックを検証済み検索クローラーで絞り、GooglebotまたはBingbotの公開レンジで身元を検証します。完了とは正当なクローラーがブロックされていないことです。
4. エッジヘッダーを比較する。 エッジ後のステータス、canonical、Cache-Control、HTTPS、HSTS、CSPを確認します。完了とはCDNがそれらを削除または書き換えていないことです。
5. 例外と担当者を記録する。 影響するルール、URLパターン、修正、次回確認日を記録します。完了とはすべての例外に担当者と期限があることです。

Googlebotに突然CDNチャレンジが表示される

1. URL Inspectionでインシデントを確認する。 ライブのレンダリングページが正常なら、問題がリージョンまたはURLパターンに限られるか確認し、そうでなければ続けます。
2. エッジのレスポンスを特定する。 403、タイムアウト、チャレンジ本文、偽の200はWAFまたはボット管理層を示します。オリジンも同じ結果を返すなら、オリジン担当者へ引き継ぎます。
3. 失敗を回復可能にする。 一時的な自動ブロックには503または429を返します。診断中にタイムアウトや200のチャレンジページを残しません。
4. クローラーを検証する。 許可リストを変える前に、逆引きと正引きDNSまたは検索エンジンの公開レンジで送信元IPを確認します。
5. ルール変更を絞る。 不正なブロックを解除するか検証済みクローラーを除外し、URL Inspectionを繰り返します。本物のページが表示されたらWAFイベントとクロールエラーを監視し、表示されなければリクエストチェーンの次のエッジルールを調べます。
6. 再発を防ぐ。 発火したルールを記録し、月次クローラーアクセス確認に追加します。

Googleにページではなくチャレンジが表示される

症状： URL Inspectionがインタースティシャル、空白ページ、またはWAFメッセージをレンダリングする。 考えられる原因： CDNでのボット検証または自動ブロック。 修正： クローラーを検証し、該当するWAFルールを調整し、一時的なブロック中は503を返す。新しいライブ検査で修正を確認する。

CDNデプロイ後にcanonicalが異なる

症状： エッジレスポンスのcanonicalがオリジンから欠落、または異なる。考えられる原因： HTML変換、ヘッダー書き換え、古いキャッシュ文書。修正： 影響するキャッシュキーをパージし、書き換えを除去し、オリジンと公開レスポンスを再比較する。

HTTPSは公開で機能するのに混合コンテンツが現れる

症状： ページURLがHTTPSなのにブラウザーが安全でないアセットを報告する。考えられる原因： CDNがHTTPでオリジンへ接続する、またはアセットURLを書き換える。修正： 両区間でHTTPSを必須にし、アセットURLを直し、パージしてScriptsタブからConsoleチェックを再実行する。

大規模公開がオリジンを過負荷にする

症状： Googleが新しいURLを多数発見すると、オリジンの遅延やエラーが急増する。考えられる原因： エッジの冷えたキャッシュでは新しいURLごとにオリジンのレスポンスが1回必要。修正： オリジン容量を戻し、必要なら回復可能な一時ステータスコードを使い、CDN保護を前提にせずキャッシュを温める計画で今後の公開を行う。

一時的なボットブロック：悪いレスポンスと回復可能なレスポンス

HTTP/2 200
content-type: text/html

<h1>Verify you are human</h1>

200は失敗を隠し、多数のURLを重複するチャレンジページに見せる可能性があります。一時的なブロックは自分自身を明示すべきです。

HTTP/2 503
retry-after: 300
content-type: text/html

CDNキャッシュキー：偶発的な重複と1つのcanonicalレスポンス

関係のないトラッキングパラメーターでHTMLを変えるキャッシュキーは、/product?utm_source=aと/product?utm_source=bに別々のエッジオブジェクトを作ります。よりきれいな設定では、キャッシュ時にそのパラメーターを無視し、両レスポンスで同じcanonical URLを保持します。これは簡略化した設定例で、正確なルール構文はCDNごとに異なります。

CDNの挙動を監査するツール

• Google Search Console URL Inspection — ライブテストを実行してレンダリングページを確認し、ボットチャレンジ、空白、エッジエラーを見つけます。
• Googlebot IP ranges — WAFアクセスを変更する前に、Googleの公開googlebot.json と照合します。
• Bing Verify Bingbot — 公式の検証ツール でBingbotの身元を確認します。
• curlまたはPowerShell Invoke-WebRequest — 安全に直接アクセスできる場所で、ブラウザーUA、クローラーUA、オリジンのステータスとヘッダーを比較します。
• Chrome DevTools — Networkでステータス／キャッシュヘッダー、Consoleでエッジ設定変更後の混合コンテンツを確認します。

CDN変更が検索に安全だと証明する

クローラーアクセステスト

実行するテスト： 変更した各テンプレートでURL Inspectionのライブテストを使う。期待結果： レンダリング済みスクリーンショットに実ページが含まれ、意図したステータスを返す。失敗の解釈： WAF、ボットチャレンジ、エッジルールがGoogleを遮っている。監視期間： 直ちに、その後ルール伝播後に再確認。ロールバック条件： Googleがチャレンジ、空白レスポンス、ハードブロックを受け取る。

エッジヘッダー一致テスト

実行するテスト： 公開とオリジンのステータス、canonical、Cache-Control、セキュリティヘッダーを比較する。期待結果： 許可されたCDN変換後も意図したシグナルが一致する。失敗の解釈： 書き換えまたは古いキャッシュがレスポンスを変えた。監視期間： デプロイとパージの直後。ロールバック条件： canonical、HTTPS、またはクローラー向けステータスが承認済みオリジンと異なる。

温かいキャッシュのパフォーマンステスト

実行するテスト： 同じURLを2回要求し、CDNのcache-statusヘッダーとTTFBを比較する。期待結果： 2回目の対象リクエストがキャッシュから配信され、冷えたリクエストより遅くない。失敗の解釈： レスポンスがキャッシュ不可、キャッシュキーが予期せず変化、またはエッジが迂回されている。監視期間： 設定伝播後。ロールバック条件： 変更がエラーを増やす、または代表ページでTTFBを一貫して悪化させる。

リージョンとキャッシュ状態の検証テスト

実行するテスト： 通常のUAと検証済みクローラーUAの両方で、個別化またはCookie付きの変種も含め、同じURLのレンダリング出力とヘッダーを複数リージョン／PoP、複数のキャッシュ状態（ヒット、ミス、古い状態）で比較する。期待結果： 意図的な差（本当に地域固有のコンテンツ）を記録した場合を除き、リージョン、キャッシュ状態、リクエスターの種類に関係なくステータス、canonical、robotsディレクティブ、レンダリングコンテンツが意図どおり一致する。失敗の解釈： 意図しないリージョン、キャッシュ状態、リクエスター依存の差は、キャッシュキー、Vary、エッジ設定のずれを示す。監視期間： デプロイ直後、その後最初のクロール／ログ確認サイクル中。ロールバック条件： いずれかのテスト軸でステータス、canonical、クローラー向けコンテンツに意図しない差がある。

重要なCDN健全性指標

エッジキャッシュヒット率

指標： エッジキャッシュから配信された対象リクエスト。分かること： CDNが反復リクエストを実際にオフロードしているか。取得方法： キャッシュ可能なコンテンツ種別で分けたCDN分析パネル。ベンチマーク／現実的な範囲： テンプレートとアセット種別ごとにベースラインを設定し、個別化HTMLと不変アセットに同じ目標を置かない。頻度： 週次、およびキャッシュルール変更後。

オリジンエラー率とTTFB

指標： キャッシュミス時のオリジン5xx率とレスポンスタイム。分かること： 冷えたキャッシュやトラフィック急増がオリジン容量を超えているか。取得方法： CDNオリジン分析とサーバーログ。ベンチマーク／現実的な範囲： URL種別ごとのサイト固有の通常範囲を使い、持続する回帰を調査する。頻度： 継続アラートと週次トレンド確認。

検証済みクローラーのブロック

指標： 確認済みGooglebotとBingbotのリクエストに対するWAFブロック。分かること： ボット保護が必要なクローラーを排除しているか。取得方法： 公式レンジまたはDNSで検証したWAFイベント。ベンチマーク／現実的な範囲： 意図しないブロックゼロ。頻度： 直ちにアラートし、月次で確認。

自分で確認：CDNとSEO

CDNがクロール、速度、インデックス登録にどう影響するかを問う短い5問です。それぞれ答えを選んでから確認してください。

時間を使う価値のあるリソース

私の関連執筆

• Google PageSpeed Insights（SEO と開発者向け） — ページ速度ツールの記事。CDNは低いPageSpeed／Core Web Vitalsスコアを直す最大級のレバーです。
• テクニカル SEO の初心者向けガイド — パフォーマンスとクロールが大きな文脈のどこに入るか。

私の講演

• SMX Advanced 2018: Solving Complex SEO Problems （SlideShare）— ロジックが存在し得る層をCDNエッジも含めて示し、それがクロール／リダイレクトの驚きを生む方法を説明します。
• テクニカル SEO、ページ速度、セキュリティの調整 （Marketing Speak、109回）— 技術SEO、ページ速度、セキュリティというCDN隣接領域。

公式

• Google — 2024 年 12 月の CDN・クロール記事 とGooglebot のクロール方法と理由。
• Bing — Bingbot を確認 とBingbot 確認ツール。

業界の資料

• Can A Content Delivery Network Boost Website SEO? （DebugBear）— Core Web Vitalsに結び付けた実務的なCDN設定手順。
• Technical SEO Checklist （DebugBear）— より広い監査でCDN／パフォーマンス項目が置かれる場所。
• Best SEO for Your CDN （KeyCDN）— エッジでのcanonicalヘッダーとrobots.txtに関するベンダーの見解。
• CDN（コンテンツ配信ネットワーク）が SEO に与える影響 （Search Engine Journal）— 一般的なCDN／SEO概説（Googleの2024年12月指針より前）。
• Microsoft list of Bingbot IP addresses released （Search Engine Land）— Googleの公開クローラーIPに対応するBingの話。
• Microsoft Bing Lists All Of BingBot’s IP Addresses In JSON File （Search Engine Roundtable）— 同じJSON IP一覧の報道。

変更履歴