【Google解説】Googlebotのクロール、フェッチ、バイト処理の仕組み

2026.04.02

Googlebotは単一のプログラムではない

まず、歴史的な誤解を解く必要があります。

2000年代初頭、Googleは1つの製品しかなかったため、1つのクローラーしかありませんでした。「Googlebot」という名前はそこから来ています。

しかし現在、Googlebotは「中央集約型クロールプラットフォーム」のユーザーの1つに過ぎません。

サーバーログに「Googlebot」と表示されているのは、Google検索のクロールです。しかし、Google Shopping、AdSenseなど、数十の他のクライアントも、異なるクローラー名で同じ基盤インフラを経由してクロールリクエストを送信しています。

2MBの制限　実際に何が起きるのか

ここが混乱しやすい部分です。

クローラーインフラの各クライアントは、フェッチの設定を行う必要があります。これには以下が含まれます。

ユーザーエージェント文字列
robots.txtで探すユーザーエージェントトークン
単一URLから取得するバイト数

具体的な制限値

Googlebot（Google検索）

HTMLやその他のファイル　最大2MB（HTTPヘッダーを含む）
PDFファイル　最大64MB

画像・動画クローラー

プロダクトに応じて様々な閾値
例　ファビコンは非常に低い制限、画像検索は高い制限

その他のクローラー（制限を指定しない場合）

コンテンツタイプに関わらずデフォルトで15MB

サーバーから送信されるバイトに何が起きるのか

1. 部分的なフェッチ

HTMLファイルが2MBより大きい場合、Googlebotはページを拒否しません。代わりに、正確に2MBのカットオフでフェッチを停止します。

重要この制限にはHTTPリクエストヘッダーも含まれます。

2. カットオフの処理

ダウンロードされた部分（最初の2MBのバイト）は、完全なファイルであるかのようにインデックスシステムとWeb Rendering Service（WRS）に渡されます。

3. 見えないバイト

2MBの閾値を超えたバイトは完全に無視されます。フェッチされず、レンダリングされず、インデックスされません。

4. リソースの取得

HTML内で参照されているすべてのリソース（メディア、フォント、いくつかの特殊ファイルを除く）は、親HTMLと同様にGooglebotによってWRSが取得します。

これらのリソースは、独自の個別のURL単位バイトカウンターを持ち、親ページのサイズにはカウントされません。

現実的な影響

Webの大部分にとって、2MBのHTMLペイロードは巨大であり、この制限に到達することはありません。

しかし、以下のような場合、問題が発生する可能性があります。

肥大化したインラインbase64画像
大量のインラインCSS/JavaScript
数メガバイトのメニューで始まるページ

これらがあると、実際のテキストコンテンツや重要な構造化データが2MBを超えてしまう可能性があります。

その重要なバイトがフェッチされない場合、Googlebotにとって、それらは単に存在しないことになります。

レンダリングの仕組み

クローラーがバイト（制限まで）を正常に取得すると、WRSにバトンを渡します。

WRSはJavaScriptを処理し、クライアントサイドのコードを実行して、ページの最終的な視覚的・テキスト的状態を理解します。

レンダリングは以下を行います。

JavaScriptとCSSファイルを取得して実行
XHRリクエストを処理
ページのテキストコンテンツと構造をより深く理解

ただし、画像や動画はリクエストしません。各リクエストされたリソースにも2MB制限が適用されます。

WRSの重要な特性

WRSはステートレスに動作します。つまり、リクエスト間でローカルストレージとセッションデータをクリアします。

これは、動的でJavaScriptに依存する要素がGoogleのシステムによってどのように解釈されるかに影響を与える可能性があります。

ベストプラクティス

Googlebotが効率的にコンテンツをフェッチして理解できるようにするため、以下のバイトレベルのベストプラクティスを覚えておく必要があります。

1. HTMLを軽量に保つ

重いCSSとJavaScriptを外部ファイルに移動します。

初期HTMLドキュメントは2MBに制限されていますが、外部スクリプトとスタイルシートは個別にフェッチされます（それぞれ独自の制限があります）。

2. 順序が重要

最も重要な要素をHTMLドキュメントの上部に配置します。

metaタグ
<title>要素
<link>要素
canonical
重要な構造化データ

これにより、カットオフより下に配置される可能性が低くなります。

3. サーバーログを監視

サーバーの応答時間に注意を払います。

サーバーがバイトの提供に苦労している場合、クローラーはインフラの過負荷を避けるために自動的に後退し、クロール頻度が低下します。

制限は永続的ではない

Googleは次のように述べています。

「この制限は固定されたものではなく、Webが進化し、HTMLページのサイズが変化するにつれて、時間とともに変更される可能性があります（または縮小します。縮小することを願っています）」

SEOタイムズの見解

この解説は、Googlebotの動作に関する最も詳細な公式情報の一つです。

2MB制限の実用的な意味

ほとんどのサイトにとって、2MB制限は問題になりません。しかし、以下のような状況では注意が必要です。

問題になる可能性が高いケース

SPAで大量のインラインスクリプト
- React、Vueなどのフレームワークで、すべてをインラインで含める設定
CMSの自動生成HTML
- 最適化されていないCMSが大量のインラインCSSを生成
大規模なメガメニュー
- ECサイトなどで、数千の商品カテゴリを持つメニュー

具体的な対策

外部化を徹底
- CSS、JavaScriptは可能な限り外部ファイルに
- 各リソースは独自の2MB制限を持つため、分割することで実質的な容量が増える
重要情報を前に
- title、meta description、構造化データ、canonicalは必ず最初の100KB以内に
- これらが2MB以降に配置されることはまずないはずだが、念のため
base64画像の使用を最小限に
- ファビコンなど小さな画像以外は外部ファイルに

レンダリングの制約

WRSがステートレスであることは重要です。

つまり、以下のような実装は問題を引き起こす可能性があります。

localStorageに依存した初期化
セッションに依存したコンテンツ表示
Cookie依存のコンテンツ

これらは、通常のユーザーには表示されても、Googlebotには見えない可能性があります。

15MBのデフォルト制限

興味深いのは、「制限を指定しないクローラー」のデフォルトが15MBという点です。

これは、Google検索以外のクローラーの方が、より多くのデータを取得する可能性があることを意味します。

測定と監視

残念ながら、自社ページが実際に2MB制限に引っかかっているかを確認する公式ツールはありません。

確認方法

ページサイズを測定
- ブラウザの開発者ツールでHTMLファイルサイズを確認
- 1.8MB以上なら要注意
Fetch as Google（URL検査ツール）
- Search Consoleでレンダリング結果を確認
- 重要なコンテンツが表示されているか検証
サーバーログ分析
- Googlebotへの応答サイズを確認