Googlebotは、あなたのページを丸ごと読んでいるわけではありません。
実は最初の2MBだけを取得して、残りは完全に無視しています。
この記事では「2MBってどのくらい？」「何が原因で超えるの？」を具体的な例で解説します。
まず「Googlebot」って何者？
「Googlebot＝1台のロボットが世界中のWebを巡回している」とイメージしがちですが、実際は違います。GooglebotはGoogle社内の共通クロールインフラへのアクセス名です。
Google検索・Google ショッピング・AdSenseなど、数十のサービスが同じインフラを通じてページを取得しており、ログに残る「Googlebot」はそのうちのGoogle検索によるリクエストです。Googlebot以外のクローラー名はGoogleのドキュメントで確認できます。
2MBルールとは？
Googlebotは1つのURLにつき、先頭から2MBぶんのデータだけを取得します。2MBに達した瞬間に取得をぴったり止め、残りのHTMLは一切取得しません。
Set-Cookie・Content-Security-Policy・Link プリロードなど大量のヘッダーがあると、本文に使える容量がその分削られます（一般的なヘッダーで数KB〜数十KB）。
ビジュアルで見る「2MBの壁」
Googlebotの2MB制限イメージ図：最初の2MBは取得・インデックス登録、それ以降は完全無視される様子を示す帯グラフ
↑ 上記の図が示すようにHTMLは先頭2MBだけ取得。それ以降のバイトはインデックスにも届かない。
2MBって実際どのくらい？
（UTF-8 で1字3バイト）
日本語テキストで約67万字・HTML換算で約2〜2.5万行。通常のページならまず問題なし！
改めて整理すると：
- 📖 日本語テキスト： 約67万字（文庫本2〜3冊分）
- 📖 英語テキスト： 約200万字・単語35万語
- 💻 HTMLのコード行数： 約20,000〜25,000行（インデント込み）
普通のページなら絶対に超えません。超えるのはページに「余計な重さ」が含まれているとき。
クローラー別・取得サイズ上限
Googlebotだけでなく、Googleのクローラー全体でサイズ制限が決まっています。
| クローラー | 上限サイズ | 対象コンテンツ | 備考 |
|---|---|---|---|
| Googlebot（HTML） | 2 MB | Webページ全般 | HTTPヘッダーを含む |
| Googlebot（PDF） | 64 MB | PDFファイル | HTML用とは別枠 |
| 画像クローラー / 動画クローラー | 製品による | 画像・動画 | faviconは超小さい〜Image Searchは大きい |
| その他クローラー（上限未指定） | 15 MB | コンテンツタイプ問わず | デフォルト値 |
取得後に何が起きる？ レンダリング（WRS）をわかりやすく
Googlebotがバイトを取得した後、それを「見える状態」にするのが レンダリング（WRS / Web Rendering Service） というシステムです。
あなたがChromeでWebページを開くと、きれいに整ったサイトが表示されますよね。それはブラウザがHTMLを読み込み、JavaScriptを実行して、文字を並べ、画像を表示してくれているからです。この「変換作業」がレンダリングです。
レンダリングは、Googleが持っているそのブラウザの役割を果たすシステムです。Googlebotが取得したHTMLを受け取り、実際のブラウザと同じようにページを組み立てて、「このページには何が書いてあるか」をインデックスに登録します。
流れを図で見ると
HTMLを取得
（最大2MB）
外部から取得
（各自2MB枠）
JSを実行
画面を構築
構造を
インデックス登録
のバイトは
🚫 無視
レンダリング（WRS）の3つの重要な制約
① 取得できたコードしか実行しない
2MBを超えた部分にJavaScriptが書いてあっても、レンダリング（WRS）はそれを実行しません。2MB以降の動的コンテンツはGooglebotには存在しないも同然です。
② ローカルストレージ・セッションは毎回リセット
レンダリング（WRS）はページを「ステートレス（記憶なし）」で処理します。前回の訪問で保存したlocalStorageの値などはすべてクリアされた状態でレンダリングされます。ログイン状態に依存した動的コンテンツはインデックスされない可能性があります。
③ 画像・動画・フォントはリクエストしない
レンダリング（WRS）がテキストと構造の理解に集中するため、imgタグの画像ファイル本体は取得しません。ただし、CSS・JS・XHRリクエストは処理します。
2MBを超えやすい「犯人」はこれだ
① Base64埋め込み画像（最大の要注意ポイント）
通常、HTMLの中に画像を入れる場合は <img src="photo.jpg"> のようにURLを書きます。このとき画像ファイル本体は別途サーバーに置かれ、HTMLの容量には影響しません。
一方、Base64という方法を使うと、画像のデータそのものをHTML内にテキストとして直接書き込めます。画像が「1ファイルで完結」するメリットはありますが、データが文字列に変換されると元のファイルサイズの約1.33倍に膨れ上がります。
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA
...（数万文字が続く）...">
300KBの画像 → HTMLに約400KB分の文字列が追加される。画像10枚で4MB超え。
<img src="/images/photo.jpg" alt="説明">
HTMLへの影響はこの1行だけ（数十バイト）。画像は別のリクエストで取得される。
※ちなみに、Base64は「画像のデータそのものを文字列に変換してHTMLに直接埋め込む」方式です。画像ファイルを開いて中身を「abcdefghij…」みたいな文字の羅列に変換したものが base64, の後に延々と続きます。開発者向けの機能なので、普通に記事を書いているぶんには自分で使うことはまずないですが、WordPressテーマやプラグインが小さいアイコン画像などをBase64でHTMLに埋め込んでいることがあります。
② インラインCSS・JavaScript
スタイルシートやスクリプトを <style> や <script> タグで直接HTMLに書いていると、その分だけHTMLのサイズが増えます。外部ファイル（.css / .js）として読み込めば、それぞれが独自の2MB枠を持つため、親ページのサイズには影響しません。
③ ページ上部の巨大なナビゲーション
ページ先頭に何百もの項目を持つメニューがHTMLとしてあると、実際の本文コンテンツはかなり下の位置に来ます。2MBは「何行目か」ではなく「先頭からのバイト数」で決まるため、本文が2MB以降に押し出されてしまうことがあります。
④ 巨大な構造化データ（JSON-LD）
商品リストや大量のFAQなどをJSON-LDで記述する場合、それ自体が数百KBになることがあります。構造化データが2MB以降にあると、リッチリザルトの対象として認識されない恐れがあります。
今すぐできる対策チェックリスト
- <title>・canonical・構造化データ（JSON-LD） は <head> の早い段階、または <body> の先頭近くに配置する
- CSS・JSは外部ファイル化する（<style>・<script> をインラインで大量に書かない）
- Base64画像の埋め込みは原則禁止。画像は外部URLで参照する
- ページのHTML全体のサイズを確認する（Chrome DevTools → Network → ドキュメントのサイズを確認）
- サーバーの応答速度を監視する。応答が遅いとGooglebotが自動的にクロール頻度を下げる
- メタタグや重要なテキストがページ上部に集まっているか確認する
まとめ
Googlebotの2MB制限は、ほとんどのWebサイトには関係のない話です。しかし、Base64画像・大量のインラインCSS/JS・肥大したナビゲーションなどが重なると、意外と簡単に壁に当たります。
重要なのは「何が2MB以内に入っているか」です。重要なメタ情報・コンテンツ・構造化データを先頭近くに置き、重いリソースは外部化するという基本を守ることで、Googlebotにとって「読みやすいページ」になります。
参考：Inside Googlebot: demystifying crawling, fetching, and the bytes we process（Google Search Central Blog, 2026年3月）
