「自社のページがGoogleにきちんと登録されているか不安」「重要なコンテンツが検索結果に出てこない理由がわからない」「ページの容量はどこまで許容されるのか、明確な基準が知りたい」——このような疑問を抱えていませんか？
2026年3月にGoogle検索の公式ブログで、これまであまり語られてこなかった「Googlebot（Googleのウェブ巡回プログラム）が1ページから取得するデータ量の上限」について、興味深い解説が公開されました。結論から述べると、Googlebotは1つのHTMLファイルにつき最大2MB（メガバイト）までしか取得しないという、明確な上限が存在します。
多くのウェブ担当者にとって、この事実は意外に映るかもしれません。クロール（ウェブページを巡回して情報を読み取る作業）は無制限に行われていると思い込んでいた方も少なくないでしょう。しかし実際には、Googleは技術的・運用的な制約のもとで、サイトから読み取る情報量にしっかりと上限を設けているのです。
そこで本記事では、Googleが2026年3月に公開した公式情報をもとに、Googlebotのクロールの仕組み、2MBという上限の意味、自社サイトで気をつけるべきポイント、そして今日から実践できる具体的な対策まで、SEO初心者の方にも理解できるよう順を追って解説します。読み終わるころには、自社サイトのHTML構造を見直すための実用的な視点が身についているはずです。
記事執筆者：認定SEOコンサルタント 三田健司
そもそもGooglebotとは？よくある誤解を解く
2MBの上限について理解する前に、まずは「Googlebot」そのものに関する誤解を解いておきましょう。Googlebotという名称は広く知られていますが、その実態を正確に把握している方は意外に少ないものです。ここでは、Googlebotが実際にどのような構造になっているのかを、Googleの公式情報をもとに整理します。
Googlebotは「単一のクローラー」ではない
「Googlebot」と聞くと、インターネット上を24時間休みなく巡回しているたった1つのプログラムをイメージする方が多いのではないでしょうか。しかし、実際は少し違います。Googleが公式に説明しているように、現在のGooglebotは一元化されたクロール基盤のなかで動作する一つのクライアント（利用プログラム）にすぎません。
つまり、サーバーログ（サイトへのアクセス記録）に「Googlebot」という名前で残っているのは、Google検索のためのクロールリクエストだけです。Googleショッピング、AdSense（広告配信サービス）、画像検索、動画検索など、Googleが提供する数十種類のサービスは、それぞれ異なるクローラー名（ユーザーエージェントと呼ばれる識別子）を使って同じ基盤を経由しています。Googlebotという一つの呼び名でまとめても、実際には用途ごとに別のクライアントが動いているということです。
Googleが提供するクローラーの一覧については、Google クローラーの概要（公式ドキュメント）で確認できます。自社サイトのアクセスログを分析する際の参考になりますので、一度目を通しておくことをおすすめします。
なぜこの違いを知ることが大切なのか
クローラーの種類を区別できるようになると、サーバーログの分析精度が大きく向上します。たとえばサーバーログに「Googlebot」と表示されていればGoogle検索からの巡回、「Googlebot-Image」であれば画像検索からの巡回、「AdsBot-Google」であればGoogle広告に関わる巡回だと判断できます。
このように識別できると、自社サイトのどのコンテンツがどのGoogleサービスから注目されているのかを正確に把握できます。とくに画像コンテンツが豊富なサイトや、広告配信を行っているサイトでは、それぞれのクローラーの動きを追うことで運用上の改善点が見えてくるでしょう。
Googlebotには「データ量」の取得上限がある
クローラーの基本構造を押さえたところで、いよいよ本題に入ります。Googleの公式情報によれば、Googlebotには1つのURL（ウェブページのアドレス）から取得できるデータ量に明確な上限が設定されています。この上限はファイルの種類によって異なるため、まずは全体像を把握しておきましょう。
コンテンツ別の取得上限一覧
ファイルの種類ごとに、どこまで取得されるのかは以下のとおりです。
| ファイルの種類 | 取得データ量の上限 |
|---|---|
| HTMLなどの通常のURL | 2 MB（HTTPヘッダー含む） |
| PDFファイル | 64 MB |
| 上限指定のないクローラー | デフォルト15 MB |
| 画像・動画 | プロダクトごとに大きく異なる（ファビコンは特に低め） |
ここで注目したいのは、HTMLファイルの上限が2MBに設定されているという点です。Googlebotがあなたのサイトの1ページを訪問したとき、HTMLは最初の2MBまでしか読み込まれません。それ以降のデータは、たとえページ内に存在していても取得されないのです。
この2MBには何が含まれるのか
2MBという上限は、HTTPレスポンスヘッダー（サーバーがブラウザに返す通信情報の冒頭部分）を含めた合計値です。HTMLのソースコード本体に加え、HTML内に直接埋め込まれたCSS（ウェブページの見た目を整える記述）、JavaScript（ページに動きを加えるプログラム）、base64という形式でテキストに変換された画像、構造化データ（検索エンジンに情報を整理して伝える特殊な記述）など、ページに含まれるすべての要素が合算されます。
これらをすべて足し合わせて、最初の2MBまでがクロール対象となるのです。なお、外部ファイルとして読み込まれるCSSやJavaScript、画像などは、それぞれ別のURLとして扱われ、独立した2MBの上限が適用されます。この区別が、後ほど解説する対策の根拠になりますので、しっかり覚えておきましょう。
上限の2MBを超えるとどうなる？
「もし自社のページが2MBを超えたら、どうなってしまうのだろう？」と不安を覚えた方もいるかもしれません。Googleは公式ブログのなかで、上限を超えた場合の挙動について明確に説明しています。ここを正しく理解することが、SEO上のリスク回避に直結します。
ページ自体が拒否されるわけではない
まず安心していただきたいのは、HTMLが2MBを超えていても、Googlebotがそのページを丸ごと拒否することはないという点です。ページが完全に無視されるわけではなく、Googlebotは最初の2MBまで取得した時点でデータの読み込みを停止する、という挙動になります。
取得した部分だけが「完全なファイル」として扱われる
ここが非常に重要なポイントです。Googleは取得した最初の2MB分を、あたかもそれが完全なHTMLファイルであるかのように処理します。インデックス登録システム（検索データベースに情報を登録する仕組み）にも、ウェブレンダリングサービス（ブラウザのようにページを再現する仕組み）にも、2MBで切り取られたHTMLがそのまま渡されるのです。
つまりGoogleは、あなたのページの後半に何が書かれていたとしても、それを「もともと無かったもの」として扱います。ここがクロール上限の最大の落とし穴と言えるでしょう。
2MB以降のバイトは「存在しないもの」として扱われる
最も注意すべきなのが、この点です。2MBの境界より後ろにあるすべてのコンテンツは、Googleにとって完全に存在しないものとなります。ページの後半に記述された本文テキスト、構造化データ、canonical URL（重複ページの正規版を示す指定）、noindex（検索結果に表示しないための指定）といったSEOディレクティブも、すべて認識されません。
これは想像以上に深刻な問題を引き起こす可能性があります。たとえば、せっかく構造化データをページ後半に配置していたのに評価対象にならないケース、noindexを指定していたのにインデックスされてしまうケース、商品ページの説明文の後半が検索結果に反映されないケース。これらの事態が、サイト運営者の知らないうちに起きている可能性があるのです。
外部リソースは別カウントで処理される
ただし安心材料もあります。HTML内で参照されている外部のCSSファイル、JavaScriptファイル、画像ファイルなどは、それぞれ独立したURLとして扱われます。それぞれに対して2MBの上限が個別に適用されるため、外部ファイルに分割すれば、HTML本体の2MB枠を圧迫することはありません。
これが、後ほど詳しく解説する「重いリソースは外部ファイル化する」というベストプラクティスの根拠です。インラインで何でも詰め込む実装と、適切に外部化された実装では、Googleからの認識のされ方に大きな差が生まれることになります。
レンダリング（WRS）の仕組みとSEOへの影響
Googlebotがデータを取得した後、その情報はウェブレンダリングサービス（WRS：Web Rendering Service）と呼ばれる仕組みに渡されます。レンダリングとは、ブラウザがHTMLを解釈して実際の画面を構築する処理のことを指します。ここでもデータ量の上限が関係してくるため、押さえておきましょう。
WRSが行っている処理の中身
WRSは、最新のブラウザと同じようにHTMLを解釈し、JavaScriptやCSSを実行して、ページの最終的な表示状態を構築する仕組みです。具体的にはJavaScriptファイルを取得して実行し、CSSファイルを適用してデザインを再現し、XHR（ページを再読み込みせずにサーバーとデータをやり取りする技術）リクエストを処理して、最終的なテキストや構造を把握します。なお、画像や動画はレンダリング段階では取得されません。
WRSの動作についてはJavaScript SEOの基本（公式ドキュメント）でも詳しく解説されていますので、JavaScriptを多用するサイトを運用している方はあわせて確認しておくことをおすすめします。
WRSが取得する各リソースにも2MBの上限がある
ここで重要なのは、WRSが取得するJavaScript、CSS、XHRレスポンスといった各リソースにも、それぞれ2MBの上限が個別に適用されるという点です。たとえば3MBある巨大なJavaScriptファイルを読み込ませていた場合、最初の2MBまでしか実行されません。その結果、ページの動作が想定通りにならない可能性が出てきます。
WRSは「ステートレス」で動作する
WRSにはもう1つ重要な特徴があります。それは、WRSがステートレスで動作することです。ステートレスとは「前の状態を覚えていない」という意味で、リクエストごとに毎回まっさらな状態から処理を始めることを指します。
具体的には、WRSはリクエスト間でlocalStorage（ブラウザにデータを保存する仕組み）の内容をクリアし、セッションデータも引き継がず、Cookieも基本的に保持しません。このため、localStorageやセッションデータに依存して表示が変わるコンテンツは、Googleが正しく認識できない可能性があります。動的なJavaScriptサイトを構築する際は、特に注意が必要なポイントと言えるでしょう。
普通のサイトで2MBに達することはあるのか
ここまで読んで、「自社サイトは大丈夫だろうか」と心配になった方もいるかもしれません。結論から申し上げると、ごく一般的な作りのWebサイトであれば、2MBに達することはほぼありません。ただし、特定の実装パターンに該当するサイトでは、知らないうちに上限を超えている可能性もあります。実際の数値感覚を持っていただくために、現状を整理しておきましょう。
一般的なWebページのHTMLサイズ
実際のWebページのHTML本体（外部リソースを除く）のサイズは、おおよそ次のような分布になっています。
| ページの種類 | HTMLサイズの目安 |
|---|---|
| シンプルなブログ記事 | 20〜100 KB |
| 一般的な企業サイトのページ | 50〜200 KB |
| ニュースサイトの記事ページ | 100〜300 KB |
| ECサイトの商品ページ（レビュー多数） | 200〜500 KB |
| 大規模なまとめページやランディングページ | 300〜800 KB |
ほとんどのページは2MBの10〜25%程度に収まっているのが実情です。Googleが公式ブログのなかで「ウェブの大部分では、この上限に達することはない」と明記しているのも、こうしたデータの裏付けがあるからこそでしょう。
2MBに到達する可能性がある実装パターン
逆に言えば、特定の実装パターンに当てはまるサイトは、知らないうちに2MBへ近づいていることがあります。最も多い原因は、画像をbase64形式（画像データをテキストに変換するエンコード方式）でHTMLに直接埋め込んでいるケースです。1枚の画像で数百KB〜数MBになることもあり、これが容量を一気に圧迫します。
次に多いのが、CSSやJavaScriptを外部ファイルにせず、HTML内のstyleタグやscriptタグの中に大量のコードをインラインで書き込んでいるケースです。BootstrapやjQueryなどのライブラリ（よく使われる機能をまとめた部品集）を丸ごとインライン化している例も実在します。
また、SPA（シングルページアプリケーション。1ページで完結するウェブアプリの作り）の初期データや、商品カタログ全件をHTML内に出力しているケースも要注意です。古いCMSやGUI型のページビルダーが生成した、不要に複雑なタグ構造を持つHTMLも、気づかぬうちに容量を膨らませている原因となります。さらに、開発時にコメントアウトされたまま残された大量の旧コードも、意外と容量を食う原因になっているのです。
文字数だけで2MBに達するのは現実的ではない
純粋な日本語の文章だけで考えると、UTF-8（ウェブで使われる標準的な文字コード）では1文字あたり約3バイトになります。2MB（約2,097,000バイト）を3バイトで割ると約70万文字となり、これが理論上の上限です。実際にはHTMLタグやデザイン要素が入るため、本文として収まる文字数の目安は15万〜30万文字程度になります。
新書1冊の文字数が約10〜15万文字であることを考えると、Webページの文字量だけで2MBに達するのは、まずあり得ない話だと言えるでしょう。問題になるのはあくまで文字以外の重い要素が大量に含まれているケースだと、明確に区別して理解しておきましょう。
今日からできる具体的な対策5選
2MBに到達する可能性が低いとはいえ、せっかく作ったコンテンツが正しくGoogleに認識されないリスクは避けたいものです。ここでは、SEO担当者の方が今日から取り組める具体的な対策を5つに絞ってご紹介します。いずれも特別なツールや費用を必要とせず、運用の見直しだけで実践できる内容です。
1. 重要な要素はHTMLの上部に配置する
これは最も基本的かつ重要な対策です。万が一カットオフ（2MBで切り取られる現象）が発生した場合に備えて、SEO上重要な要素はHTMLの先頭に近い位置に配置しましょう。具体的には、titleタグ、descriptionやog:imageなどのmetaタグ、canonicalを指定するlinkタグ、構造化データ（JSON-LD形式の記述）、noindexやnofollowなどのSEO指示が該当します。
これらの要素は必ずheadセクション内、もしくはbody直後の早い段階に配置するのが鉄則です。仮に2MBの境界がページの後半で訪れたとしても、重要な情報がカットされるリスクを最小限に抑えられます。
2. CSSとJavaScriptは外部ファイル化する
インラインで書かれたCSSやJavaScriptは、HTML本体の容量を大きく圧迫します。可能な限り外部ファイル化を進めましょう。styleタグの中に書いている記述は外部CSSファイルに切り出し、scriptタグの中のコードは外部JSファイルに移動させます。
外部ファイルはそれぞれ独立した2MB枠を持つため、HTML本体の容量を効率的に削減できます。あわせてページの表示速度向上にもつながるため、ユーザー体験の観点からも有効な施策です。
3. base64画像のインライン埋め込みを避ける
画像はHTML内に埋め込まず、通常のimgタグで外部ファイルとして参照するのが原則です。base64によるインライン埋め込みは、HTTPリクエスト数（サーバーへの問い合わせ回数）を減らせるメリットがありますが、HTML容量が膨らむデメリットの方がはるかに大きい場合がほとんどです。
例外的に、サイズが極めて小さなアイコンなど、ファイル分割の管理コストの方が問題になるケースのみインライン化を検討する程度に留めましょう。それ以外は外部ファイルとして扱うのが賢明です。
4. サーバーログを定期的にモニタリングする
Googlebotの挙動は、サーバーログから観察できます。どのページがクロールされているか、レスポンスタイム（サーバーが応答するまでの時間）は適切か、404や500などのエラーは発生していないか、といった点を定期的にチェックしましょう。
とくにレスポンスが遅い場合、Googleはサーバーへの負荷を避けるためにクロール頻度を自動的に下げることがあります。これは新しいページが検索結果に反映される速度にも影響するため、見過ごせないポイントです。
5. Search Consoleとデベロッパーツールで容量をチェックする
ページの実際の容量は、複数の方法で確認できます。最も手軽なのは、Chromeブラウザのデベロッパーツールを使う方法です。F12キーで起動し、Networkタブを開いてページをリロードすると、一番上に表示される文書（HTMLファイル）のSize列で転送サイズを確認できます。
あわせてGoogle Search ConsoleのURL検査ツールを使えば、Googleが実際にどのようにページを認識しているかを確認できます。「レンダリングされたHTML」を表示させ、想定通りのコンテンツがすべて含まれているかを確認しましょう。HTML容量が500KBを超えている場合は、内容を見直すべきサインだと考えてください。
Googlebotクロール上限に関するよくある質問
ここまで解説した内容について、ウェブ担当者から実際に寄せられることの多い質問を整理しました。記事の内容を補足する形でお読みいただければ、理解がさらに深まるはずです。
Q1. 2MBの上限は今後変わる可能性はありますか？
はい、Googleは公式ブログのなかで、この上限について「固定ではなく、ウェブの進化やHTMLページのサイズの拡大に伴って変更される可能性がある」と明言しています。今後、上限が引き上げられる可能性も、引き下げられる可能性も両方あるということです。とはいえ、重要な情報をHTML上部に配置するというベストプラクティスは、上限の数値に関係なく有効ですので、基本方針として押さえておきましょう。
Q2. 2MBを超えそうなページがあるか、どう確認できますか？
Chromeのデベロッパーツール（F12キー）のNetworkタブで、各ページのHTML容量を確認できます。あわせてGoogle Search ConsoleのURL検査ツールを使えば、Googleが実際にどのようにページを認識しているかを確認することも可能です。レンダリング後のHTMLを表示し、想定通りのコンテンツがすべて含まれているかを目視でチェックするのが確実です。
Q3. 動画や音声ファイルにも上限はありますか？
動画や画像、音声などのメディアファイルについては、HTMLとは別の上限が設定されており、プロダクト（Google検索、画像検索、動画検索など）によって大きく異なります。ファビコンのように非常に小さい上限が設定されているものもあれば、画像検索のように比較的大きな上限のものもあります。一般的な運用では、メディアファイルのサイズが原因で問題になることは少ないですが、極端に大きなファイルはパフォーマンス上の理由からも避けるのが賢明です。
Q4. JavaScriptで動的に表示するコンテンツも2MB制限の対象ですか？
動的に生成されるコンテンツも、最終的にはJavaScriptファイルやXHRレスポンスとして配信されるため、それぞれに2MBの上限が適用されます。また、Googleのレンダリングサービス（WRS）はステートレスで動作するため、localStorageやセッションに依存するコンテンツは正しく認識されない可能性があります。重要なコンテンツは、サーバーサイドレンダリング（サーバー側でHTMLを生成して配信する仕組み）や静的HTMLとして提供することをおすすめします。
Q5. PDFファイルも2MBが上限ですか？
いいえ、PDFファイルは別枠で、上限は64MBに設定されています。HTMLよりもはるかに大きな上限です。とはいえ、64MBを超える巨大なPDFはユーザー体験的にも好ましくないため、適切なサイズに収めることをおすすめします。検索結果に表示させたいPDFがある場合は、容量だけでなく内部のテキスト構造にも気を配りましょう。
まとめ：重要な情報を「取得される位置」に届ける
Googlebotには1つのHTMLにつき2MBまでという取得上限があり、それを超えた部分はインデックス登録もレンダリングも行われません。一般的なWebサイトであればこの上限に達することはまずありませんが、インライン化された重い要素やbase64画像が多用されているサイトでは要注意です。重要な要素はHTMLの上部に配置し、CSSやJavaScriptは外部ファイル化することで、HTML本体を軽量に保つことができます。あわせてページ容量とサーバーレスポンスを定期的にモニタリングする運用体制を整えておくと、長期的にも安心です。
クロールという仕組みは、決して魔法のように動いているわけではありません。Googleが取得できるデータ量には明確な上限があり、その範囲内でいかに重要な情報を提供するかが、SEOの基本になります。Googlebotはあなたが作ったページの「最初の2MB」を見て、そのページの価値を判断するのです。だからこそ、最も伝えたいメッセージは、必ずカットオフより前に届くように設計する必要があります。
「ページのSEOがうまくいっていない」「重要なコンテンツが評価されていない気がする」とお悩みの方は、まず一度、自社サイトのHTML構造を見直してみてはいかがでしょうか。シンプルな整理だけでも、検索エンジンへの伝わり方は大きく変わるはずです。
株式会社アクセス・リンクでは、SEOコンサルティングを通じて、技術的な観点からサイトのパフォーマンス改善をサポートしています。「自社サイトのクロール状況が気になる」「Googleに正しく認識されているか確認したい」という方は、ぜひ一度ご相談ください。認定SEOコンサルタントが、あなたのサイトに最適な改善策をご提案いたします。
参考情報
- Google Search Central Blog「Googlebot の内部: クロール、取得、処理するバイトの謎を解く」（2026年3月31日公開）
- Google クローラーの概要（公式ドキュメント）
- JavaScript SEO の基本を理解する（公式ドキュメント）
- Google Search Console
- Chrome DevTools 公式ドキュメント
記事執筆・株式会社アクセス・リンク 代表取締役
Webサイト制作歴10年以上の経験を元にSEOコンサルティングを行い、延べ1,000件以上のサポート実績を誇ります。個人事業主や中小企業向けのホームページ制作やSEOコンサルティングを得意としています。
（社）全日本SEO協会 認定SEOコンサルタント
コメント