12 月のクロール情報: CDN とクロール

2024 年 12 月 24 日（火）

コンテンツ配信ネットワーク（CDN）は、ウェブサイトの遅延を短縮し、通常はウェブトラフィック関連のトラブル回避に特に役立つサービスです。CDN の主な目的は、サイトで大規模なトラフィック負荷が発生している場合でも、その影響を受けずにコンテンツをすばやく配信することにあります。CDN の「"D"」とは、世界中にコンテンツを届ける（Deliver）または分散する（Distribute）ことを指しており、1 か所のデータセンターでコンテンツをホストする場合よりもユーザーへの転送時間が短縮されるメリットがあります。この投稿では、CDN を利用して、サイトのクロールとユーザー エクスペリエンスを改善する方法を説明します。また、CDN を使用したサイトでのクロールに関する注意点も紹介します。

振り返り: CDN とは

基本的に CDN は、オリジンサーバー（ウェブサイトがある場所）とエンドユーザーの間の中継地点として、サーバーに代わってファイルを配信します。これまで、CDN の主な目的はキャッシュ保存でした。ユーザーがサイトの URL をリクエストすると、CDN がその URL のコンテンツを一時的にキャッシュに保存して、一定期間はサーバーが再度そのファイルを配信しなくてすむようにするものです。

CDN によってユーザーに近い場所から配信できるため、サイトの表示速度が大幅に向上します。たとえば、オーストラリアにいるユーザーが、ドイツでホストされているサイトにアクセスしたとすると、CDN はオーストラリアにあるキャッシュからそのユーザーに配信するため、遠くまで転送する時間が短縮されます。どれだけ伝送速度が向上しても、物理的にかなりの距離があると表示速度が遅くなるものです。

最後に、CDN は過負荷とセキュリティの脅威からサイトを守るすばらしいツールです。大量のグローバル トラフィックを管理する CDN は、トラフィックの異常を検知し、過度または不正なアクセスをブロックして、高度な信頼性を提供するトラフィック モデルを構築しています。たとえば、2024 年 10 月 21 日に、Cloudflare のシステムはピーク時 4.2 Tbps（これは超大規模です）の DDoS 攻撃を自動検知し、わずか 1 分ほどで終了させました。

サイトをサポートする CDN の機能

高速の高性能サーバー、最適なアップリンクを使用するために自社投資したから、アクセス速度の改善は要らないとお考えかもしれませんが、大規模なサイトを運営されている場合は特に、CDN を活用すると長期的にはコスト削減につながります。

  • CDN でのキャッシュ保存: メディア、JavaScript、CSS などのリソース、さらには HTML も CDN のキャッシュから配信できれば、サーバーはそのようなリソースの配信にコンピューティング リソースと帯域幅を使用せずにすみ、このプロセスでのサーバー負荷が軽減します。通常、これによりユーザーのブラウザでのページ読み込み速度も速くなり、コンバージョンの向上につながります。
  • 大量のトラフィックからの保護: CDN は特に過度または不正なトラフィックの特定とブロックを得意とし、不正行為を行っているボットや人物がサーバーに負荷をかけているときでも、ユーザーがサイトにアクセスできるようにします。
    さらに、不正なトラフィックをブロックするための制御機能は、大量のトラフィックだけでなく、特定のクローラー、特定のパターンに当てはまるクライアント、同じ IP アドレスを何度も使用している荒らしによるトラフィックなど、サイトに不要なトラフィックのブロックにも使用できます。サーバーまたはファイアウォールでも同様のことができますが、通常は CDN のユーザー インターフェースを使うほうがずっと簡単です。
  • 信頼性: CDN によっては、オリジンサイトがダウンしているときでも、ユーザーにサイトのコンテンツを配信できます。当然ながら、これが機能するのはほぼ静的コンテンツの場合になりますが、それでも待ちきれないユーザーが他のサイトに逃げないようにするための対策として足りるものです。

つまり、CDN は心強い味方です。サイトの規模が大きい場合や、トラフィックの大幅な増加が見込まれる場合（またはすでに大量のトラフィックが発生している場合）には、料金、パフォーマンス、信頼性、セキュリティ、カスタマー サポート、拡張性、今後の展開などの要素を踏まえて、ニーズに合った CDN を探しましょう。お使いのホスティング プロバイダや CMS プロバイダに問い合わせて、CDN を利用できるか、またはすでに導入されているかなどをご確認ください。

CDN を使用しているサイトでのクロールの影響

クロールに関しても CDN は利点がありますが、クロールに関する問題の原因となることもまれにあります。ここは大事なので最後までお読みください。

CDN によるクロール頻度への影響

Google のクロール インフラストラクチャは、CDN を使用しているサイトでは高い頻度でクロールできるように設計されています。サイトが CDN を使用しているかどうかは、クローラーが発見してアクセスする URL の提供元サービスの IP アドレスから推測できます。ほとんどの場合、これは正常に機能します。

たとえば、ストックフォトのサイトを今日公開し、そこには 1,000,007 点の素材が含まれているとします。すべての素材についてランディング ページ、カテゴリページ、詳細ページを作成してウェブサイトを公開した場合、ページの数は大量になります。クロール能力の上限についてのドキュメントで説明しているとおり、Google 検索ではできる限り迅速にこのようなページのすべてをクロールすることを目指していますが、クロールによってサーバーに大きな負荷がかからないように制御されており、クロール リクエスト数の増加により、サーバーのレスポンスに時間がかかるようになると、サーバーへの負荷を抑えるために Google 側にスロットリングが適用されます。サイトで CDN が使用されていることをクロール インフラストラクチャが検知すると、このスロットリングのしきい値は引き上げられます。これは、サーバーに送信する同時リクエスト数を増やしても処理できる可能性が高く、問題ないと判断されるためです。その結果、より迅速にウェブショップのクロールが行われることになります。

ただし、その URL へのアクセスが初めてで、CDN のキャッシュが「コールド」の場合、つまりその URL がリクエストされたことがなく、コンテンツがまだ CDN によってキャッシュ保存されていない場合は、オリジンサーバーはその URL のリソースを少なくとも 1 回は配信して、CDN のキャッシュを「ウォームアップ」する必要があります。この仕組みは HTTP キャッシュ保存の仕組みとも非常によく似ています。

つまり、CDN を使用している場合でも、元のサーバーから少なくとも 1 回は 1,000,007 個の URL のコンテンツを配信する必要があります。最初の配信が完了した後でのみ、CDN によるキャッシュ保存が役に立つようになります。これは「クロール バジェット」を多く消費するだけでなく、数日間はクロール頻度が高くなる可能性があります。一度に大量の URL を公開する場合はこの点を念頭に置いてください。

CDN によるレンダリングへの影響

初回の 12 月のクロール情報の、リソースのクロールに関するブログ投稿で説明したとおり、リソースを固有のホスト名または CDN ホスト名（cdn.example.com）に分割することにより、Google のウェブ レンダリング サービス（WRS）がページをより効率的にレンダリングできるようになる場合があります。ただし注意点があり、この方法は異なるホスト名への接続のオーバーヘッドにより、ページ パフォーマンスに悪影響を及ぼす可能性があります。そのため、ページ エクスペリエンスとレンダリング パフォーマンスを慎重に検討したうえで実行を判断する必要があります。

メインのホストで CDN を使用していれば、この問題を回避できます。クエリするホスト名は 1 つで、重要なレンダリング リソースは CDN のキャッシュから配信されるため、サーバーがレンダリング リソースを配信する必要がなくなります（さらにページ エクスペリエンスにも影響しません）。

最終的には、静的リソースに個別のホスト名（cdn.example.com）を設定する、メインのホスト名には CDN を使用する、またはその両方を行うなど、ビジネスに最も適したソリューションを選択してください。Google のクロール インフラストラクチャはいずれのオプションにも問題なく対応できます。

CDN によりサイトが過度に保護されるケース

CDN が提供する大量のトラフィックからの保護機能と、クローラーによるクロールの仕組みが逆に災いして、サイトにアクセスしてほしいボットが CDN のブロックリスト（通常はウェブ アプリケーション ファイアウォール（WAF）のブロックリスト）に入ってしまうことがあります。ブロックリストに入ると、クローラーはサイトにアクセスできなくなり、結果としてサイトが検索結果に表示されなくなります。ブロックはさまざまな形で行われ、Google の検索結果におけるサイトのプレゼンスにより悪影響を及ぼすものもあります。しかも CDN 側で発生するため、パブリッシャーが制御することは難しい（あるいは不可能）場合があります。このブログ投稿ではこのようなブロックを 2 種類に分けて説明します。一つはハードブロック、もう一つはソフトブロックです。

ハードブロック

ハードブロックは CDN がクロール リクエストに対して、なんらかの形のエラーを含むレスポンスを送信した場合に発生します。次のようなケースが該当します。

  • HTTP 503 / 429 ステータス コード: このような一時的なブロック状態を示すステータス コードの送信は推奨される方法で、この場合は CDN によって意図せずブロックされるまでに原因を特定して対策を講じる時間を確保できます。
  • ネットワーク タイムアウト: CDN からのネットワーク タイムアウトが発生すると、影響を受ける URL は Google の検索インデックスから削除されることになります。このようなネットワーク エラーは端末の「ハード」エラーとみなされます。さらに、サイトが過負荷であることをクロール インフラストラクチャに伝えることになり、サイトのクロール頻度に大きな影響を及ぼす可能性もあります。
  • HTTP 200 ステータス コードでのランダムなエラー メッセージ: ソフトエラーとも呼ばれ、非常に問題です。エラー メッセージが Google 側で「ハード」エラー（HTTP 500 など）と同じと見なされると、Google は URL を検索から削除します。Google がエラー メッセージを「ハード」エラーとして検出できなかった場合は、同じエラー メッセージが発生しているすべてのページが重複ページとみなされ、Google の検索インデックスから削除される可能性があります。Google のインデックス登録では、重複 URL の再クロール リクエストを優先しないため、この復旧には時間がかかる場合があります。

ソフトブロック

CDN が「本当に人間ですか」というインタースティシャルを表示した場合も、同様の問題が発生する可能性があります。

人間と呼ばれて困惑している Crawley

Google のクローラーは人間でないことを認識しており、人間であるふりをすることはありません。クロールのみに特化しているボットです。ただ、インタースティシャルが表示されると、クローラーがアクセスできるのはそこまでで、サイトの内容は確認できなくなります。このようなボット認証用のインタースティシャルを使用する場合は、クローラーなどの自動クライアントに 503 HTTP ステータス コードの明確なシグナルを送り、コンテンツが一時的に利用できないことを伝えることを強くおすすめします。これにより、コンテンツが Google のインデックスから自動的に削除されなくなります。

ブロックのデバッグ

ハードブロックの場合でもソフトブロックの場合でも、正しく機能しているかを確認する一番簡単な方法は、Search Console の URL 検査ツールを使って、レンダリングされた画像を確認する方法です。ページが表示されていれば問題ありません。空のページ、エラー、ボット チャレンジのページが表示されている場合は、CDN のプロバイダに相談することをご検討ください。

また、このような意図しないブロックに対応するため、Google やその他の検索エンジンなどのクローラー運営者は自身の IP アドレスを公開して、クローラーであることをパブリッシャーにわかるようにしています。また、適切なクローラーと判断した場合には、WAF ルールからブロックされた IP を削除したり、さらには許可リストに追加したりすることもできます。こうした対策をどこに施すかは、お使いの CDN によって異なりますが、ほとんどの CDN やスタンドアロンの WAF には役に立つドキュメントが用意されており、少し検索するだけで次のようなものが見つかります（この投稿の公開日時点）。

検索エンジンにサイトを表示させたい場合は、訪れてもらいたいクローラーが自社サイトにアクセスできるかを確認することを強くおすすめします。知らない間にサイトの IP が勝手にブロックリストに追加されていることがあります。そのため、検索パフォーマンスにとどまらず、サイト自体の成功のためにも定期的にブロックリストを確認するようにしてください。ブロックリストが延々と続いている場合には（このブログ投稿も長くなりましたが）、IP 範囲の最初の数セグメントのみ確認してみてください。たとえば、192.168.0.101 ではなく 192.168 を探すようにします。

この投稿は 12 月のクロール情報のブログ投稿シリーズの最後の投稿になります。今回の内容がお役に立てば幸いです。いつものとおり、ご質問などがあればぜひお寄せください。

Posted by Martin Splitt and Gary Illyes

クロールについて詳しくは、12 月のクロール情報シリーズ全体をご覧ください。

Aaseesh Marina

プロダクト サポート マネージャー Aaseesh Marina は、Google で Search Console を担当するプロダクト サポート マネージャーで、Google 検索におけるサイトの視認性を高めるのに必要なサポートをサイト所有者の皆様に提供することを使命としています。 以前は Google のサーチ クオリティ チームに在籍しており、Google 検索の検索結果の品質評価と、スパムをはじめとする不正行為からのユーザーの保護に尽力していました。Aaseesh Marina による

Adrian Gregory Lui

ニュース パートナーシップ担当マネージャー Adrian Gregory Lui による Google 検索セントラル ブログの投稿をご覧ください。 LinkedIn

Adriana Porter Felt

Chrome セキュリティ Adriana Porter Felt による Google 検索セントラル ブログの投稿をご覧ください。