2026 年 3 月 31 日（火曜日）
Search Off the Record ポッドキャストのエピソード 105 をお聴きになった方は、Googlebot の内部構造という、Google の（そして Google のサーバーの）心臓部に近いトピックを詳しく取り上げたことをご存知かもしれません。
長い間、「Googlebot」という名前は、インターネットを体系的に読み取る単一の疲れ知らずの Googlebot のイメージを呼び起こしてきました。しかし、実際はもう少し複雑で、はるかに興味深いものです。今回は、クロール インフラストラクチャについて、特に Google の頭を悩ませているバイトサイズの制限に焦点を当てて説明します。
まず、Googlebot は単一のプログラムではありません。
まず、歴史的な誤解を解きましょう。2000 年代初頭、Google のプロダクトは 1 つのみであったため、クローラーも 1 つのみでした。「Googlebot」という名前が定着しました。しかし、現在の Googlebot は、一元化されたクロール プラットフォームに似たもののユーザーにすぎません。
サーバーログに Googlebot が表示されている場合は、Google 検索のみを確認しています。Google ショッピングや AdSense など、他の数十のクライアントも、異なるクローラ名でこの同じ基盤となるインフラストラクチャを介してクロール リクエストをルーティングします。大規模なクライアントについては、Google クローラ インフラストラクチャ サイトで説明しています。
2 MB の上限: バイトはどうなるか
ここから少しわかりにくくなります。クローラー インフラストラクチャのすべてのクライアントは、フェッチの設定を行う必要があります。これらの設定には、ユーザー エージェント文字列、robots.txt で検索するユーザー エージェント トークン、単一の URL から取得するバイト数などが含まれます。
現在、Googlebot は個々の URL（PDF を除く）に対して最大 2 MB を取得します。つまり、HTTP ヘッダーを含むリソースの最初の 2 MB のみがクロールされます。PDF ファイルの上限は 64 MB です。
画像と動画のクローラーには通常、幅広いしきい値が設定されており、取得対象のプロダクトによって大きく異なります。たとえば、ファビコンの取得には、画像検索とは異なり、非常に低い上限が設定されている場合があります。
上限が指定されていない他のクローラの場合、コンテンツ タイプに関係なくデフォルトは 15 MB です。
サーバーがネットワーク経由で送信するバイト数にはどのような影響がありますか？
- 部分取得: HTML ファイルが 2 MB を超えていても、Googlebot はページを拒否しません。代わりに、2 MB のカットオフでフェッチを正確に停止します。この上限には HTTP リクエスト ヘッダーが含まれます。
- カットオフの処理: ダウンロードされた部分（最初の 2 MB のバイト）は、完全なファイルであるかのように、インデックス登録システムとウェブ レンダリング サービス（WRS）に渡されます。
- 見えないバイト: 2 MB のしきい値の後に存在するバイトはすべて無視されます。取得、レンダリング、インデックス登録は行われません。
- リソースの取り込み: HTML 内で参照されているすべてのリソース（メディア、フォント、一部の特殊なファイルを除く）は、親 HTML と同様に Googlebot を使用して WRS によって取得されます。URL ごとに独自のバイトカウンタがあり、親ページのサイズにはカウントされません。
ウェブの大部分では、2 MB の HTML ペイロードは非常に大きく、この上限に達することはありません。ただし、ページに肥大化したインライン base64 画像、インライン CSS/JavaScript の巨大なブロックが含まれている場合や、数メガバイトのメニューで始まる場合、実際のテキスト コンテンツや重要な構造化データが 2 MB のマークを超えてしまう可能性があります。重要なバイトが取得されない場合、Googlebot には存在しないものと見なされます。
バイトをレンダリングする
クローラーがバイト（上限まで）を正常に取得すると、WRS にバトンを渡します。WRS は、最新のブラウザと同様に JavaScript を処理してクライアントサイドのコードを実行し、ページの最終的な視覚的およびテキストの状態を把握します。レンダリングでは、JavaScript ファイルと CSS ファイルが取得されて実行され、XHR リクエストが処理されて、ページのテキスト コンテンツと構造がより正確に把握されます（画像や動画はリクエストされません）。リクエストされたリソースごとに、2 MB の上限も適用されます。
ただし、WRS はクローラーが実際に取得したコードのみを実行できることに注意してください。さらに、WRS はステートレスに動作します。リクエスト間でローカル ストレージとセッション データをクリアします。これは、動的で JavaScript に依存する要素が Google のシステムによってどのように解釈されるかに特に影響する可能性があります。
バイトに関するおすすめの方法
Googlebot がコンテンツを効率的に取得して理解できるようにするには、バイトレベルのベスト プラクティスを念頭に置いてください。
- HTML を軽量に保つ: 重い CSS と JavaScript を外部ファイルに移動します。最初の HTML ドキュメントは 2 MB に制限されますが、外部スクリプトとスタイルシートは個別に取得されます（それぞれに独自の制限が適用されます）。
-
順序が重要: メタタグ、
<title>要素、<link>要素、正規 URL、重要な構造化データなどの最も重要な要素は、HTML ドキュメントの上部に配置します。これにより、カットオフを下回る可能性が低くなります。 - サーバーログをモニタリングする: サーバーのレスポンス時間を監視します。サーバーがバイトの処理に苦労している場合、Google のクローラはインフラストラクチャの過負荷を回避するために自動的にバックオフし、クロール頻度を下げます。
この上限は固定ではなく、ウェブの進化や HTML ページのサイズの拡大に伴って変更される可能性があります。（または縮小。縮小されることを願っています）。
クロールは魔法ではなく、高度にオーケストレーションされた、スケーリングされたバイトの交換です。中央フェッチ インフラストラクチャがこれらのバイトを取得して制限する方法を理解することで、サイトの最も重要なコンテンツが常にカットされることを防ぐことができます。
今後ともよろしくお願いいたします。
舞台裏の詳細についてもっと知りたいですか？YouTube の Search Off the Record ポッドキャストのエピソード 105 またはポッドキャストを聴いているサービスで、ぜひお聴きください。