サイトを CDN に載せ替えたら、表示は速くなったのに、元のサーバーの負荷がかえって上がった。
そんなことが起きる理由を Google が公式ブログで解説しました。
11月11日付けの Google 検索セントラル ブログの記事で、書いたのは Google の Gary Illyes 氏たちです。
原題は「Moving to a CDN without overwhelming your origin (or blocking Googlebot)」で、「元のサーバーを圧倒せず（Googlebot も締め出さずに）CDN に移行するには」という意味です。
この記事ではその中身をかみ砕いて紹介し、CDN に載せ替える案件で制作者が何をしておけばよいかを整理します。
ひとことで
CDN に切り替えると応答が速くなるので、Google は「サーバーが強くなった」と判断して、クロールを増やします。
ところが、切り替えた直後の CDN にはまだ何もキャッシュされていません。
そのため、増えたクロールのほとんどが CDN を素通りして元のサーバーに届いてしまう、という話です。
速くするために CDN を入れたのに、かえってサーバーが苦しくなる。
ちょっとややこしいですが、仕組みを知ると納得できます。
前提: Google がクロールする量は、サーバーの速さで決まる
Google はサイトごとに「どれくらいの勢いでクロールしてよいか」の上限を決めています。
英語では crawl capacity limit（hostload とも）と呼ばれています。
この上限はサーバーの応答の速さと安定性で調整されます。
- 応答が遅くなったり、エラーが増えたりすると、上限を下げる
- 応答が速く、安定していると、上限を少しずつ上げる
サーバーに負担をかけすぎないための仕組みです。
逆に言えば、サーバーが速くなれば、Google はそのぶん遠慮なくクロールしに来ます。
反対に、サーバーが遅いとクロールが先送りされ、Search Console に「検出 – インデックス未登録」が増えることがあります。
品質の問題との見分け方は、こちらでまとめています。
CDN に移行した直後に、クロールが急増する仕組み
順を追うと、次のようになります。
- ドメインの向き先（DNS）を CDN に切り替えると、接続や応答の時間が大きく縮む
- Google はそれを見て「サーバーが強くなった」と判断し、クロールの勢いを上げる
- ところが新しい CDN のキャッシュは空なので、どの URL も最初の1回はキャッシュに当たらず、元のサーバー（オリジン）まで取りに行く
- 結果として、キャッシュがたまるまでのあいだ、増えたクロールがそのままオリジンにのしかかる
ここで効いてくるのが3です。
CDN は2回目以降のアクセスにはキャッシュから返すので、オリジンを守ってくれます。
でも最初の1回だけは、どうしてもオリジンに取りに行く必要があります。
しかも、人とクローラーではアクセスの仕方が違います。
人は人気のあるページに集中するので、キャッシュはすぐにたまります。
一方、クローラーはサイトの中の URL を広く順番に巡るので、キャッシュに当たらないアクセスが大量に出やすい、というわけです。
その間は人の訪問とクローラーの両方が、オリジンに直接届くことになります。
なお、CDN によっては接続のペースを調整する機能があり、急増を和らげてくれる場合もあるそうです。
Google が勧める4つの対策
1. 検証済みのボットを CDN・WAF で通す
CDN や WAF（不正なアクセスを防ぐ仕組み）には「既知の、検証済みのボットを許可する」機能や、あらかじめ用意されたルールがあることが多いです。
これを使って、Googlebot が CAPTCHA などの確認画面で止められないようにします。
Googlebot が使う IP アドレスの範囲は公開されているので、本物かどうかを確かめられます。
止めたいボットがあるときは、ボット全体ではなく、そのボットだけを狙って止めるよう勧められています。
2. 切り替える前に、キャッシュを温めておく
本番の切り替え前に、次のような URL を CDN 経由で、ペースを抑えて取得しておきます。
- 主要なページ
- セールや季節のイベントのページ
- よくクロールされる URL
先にキャッシュにためておけば、切り替えた直後に、オリジンへアクセスが集中するのを防げます。
「よくクロールされる URL」は Search Console の「クロールの統計情報」レポートで、ある程度つかめると思います。
Search Console の左メニューの最下部にある「設定」をクリックし、「クロール」の項目にある「クロールの統計情報」（「詳細を開く」）を選ぶと確認できます。
3. どうしても苦しいときは、429 か 503 を短期間だけ返す
オリジンの負荷が深刻なときは、サーバーや CDN の流量制限の機能で、一時的に 429 か 503 を返します。
期間は数時間から、長くても1〜2日までとされています。
4. 403 や確認画面でクローラーを止めない
403（アクセス禁止）や、人かどうかを確かめる画面で Googlebot を止めると、クローラーが引き下がり、ページが検索結果から消えてしまうおそれがある、と書かれています。
429・503 と 403 の違い
3と4は似ているようで、Google への伝わり方がまったく違います。
| 返すもの | 意味 | Google の受け取り方 |
|---|---|---|
| 429（Too Many Requests） | アクセスが多すぎる | 今は控えてほしい、という一時的な合図 |
| 503（Service Unavailable） | 一時的に使えない | 今は控えてほしい、という一時的な合図 |
| 403（Forbidden）や確認画面 | アクセスを拒否 | クローラーが引き下がり、検索結果から消えるおそれがある |
負荷を下げたいときに、とっさに「ボットを全部ブロック」してしまうと、403 や確認画面になりがちです。
それでは検索結果から消えるおそれがあるので、止めるなら 429 か 503 を短いあいだだけ。
ここは覚えておきたいところです。
制作の現場で: CDN に載せ替える案件のチェックリスト
Google の記事をもとに、案件で確認しておきたいことを時期ごとに整理しました。
切り替える前
- CDN・WAF の設定で、検証済みのボットを許可しているか
- 主要なページや、よくクロールされる URL を CDN 経由で取得しておいたか
- オリジンの負荷が上がったときに、403 ではなく 429 か 503 を返す方法を決めてあるか
- セールなど、アクセスが増える時期の直前に切り替えようとしていないか
切り替えた直後
- オリジンの CPU やメモリ、アクセスログに、急な増え方がないか
- Search Console の「クロールの統計情報」で、クロールの数やサーバーの応答に変化がないか
数日たってから
- キャッシュがたまり、オリジンへのアクセスが落ち着いてきたか
- 429 や 503 を返していたなら、元に戻したか
特に小さめのレンタルサーバーをオリジンにしている場合は、ふだんは余裕があっても、切り替え直後のクロールの増え方には耐えきれないこともありそうです。
CDN の導入を提案するときは、「切り替え直後の数日は、元のサーバーの様子を見ます」とあらかじめ伝えておくと安心です。
判断基準のまとめ
- CDN に切り替えた直後のオリジンの負荷の増加は、キャッシュが空のせいで起きる一時的なもの
- 対策は、検証済みボットの許可と、切り替え前のキャッシュの温め
- それでも苦しいときは、429 か 503 を数時間〜1〜2日だけ
- 403 や確認画面で Googlebot を止めるのは避ける
出典
- Google 検索セントラル ブログ「Moving to a CDN without overwhelming your origin (or blocking Googlebot)」: https://developers.google.com/search/blog/2026/11/crawling-cdn
- クロールの上限（Crawl Budget Management）: https://developers.google.com/crawling/docs/crawl-budget
- Google のクロール頻度を下げる方法（Reduce Google Crawl Rate）: https://developers.google.com/crawling/docs/crawlers-fetchers/reduce-crawl-rate
- Google のクローラーの確かめ方（Verify Requests from Google Crawlers and Fetchers）: https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
- Search Console ヘルプ「クロールの統計情報レポート」: https://support.google.com/webmasters/answer/9679690?hl=ja
