Googleのクローラーである「Googlebot」が読み込めるHTMLファイルのサイズには、最初の2MBまでという上限が設けられています。この制限を超えたコンテンツは検索エンジンに認識されず、せっかく作成した情報が検索結果に反映されない「インデックス漏れ」を引き起こすおそれがあります。
「うちのサイトは大丈夫だろうか」と不安に感じた方もいるかもしれません。実際、Base64画像の多用やインラインのCSS・JavaScriptを大量に含むページでは、知らないうちにこの上限に達しているケースが報告されています。本記事では、2MB制限の正しい仕様から、制限に引っかかりやすい原因、そしてインデックス漏れを防ぐための具体的なクロール最適化とSEO対策までをわかりやすく解説していきます。
GooglebotのHTML「2MB制限」とは？ファイルサイズ上限の真実
Googlebotの2MB制限について調べると、「以前は15MBだったのに2MBに縮小された」という情報を目にすることがあるかもしれません。この噂はSEO関連のコミュニティで大きな話題となりましたが、結論からいえば誤解です。まずはこの制限の正確な内容を押さえておきましょう。
制限は15MBからの縮小ではなく最初から2MBだった
2024年頃、Google検索セントラルの公式ドキュメントが更新されたことをきっかけに、「Googlebotのクロールサイズ上限が15MBから2MBに引き下げられた」という情報がSEO業界で駆け巡りました。しかし実際には、もともとGooglebotがHTMLファイルに対して適用していた取得上限は2MBであり、15MBという数値はHTMLだけでなく画像やPDFなども含めたすべてのリソースに対する全体的な制限値でした。
つまり、仕様が変更されたわけではなく、公式ドキュメント上での記載場所が移動し、説明がより明確になっただけというのが実情です。Googleの公式見解としても、HTMLのファイルサイズ上限は以前から2MBに設定されていたと説明されています。この経緯を知らずに「急に制限が厳しくなった」と慌てる必要はありませんが、2MBという上限そのものはれっきとした事実ですので、しっかり意識しておくことが大切です。
2MB制限を超えるとどうなる？インデックス漏れのリスク
では、HTMLファイルが2MBを超えてしまった場合、具体的に何が起こるのでしょうか。Googlebotはページのソースコードを先頭から順番に読み込みますが、2MBに到達した時点で読み取りを打ち切ります。そのため、2MB以降に記述されたコンテンツはすべて無視されることになります。
この仕組みが引き起こすリスクを整理すると、以下のとおりです。
- ページ後半に配置したテキストコンテンツがGoogleに認識されず、検索結果に反映されない
- 2MB以降に記述された内部リンクや外部リンクがクローラーに発見されず、リンク先のページのクロールにも悪影響が及ぶ
- 構造化データ（JSON-LD）をHTMLの末尾に配置している場合、リッチリザルトが表示されなくなる可能性がある
- ページ全体の評価が不完全になり、本来獲得できるはずの検索順位を逃してしまう
特に注意したいのは、テキストだけでなくリンク情報も失われるという点です。サイト内の回遊を促すために設置したナビゲーションやフッターのリンクが読み込まれなければ、サイト全体のクロール効率が低下してしまいます。目に見えないところで大きな損失が発生しかねないため、自サイトのHTMLファイルサイズは定期的に確認しておくべきでしょう。
HTMLが2MB制限に引っかかる原因と注意すべき4つのケース
「HTMLファイルが2MBを超えることなんてあるの？」と感じる方もいるかもしれません。たしかに、テキストだけで構成された一般的なWebページの平均的なHTMLサイズは22KB前後といわれており、通常の記事ページであれば2MBにはほど遠い数値です。しかし、特定の実装方法を採用しているサイトでは、思いのほか簡単にこの上限に近づいてしまうことがあります。ここでは、制限に引っかかりやすい代表的な4つのケースを解説します。
Base64画像の多用によるファイルサイズ肥大化
Base64画像とは、画像データをテキスト文字列に変換してHTMLソースコードの中に直接埋め込む方式のことです。通常、画像はサーバー上に別ファイルとして保存し、HTMLからはそのファイルパスを参照するだけで済みます。ところがBase64で埋め込むと、画像の情報がすべて長大な英数字の文字列としてHTML内に展開されるため、たった数枚の画像でもファイルサイズが一気に膨れ上がってしまいます。
たとえば、100KBの画像をBase64エンコードすると約133KBの文字列になります。こうした画像を15枚ほど埋め込むだけで、それだけで約2MBに達してしまう計算です。サムネイル画像を一覧表示するページや、アイコンをBase64で管理しているサイトは特に注意が必要でしょう。
過剰なインラインCSSやJavaScript
CSSやJavaScriptを外部ファイルとして読み込まず、HTMLの中にそのまま記述する「インライン」方式も、ファイルサイズを押し上げる大きな要因です。ページの表示速度を最適化する目的でクリティカルCSSをインライン化するケースはありますが、サイト全体のスタイルシートをまるごとHTML内に埋め込んでしまうと、本文のテキストが始まる前の段階でかなりの容量を消費してしまいます。
JavaScriptについても同様で、分析用のトラッキングコードやウィジェットのスクリプトを複数インラインで記述していると、積み重なって予想以上のサイズになることがあります。外部ファイルとして読み込んだリソースにはそれぞれ個別に2MBの制限が適用されるため、HTMLの中に詰め込むよりも外部に分離するほうがクロールの観点からは有利です。
無駄なHTMLコメントやデバッグ情報の出力
開発段階で挿入したHTMLコメントやデバッグ用の情報が、本番環境にそのまま残っているケースも見受けられます。CMSやフレームワークが自動的に出力するコメントタグは、1つひとつは小さくても、数百ページ分のテンプレートに蓄積すると無視できないサイズになることがあります。
また、サーバーサイドのテンプレートエンジンがレンダリング時に生成する不要な空白行やインデント、条件分岐の痕跡なども、ファイルサイズを地味に増加させる原因です。こうした「見えないゴミ」は表示上の問題を起こさないため気づきにくいのですが、クロール最適化の観点からは定期的にソースコードを確認してクリーンアップすることをおすすめします。
SPA（シングルページアプリケーション）の初期ロード
ReactやVue.jsなどのフレームワークで構築されたSPA（シングルページアプリケーション）では、アプリケーション全体のロジックやルーティング情報が初期HTMLに含まれることがあります。特にサーバーサイドレンダリング（SSR）を導入している場合、レンダリング済みのHTMLとクライアント側で再実行するためのJavaScriptの両方がソースコードに含まれるため、ページによっては非常に大きなHTMLが生成されることがあるのです。
加えて、SPAでは状態管理のための初期データがJSON形式でHTML内にインライン展開されるケースも多く、取り扱うデータ量が多いページほど2MB制限に近づくリスクが高まります。GoogleのWeb Rendering Service（WRS）はJavaScriptを実行してレンダリング結果を評価しますが、その前段階であるHTMLの取得時にファイルサイズが2MBを超えていれば、後続のレンダリング処理にも影響が及ぶ点を忘れないようにしましょう。
ここまで紹介した4つのケースを原因とリスクの観点で整理すると、次の表のようになります。
| 原因 | 具体例 | SEOへのリスク |
|---|---|---|
| Base64画像の多用 | 商品一覧ページに画像を直接埋め込み | 数枚で数百KBに達し、2MB超過の主要因になる |
| 過剰なインラインCSS/JS | サイト全体のスタイルやトラッキングコードをHTML内に記述 | 本文テキストの読み込み前に容量を圧迫する |
| HTMLコメント・デバッグ情報 | 開発時のメモやCMSの自動出力コメント | 蓄積すると数十KB規模に膨らむことがある |
| SPAの初期ロード | SSRによるHTML肥大化、初期データのインライン展開 | レンダリング前のHTML取得段階で制限に抵触するおそれがある |
自社サイトのHTMLファイルサイズを確認する方法
2MB制限のリスクを理解したところで、次に気になるのは「自分のサイトは大丈夫なのか」という点ではないでしょうか。幸いなことに、HTMLファイルサイズの確認は特別な知識がなくても手軽に行えます。ここでは、すぐに実践できる2つの確認方法を紹介します。
Chromeの「DevTools」を使ったチェック手順
もっとも手軽な方法は、Google Chromeに標準搭載されている開発者ツール「DevTools」を使うやり方です。追加のソフトウェアをインストールする必要がなく、普段使っているブラウザだけで完結します。以下の手順で確認してみてください。
- Chromeで対象のページを開き、キーボードの「F12」キーを押してDevToolsを起動する
- 上部のタブから「Network（ネットワーク）」を選択する
- 「Disable cache（キャッシュを無効化）」にチェックを入れる
- そのままページを再読み込み（Ctrl+R または Cmd+R）する
- 表示された一覧の中から、一番上にあるHTMLドキュメント（ページのURLと同じ名前のファイル）をクリックする
- 「Response Headers」や「Size」の列で、非圧縮時のファイルサイズを確認する
ここで注意したいのは、サーバーからブラウザへの転送時にはgzip圧縮が適用されていることが多い点です。ネットワークタブに表示される転送サイズは圧縮後の値であるため、実際のHTMLファイルサイズとは異なります。Googlebotの2MB制限は非圧縮の状態に対して適用されるため、必ず「Response」タブでソースコードの実サイズを確認するようにしましょう。
無料のSEOツール「2MB制限チェッカー」を活用する
DevToolsの操作に慣れていない方や、複数のURLをまとめてチェックしたい場合には、Web上で公開されている無料の診断ツールを利用するのも一つの手です。対象のURLを入力するだけで、そのページのHTMLファイルサイズが2MBを超過していないかを自動で判定してくれます。
こうしたツールの多くは、ファイルサイズの数値に加えて「安全」「注意」「超過」といったわかりやすいステータスを表示してくれるため、技術的な知識が少ない方でも直感的に結果を把握できるのが利点です。サイトリニューアルやページ追加のタイミングで定期的にチェックする習慣をつけておくと、意図せず制限を超えてしまうリスクを未然に防げるでしょう。
2MB制限を回避するクロール最適化とSEO対策
ファイルサイズの現状を把握できたら、次は具体的な改善策に取り組む番です。ここで紹介する対策はどれも技術的に難易度が高いものではなく、基本的なWeb制作の延長線上で実施できるものばかりです。一つずつ着実に対応していきましょう。
HTMLの不要なコード削除・軽量化（Minify）
最初に取り組みたいのが、HTMLソースコードの軽量化、いわゆる「Minify（ミニファイ）」です。Minifyとは、コードの動作に影響を与えない余計な空白・改行・コメントを自動的に除去し、ファイルサイズを圧縮する手法を指します。
たとえば、開発時に読みやすさのために入れたインデントや、CMSが自動生成する不要なコメントタグは、ブラウザの表示にもSEOにも一切貢献しません。これらを削除するだけで、ページによっては数十KBの削減が見込めます。WordPressなどのCMSを利用している場合は、Minify機能を備えたプラグインを導入すれば手動での作業は不要です。
CSSやJavaScriptの外部ファイル化
前半でも触れたとおり、インラインで記述されたCSSやJavaScriptはHTMLファイルサイズを直接的に押し上げます。この問題を解消するもっとも効果的な方法が、これらのコードを外部ファイルとして分離することです。
ここで押さえておきたいのは、Googlebotの2MB制限はリソースの種類ごとに個別に適用されるという仕組みです。つまり、HTMLファイルに2MB、外部CSSファイルに2MB、外部JavaScriptファイルに2MBと、それぞれ別枠で上限が設けられています。大量のスタイル定義やスクリプトをHTML内に詰め込むのではなく、外部ファイルとして切り出すことで、HTML本体の容量を本文テキストのために確保できるわけです。
Search Consoleの「URL検査」ツールを使えば、Googlebotがページをどのようにレンダリングしているかをスクリーンショットで確認できます。外部ファイル化の後に意図したとおりの表示が維持されているか、併せてチェックしておくと安心でしょう。
画像のLazy Load（遅延読み込み）の導入
Base64画像の埋め込みをやめて通常の画像ファイルに置き換えることは大前提ですが、さらに一歩進んだ対策としておすすめしたいのが「Lazy Load（遅延読み込み）」の導入です。
Lazy Loadとは、画面に表示される範囲に入ったタイミングで初めて画像を読み込む仕組みのことです。この方法を採用すれば、初期ロード時に読み込まれるHTMLにはすべての画像情報を含める必要がなくなり、ファイルサイズの大幅な削減が期待できます。実装も比較的簡単で、HTMLのimgタグに「loading=”lazy”」という属性を追加するだけで、主要なブラウザではネイティブにLazy Loadが機能します。
ただし、ファーストビュー（ページを開いた直後に見える領域）に表示される画像にまでLazy Loadを適用すると、表示速度の体感が悪化するおそれがあるため、適用範囲は画面外の画像に限定するのがベストプラクティスです。
まとめ：Googlebotの2MB制限を正しく理解しSEO対策を万全に
Googlebotが取得できるHTMLのファイルサイズ上限は2MBであり、これは以前からの仕様です。Base64画像の多用やインラインCSS/JSの肥大化によってこの制限を超えると、ページ後半のコンテンツやリンクがインデックスされないリスクが生じます。Minifyによるコード軽量化、CSSやJavaScriptの外部ファイル化、Lazy Loadの活用といったクロール最適化を実施し、検索エンジンにすべてのコンテンツを確実に届けましょう。
まずは今日、DevToolsやチェッカーツールで自サイトの主要ページのファイルサイズを確認するところから始めてみてください。現状を把握することが、インデックス漏れのない万全のSEO対策への第一歩です。