Google のクローラーとフェッチャー（ユーザー エージェント）の概要

Google はクローラーとフェッチャーを使用して、自動的にまたはユーザー リクエストに基づき、サービスのアクションを実行します。クローラー（「ロボット」や「スパイダー」と呼ばれることもあります）は、ウェブサイトを自動的に検出してスキャンするプログラムの総称です。フェッチャーは、一般的にユーザーに代わって単一のリクエストをする wget のようなプログラムとして機能します。Google のクローラーには次の 3 つのタイプがあります。

一般的なクローラー Google 製品で使用される一般的なクローラー（Googlebot など）。自動クロールでは常に robots.txt ルールに従います。
特殊なケース用のクローラー 特殊なケース用のクローラーは一般的なクローラーと似ていますが、クロールされるサイトと Google サービス間でクロール プロセスに関して合意がある、特定のサービスで使用されます。たとえば、AdsBot は広告パブリッシャーの許可に基づき、グローバル robots.txt ユーザー エージェント（*）を無視します。
ユーザー トリガー フェッチャー ユーザー トリガー フェッチャーは、エンドユーザーがフェッチをトリガーする、ツールおよびサービスの機能の一部です。たとえば、Google サイト検証ツールはユーザーのリクエストに基づいて動作します。

Google クローラーとフェッチャーの技術的特性

Google のクローラーとフェッチャーは、数千台のマシンで同時に実行することでパフォーマンスを向上させ、ウェブの拡大に伴って拡張できるように設計されています。帯域幅の使用量を最適化するため、クライアントを世界中の多くのデータセンターに分散させることで、アクセスするサイトが近くなるようにしています。そのため、複数の IP アドレスからのアクセスがログに記録される場合があります。Google からのトラフィックは大部分が米国の IP アドレスからですが、サイトが米国からのリクエストをブロックしていることが検出された場合は、他の国の IP アドレスからクロールを試みることがあります。

サポートされている転送プロトコル

Google のクローラーとフェッチャーは HTTP/1.1 と HTTP/2 をサポートしています。クローラーは、最高水準のクロール パフォーマンスを提供するプロトコル バージョンを使用し、以前のクロールの統計情報に応じてクロール セッション間でプロトコルを切り替える場合があります。Google のクローラーが使用するデフォルトのプロトコル バージョンは HTTP/1.1 ですが、HTTP/2 を介してクロールすることで、サイトと Googlebot のコンピューティング リソース（CPU、RAM など）が節約されます。ただし、サイトにとって Google サービス特有のメリット（Google 検索でのランキング上昇など）はありません。HTTP/2 を介してクロールされないようにするには、サイトをホストしているサーバーの設定を変更し、Google が HTTP/2 を介してアクセスしようとすると 421 の HTTP ステータス コードで応答するようにしてください。この対応ができない場合は、クロールチームにメッセージを送信できます（ただし、この解決策は一時的なものです）。

Google クローラーのインフラストラクチャは、RFC959 とそのアップデートで定義されている FTP と RFC4217 とそのアップデートで定義されている FTPS を使ったクロールにも対応していますが、このようなプロトコルからのクロールはまれです。

サポートされているコンテンツ エンコード

Google のクローラーとフェッチャーは、gzip、deflate、Brotli（br）のコンテンツ エンコード（圧縮形式）に対応しています。各 Google ユーザー エージェントがサポートしているコンテンツ エンコードは、各リクエストの Accept-Encoding ヘッダーで告知されます。たとえば、Accept-Encoding: gzip, deflate, br のようになります。

クロール頻度とホスト負荷

サーバーに大きな負荷をかけることなく、1 回のアクセスでサイト内のページをできるだけ多くクロールすることを目標にしています。Google のクロール リクエストへの対応で問題が発生した場合は、クロール頻度を減らすことができます。Google クローラーに不適切な HTTP レスポンス コードを送信すると、Google サービスでのサイトの表示に影響が発生する場合があります。

HTTP キャッシュ保存

Google クローラーのインフラストラクチャは、HTTP キャッシュ標準で定義されているヒューリスティックの HTTP キャッシュ保存をサポートしています。具体的には ETag レスポンスおよび If-None-Match リクエスト ヘッダーと、Last-Modified レスポンスおよび If-Modified-Since リクエスト ヘッダーを使用します。

ETag および Last-Modified レスポンス ヘッダー フィールドの両方が HTTP レスポンスに含まれる場合、Google クローラーは HTTP 標準に従って ETag 値を使用します。特に Google クローラーでは、ETag では日付形式の問題が発生しないため、Last-Modified ヘッダーではなく ETag を使用して、キャッシュ保存の設定を指定することをおすすめします。

他の HTTP キャッシュ ディレクティブはサポートされません。

個々の Google クローラーとフェッチャーは、関連付けられているサービスのニーズによって、キャッシュ保存を利用する場合と利用しない場合があります。たとえば、Googlebot は Google 検索用に URL 再クロールするときにキャッシュ保存に対応していますが、Storebot-Google は特定の条件の場合のみキャッシュ保存に対応しています。

サイトで HTTP キャッシュ保存を実装するには、ホスティング プロバイダまたはコンテンツ マネジメント システム プロバイダにお問い合わせください。

ETag と If-None-Match

Google クローラーのインフラストラクチャは、HTTP キャッシュ標準で定義されている ETag と If-None-Match をサポートしています。ETag レスポンス ヘッダーとその対応するリクエスト ヘッダーである If-None-Match について詳細をご確認ください。

Last-Modified と If-Modified-Since

Google クローラーのインフラストラクチャは、HTTP キャッシュ標準で定義されている Last-Modified と If-Modified-Since をサポートしていますが、次の点に注意する必要があります。

  • Last-Modified ヘッダーの日付は HTTP 標準に従った形式とします。解析に関する問題が発生しないように、「Weekday, DD Mon YYYY HH:MM:SS Timezone」という日付形式を使用することをおすすめします（「Fri, 4 Sep 1998 19:15:56 GMT」など）。
  • 必須ではないものの、Cache-Control レスポンス ヘッダーの max-age フィールドを設定して、クローラーが特定の URL をクロールするタイミングを判断できるようにすることも検討してください。max-age フィールドの値には、コンテンツが変更されない想定期間を秒単位で設定します。たとえば、Cache-Control: max-age=94043 と設定します。

Last-Modified レスポンス ヘッダーと対応するリクエスト ヘッダーである If-Modified-Since について詳細をご確認ください。

Google のクローラーおよびフェッチャーであることの確認

Google クローラーであることは次の 3 つの方法で確認できます。

  1. HTTP user-agent リクエスト ヘッダー。
  2. リクエストの送信元 IP アドレス。
  3. 送信元 IP の逆引き DNS ホスト名。

これらを使って確認する方法については、Google のクローラーやフェッチャーであることを確認するをご覧ください。