• #SEO
  • #Google
  • #Googlebot
  • #技術メモ
開発未分類メモ

何が起きたのか

2026年3月31日、GoogleのGary Illyesが公式ブログで「Inside Googlebot: demystifying crawling, fetching, and the bytes we process」を公開した。Googlebotのクロールアーキテクチャとバイトサイズ制限について、技術的な詳細が初めて体系的に語られた記事だ。

核心はシンプル: GooglebotはHTMLを最初の2MBまでしか取得しない。2MBを超えた部分は、クロールもレンダリングもインデックスもされない。

確認された仕様

ファイルタイプ別の取得上限

ファイルタイプ上限
HTML2MB
CSS / JavaScript(各リソース個別)2MB
PDF64MB
Googleクロールインフラ全体のデフォルト15MB

重要な仕様詳細

  • 非圧縮データに対して2MBが適用される(gzip転送後のサイズではない)
  • HTTPレスポンスヘッダーも2MBのカウントに含まれる
  • CSS・JavaScriptは親HTMLとは別カウント。各外部リソースに個別で2MB制限が適用される
  • 上限に達した時点でフェッチを停止し、ダウンロード済みの部分だけがインデックス対象になる
  • コンテンツは文字の途中であっても容赦なく切断される

フェッチ段階で切れる

2MB制限が適用されるのはフェッチ段階(raw HTML) だ。Web Rendering Service(WRS)は、フェッチ段階で切り詰められたデータを「完全なファイル」として受け取る。つまりレンダリング以降の工程では、切断されたことすら認識されない。

これは新しい制限ではない

ここが誤解されやすい。Googlebotは以前から2MBしか見ていなかった。 ドキュメント上は「15MB」と記載されていたが、2026年2月に修正された。Googleはこれを「動作変更」ではなく「ドキュメントの明確化」と説明している。

タイムライン

時期出来事
2022年6月Googleが15MB制限を公式文書化。「この制限は新しいものではなく、何年も前から存在していた」と説明
2026年2月3日ファイルサイズ制限ドキュメントが改訂。15MBから2MBへの変更が文書化される
2026年2月6日John MuellerがBlueskyで2MBチェックツールを推奨
2026年3月31日Gary Illyesのブログ記事で技術的詳細が公開

発端は、Mark van Ments氏がGoogle Search Central Help Communityで自サイトのコンテンツが途中で切れる問題を報告したことだった。Google担当者が「ドキュメントが間違っていた。Googlebotはraw HTMLの最初の2MBしか見ていない」と回答し、ドキュメント修正につながった。

Search Consoleでは検出できない

Spotibo社が実テストで確認した、SEO担当者にとって最も厄介な事実がある。

  • Search Consoleは警告を出さない。 2MBを超えたページでも「インデックス登録済み」と正常表示される
  • URL Inspectionツールは別のクローラー(Google-InspectionTool)を使う。このクローラーの上限は15MBなので、実際のGooglebotとは異なる結果を返す
  • つまり、URL Inspectionで問題なしと表示されても、本番のGooglebotでは切断されている可能性がある

実際どのくらいのサイトが影響を受けるか

Web Almanac 2025のデータによると:

指標サイズ
HTML中央値(モバイル)約33KB
90パーセンタイル約392KB
2MB超えの割合全ページの0.82%

99%以上のサイトは問題ない。ただし以下のパターンは危険:

  • Base64画像のインライン埋め込み: data URIで画像をHTMLに直接記述
  • 巨大なインラインCSS/JavaScript: 外部ファイル化されていないスタイルやスクリプト
  • 大量のナビゲーション: メガメニューやサイドバーがHTML上部を占有
  • 大規模な商品リスト: ECサイトのカテゴリページで数百商品を1ページに展開

SEOで気をつけること

重要なものを上に置く

Googlebotが確実に読む範囲に、重要なコンテンツを配置する。

  • <title>, <meta>, <link rel="canonical">
  • 構造化データ(JSON-LD)
  • 本文コンテンツ

構造化データをフッターに置いているサイトは、2MBに引っかからなくてもHTMLの下部にあるだけでリスクがある。<head>内に移すのが安全だ。

HTMLを軽くする

  • インラインCSS/JSを外部ファイルに分離する
  • Base64画像を通常の<img>タグに置き換える
  • 不要なDOM要素を削減する

JS依存を減らす

  • SSR(サーバーサイドレンダリング)またはSSG(静的サイト生成)を使う
  • 初期HTMLにコンテンツを含める
  • SPAで後から読み込むコンテンツは、Googlebotにとって存在しない

Gary Illyesの記事でも、「フェッチされた範囲のJavaScriptしか実行されない」と明記されている。

このサイトは大丈夫か

このブログ(mdx-playground)の全782記事を調査した結果:

指標結果
最大のMarkdownソース約55KB(skill-authoring-best-practices.md
50KB超のファイル数3件
100KB超のファイル数0件
全記事の合計約881KB

最大の記事でも55KB。HTMLテンプレート(ナビゲーション、head、スクリプト参照等)を加えても200KB前後で、2MBの10分の1にも満たない。全記事が2MB制限の圏内に収まっている。

SSGで静的HTMLを生成しているため、JS依存の問題もない。

出典

Google公式

SEO専門メディア

独立テスト・検証