-
【SEO注意報?】Googlebotの「HTML 2MB制限」の真実。騒動の背景と本当にやるべき対策
-
-
-
岡野 貴映
2026.04.02(木曜日)
-
最近、X(旧Twitter)のSEO・Web制作界隈で「GooglebotはHTMLの先頭2MBまでしか読み込まないらしい!」「構造化データが無視されるかも!」という話題が大きくバズりました。日々Webメディアの運営やディレクションに関わっていると、こうしたアルゴリズムやクローラーの仕様明文化には非常に敏感になりますよね。
一部では「知らないとヤバい」とパニック気味な声も上がっていましたが、結論から言うと「ほとんどの人は心配しなくていい事案ですが、ShopifyやWordPressなどで重い作り方をしている場合は、念のためチェックと対策を」というのが実態です。
まぁ、ゴリゴリにカスタマイズしているWebサイトは要注意ってことです。
本記事では、Google検索セントラルの公式ブログで語られた内容を紐解きながら、この2MB制限の真実と、自分のサイトの確認方法、そしてWeb担当者が本当にやるべき対策について解説します。
1. Googlebotの「2MB制限」の公式仕様とは?
2026年3月末に公開されたGoogle検索セントラルブログでは、Googlebotのクロールとフェッチ(取得)の仕組みについて詳細が明かされました。具体的には以下のような仕様になっています。
- Googlebotは現在、個々のURLにつき最大2MBまでしかフェッチしません(PDFファイルの場合は64MBまで)。
- この「2MB」という制限には、HTTPレスポンスヘッダーも含まれます。(※「リクエストヘッダー」ではなく、サーバーからの「レスポンスヘッダー」です)
- HTMLファイルが2MBを超過している場合でもページが拒否されるわけではなく、きっちり2MBの地点でデータの取得が打ち切られます。
- 2MBのしきい値を超えた部分にあるデータは完全に無視され、フェッチも、レンダリングも、インデックスもされません。
- HTML内で参照されている外部リソース(CSSやJavaScriptなど)は、親ページとは別に独自のバイトカウンターを持っており、親の2MB制限にはカウントされません。ただし、それらの外部ファイルにも個別に同様の2MB制限が適用されます。
つまり、「HTMLファイルそのものの容量が大きすぎると、後ろの方に書いたコードはGoogleに認識されない」ということです。
この制限はWebの進化に合わせて将来変更される可能性があることも、Googleは公式に明言しています。「2MBが永続的な絶対ルール」ではない点も、頭に置いておきましょう。Webの進化は早いので、すぐ変わる可能性もありますし。。。
2. なぜ話題になったのか?「以前は15MBだった」という背景
この制限が話題を呼んだ背景には、重要なコンテキストがあります。それは「以前のGooglebotのフェッチ上限は15MBだった」という事実です。2026年2月にGoogleがドキュメントを更新し、Googlebot固有の制限が2MBであることが明文化されたことで、SEO界隈がざわつきました。今回の3月のブログ投稿は、その仕様をさらに詳しく解説したものです。
なお、15MBという上限はGoogle全体のクローラーインフラのデフォルト値として引き続き存在しており、「2MBへの変更」はGoogleの検索インデックス向けのGooglebot固有の値として文書化されたものです。
近年は、Shopifyでのリッチなセクション多用、WordPressでの過度なプラグイン導入などにより、HTMLソースコードが肥大化しやすい環境にあるからです。ブログ内でも警告されている通り、肥大化したインラインのBase64画像や、大量のインラインCSS/JavaScriptがHTMLに直書きされていると、実際のテキストコンテンツや重要な構造化データが2MBのラインより下に押し出されてしまう可能性があります。もし重要なバイトがフェッチされなければ、Googlebotにとってそれらは存在しないのと同じになってしまいます。
特に、<head> 内ではなくページの下部(フッター付近)に schema.org の構造化データや canonical タグを出力するような仕様のサイトは、「Googleに評価してもらいたい要素が見落とされるリスクがある」として注意喚起が広がりました。
3. 実務派の冷静な視点:普通のサイトは「ほぼ心配いらない」
警戒する声がある一方で、冷静に事実を見ると「大騒ぎするようなことではない」ことがわかります。Googleの公式ブログでも、「ウェブの大部分において、2MBのHTMLペイロードは巨大であり、この制限に引っかかることは決してないでしょう」と明記されています。
実際、2MBの「生のHTML」というのは、とてつもないデータ量です。テキストとコードだけで2MBに達することは稀です。試しに皆さんがよく知るメガサイトのHTMLサイズ(非圧縮時)を見てみましょう。
- Yahoo! JAPANトップページ: 約46KB
- Apple公式サイト: 約50KB前後
日本一情報が詰まっていそうなあのYahoo!ですら、2MB(約2000KB)には遠く及びません。ごく一般的なコーポレートサイトやブログ記事であれば、HTML単体で100KB未満に収まるのが普通です。
「画像が重いから2MB超えちゃうかも!」と勘違いしがちですが、画像は外部リソースとして別で読み込まれるため、HTMLの2MB制限にはカウントされません。
ですので、正直、ほとんどの人にはあまり関係のない情報なのかもしれませんが、予備知識として持っておきましょう。
4. 自分のサイトのHTMLサイズを確認する方法
そうは言っても、自社メディアやクライアントのサイトがどうなっているか、一度は確認しておきたいですよね。
まず知っておくべき落とし穴:URL検査ツールでは検出できない
Google Search Consoleの「URL検査」ツールを使って確認しようとするのは、実はNGです。URL検査ツールは「Google-InspectionTool」という別のクローラーを使用しており、こちらは15MBの制限下で動作します。そのため、実際に2MB制限でコンテンツが切り捨てられているページでも、URL検査ツール上では「正常にインデックス済み」と表示されてしまいます。
「Search Console上で問題なし → 実は2MBで切り捨てられている」という事態が、エラーなく静かに発生します。 SEO担当者が真っ先に手を伸ばすツールが、この問題の検出には使えないという点は非常に重要です。
ブラウザの開発者ツールで確認する(推奨)
ブラウザ(Google Chrome)の開発者ツール(DevTools)を使えば確認できます。
1.確認したいWebページを開く
2.画面上で右クリックし、「検証」を選択(または F12 キーを押す)
3.上部のタブから 「Network(ネットワーク)」 を開く

4.Networkタブ内のフィルタで 「Doc」 を選択する

5.キーボードの Ctrl + R(Macは Cmd + R)を押してページをキャッシュなしで再読み込みする
6.リストに表示されたHTMLファイル(通常は一番上)をクリックし、「Headers」タブ内のContent-Length または レスポンスの「Content」(デコード済み)サイズ を確認する

重要な注意点: Googlebotの2MB制限は圧縮前の非圧縮サイズに対して適用されます。Networkタブの「Size」列は転送時(Gzip等で圧縮済み)のサイズを表示していることが多く、そのままでは正確な判断ができません。デコード後のサイズを確認するか、専用ツール(後述)の利用を検討してください。
ここで表示されるデコード済みサイズが 2.0 MB を超えていなければ、問題ありません。
novarisのサービスLPの場合、30KBだったので、余裕で大丈夫でした。
5. まとめ:Web担当者が意識すべきベストプラクティス
今回のGoogleからの明言は、SEOの枝葉末節のテクニックというよりも、「クリーンで軽量なコードを書く」というWeb制作の基本を再確認する良いきっかけになりました。
Googleが公式に推奨しているバイトレベルのベストプラクティスは以下の通りです。
HTMLを無駄なく保つ 重いCSSやJavaScriptはHTML内に直書きせず、外部ファイルに移行しましょう。初期HTMLドキュメントの上限は2MBですが、外部スクリプトやスタイルシートは個別にフェッチされるため、HTML本体のサイズを削減できます。なお、外部ファイルにも個別に2MBの制限が適用される点は念頭に置いてください。
重要な要素は上部に配置する メタタグ、canonical、不可欠な構造化データなどは、HTMLドキュメントのより上部に配置しましょう。これにより、カットオフラインの下に配置されるのを防ぐことができます。
サーバーレスポンスを監視する サーバーがバイトの提供に手間取っている場合、Googlebotのフェッチャーは自動的に退いてクロール頻度を下げます。サーバーログを定期的にチェックし、レスポンスタイムの異常がないか確認しましょう。
URL検査ツールを過信しない 前述の通り、Search ConsoleのURL検査ツールは2MBの切り捨てを検出できません。重要なページについては、DevToolsや専用のHTMLサイズ計測ツールを使って非圧縮サイズを直接確認することを習慣づけましょう。
過度に恐れる必要はありませんが、サイトのリニューアル時や、新しいCMS・ツールを導入する際には、頭の片隅に「2MBの壁」と「コードの順序」を置いておくと安心です。不要なパニックは避け、ユーザーにとって表示が速く快適な、本質的なサイト運営にリソースを注いでいきましょう。
関連記事
-
【備忘録】VSCodeのLive ServerでShift-JISが文字化けする問題、ローカルサーバーでサクッと解決した話
2026.03.26(木曜日)
-
SEO分析の定番ツール「Screaming Frog SEO Spider」完全ガイド〜世界中のSEOプロが使い倒す理由と実践テクニック〜
2026.03.16(月曜日)
-
音声入力でAIプロンプトを爆速化!月額課金なし・2,000円マイクで実現する「声でプロンプト」活用術
2026.03.12(木曜日)
-
「参考書のコードがごちゃごちゃしてる…」その違和感は正しい!PHPの『echo連打』を卒業する4つのステップ
2026.02.26(木曜日)