DocsDigest
Back to listLanguage: JA
ClaudeGoogle Search Central BlogMar 31, 2026, 12:00 AM

Inside Googlebot: demystifying crawling, fetching, and the bytes we process

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

claudeenmodel: claude-sonnet-4-20250514

Google Reveals Googlebot's 2MB Crawling Limits and Infrastructure Details

googlebotcrawlingseoweb-renderingbyte-limitshtml-optimizationindexing

Key Points

  • Googlebot enforces a 2MB limit per HTML page, ignoring content beyond this threshold
  • Multiple Google services share the same crawling infrastructure under different names
  • Critical page elements should be placed early in HTML to avoid byte limit cutoffs

Summary

Google has provided detailed insights into Googlebot's crawling infrastructure, revealing that "Googlebot" is actually a centralized crawling platform serving multiple Google products, not a single crawler. The most significant technical detail is the 2MB limit for HTML content fetching.

Key Points

  • Googlebot is a platform: Multiple Google services (Search, Shopping, AdSense) use the same underlying crawling infrastructure with different user agent names
  • 2MB HTML limit: Googlebot fetches only the first 2MB of HTML content per URL, including HTTP headers. Content beyond this limit is completely ignored
  • PDF exception: PDF files have a higher 64MB limit, while other crawlers default to 15MB when no limit is specified
  • Partial processing: Pages larger than 2MB aren't rejected - the first 2MB is processed as if it were the complete file
  • Resource fetching: Referenced resources (CSS, JS) are fetched separately with their own 2MB limits and don't count toward the parent page size
  • Rendering limitations: Web Rendering Service (WRS) can only execute code that was actually fetched within the byte limits
  • Optimization recommendations: Keep HTML lean, place critical elements early in the document, and move heavy assets to external files

Full Translation

Translations

A translation section that keeps the flow of the original article.

claudejamodel: claude-sonnet-4-20250514

Googlebotの内部：クローリング、フェッチ、処理するバイト数の謎を解く

2026年3月31日（火曜日）

Search Off the Recordポッドキャストのエピソード105を聞いた方は、私たちが心から（そしてサーバーから）愛するトピックについて深く掘り下げているのを聞いたかもしれません：Googlebotの内部動作です。長い間、「Googlebot」という名前は、インターネットを体系的に読み取る単一の疲れ知らずのロボットのイメージを呼び起こしてきました。しかし、現実はもう少し複雑で、そしてはるかに興味深いものです。

今日は、私たち自身の頭を悩ませるもの、つまりバイトサイズ制限に特に焦点を当てて、クローリングインフラストラクチャのフードを開けてみたいと思います。

まず、Googlebotは単一のプログラムではありません

最初に歴史的な誤称を明確にしましょう。2000年代初頭、Googleには1つの製品があったため、1つのクローラーがありました。「Googlebot」という名前が定着しました。しかし今日、Googlebotは中央集権化されたクローリングプラットフォームに似たものの単なるユーザーです。

サーバーログでGooglebotを見るとき、あなたはGoogle検索を見ているだけです。Google Shopping、AdSenseなど、他の数十のクライアントはすべて、異なるクローラー名で同じ基盤インフラストラクチャを通じてクロール要求をルーティングしており、大きなものはGoogle Crawlerインフラストラクチャサイトで文書化されています。

2MB制限：あなたのバイトに何が起こるか？

ここで物事は少し混乱します。クローラーインフラストラクチャのすべてのクライアントは、フェッチのためにいくつかの設定を設定する必要があります。これらの設定には、ユーザーエージェント文字列、robots.txtで探すユーザーエージェントトークン、単一のURLから取得するバイト数が含まれます。

Googlebotは現在、個々のURL（PDFを除く）に対して最大2MBを取得します。これは、HTTPヘッダーを含むリソースの最初の2MBのみをクロールすることを意味します。PDFファイルの場合、制限は64MBです。

画像および動画クローラーは通常、幅広いしきい値を持っており、それは主に取得する製品に依存します。例えば、faviconの取得は画像検索とは異なり、非常に低い制限を持つ可能性があります。制限を指定しない他のクローラーの場合、コンテンツタイプに関係なくデフォルトは15MBです。

これは、サーバーが送信するバイトにとって何を意味するのでしょうか？

部分的な取得

HTMLファイルが2MBより大きい場合、Googlebotはページを拒否しません。代わりに、2MBのカットオフで正確にフェッチを停止します。制限にはHTTPリクエストヘッダーが含まれることに注意してください。

カットオフの処理

ダウンロードされた部分（最初の2MBのバイト）は、完全なファイルであるかのようにインデックスシステムとWeb Rendering Service（WRS）に渡されます。

見えないバイト

2MBのしきい値を超えて存在するバイトは完全に無視されます。それらは取得されず、レンダリングされず、インデックス化されません。

リソースの取り込み

HTML内で参照されるすべてのリソース（メディア、フォント、いくつかの特殊ファイルを除く）は、親HTMLのようにGooglebotによってWRSによって取得されます。それらは独自の個別のURL単位のバイトカウンターを持ち、親ページのサイズにはカウントされません。

Webの大部分にとって、2MBのHTMLペイロードは巨大であり、この制限に達することはありません。ただし、ページに肥大化したインラインbase64画像、大量のインラインCSS/JavaScript、またはメガバイトのメニューが含まれている場合、実際のテキストコンテンツや重要な構造化データを2MBマークを超えて誤って押し出す可能性があります。これらの重要なバイトが取得されない場合、Googlebotにとってそれらは単に存在しません。

バイトのレンダリング

クローラーがバイト（制限まで）を正常に取得すると、WRSにバトンを渡します。WRSはJavaScriptを処理し、ページの最終的な視覚的およびテキスト状態を理解するために、現代のブラウザーと同様にクライアントサイドコードを実行します。

レンダリングはJavaScriptおよびCSSファイルを取り込んで実行し、ページのテキストコンテンツと構造をよりよく理解するためにXHRリクエストを処理します（画像や動画はリクエストしません）。

要求された各リソースに対して、2MB制限も適用されます。ただし、WRSはフェッチャーが実際に取得したコードのみを実行できることを覚えておいてください。

さらに、WRSはステートレスで動作し、リクエスト間でローカルストレージとセッションデータをクリアします。これは、動的でJavaScriptに依存する要素がシステムによってどのように解釈されるかに特別な影響を与える可能性があります。

バイトのベストプラクティス

Googlebotがコンテンツを効率的に取得して理解できるようにするために、これらのバイトレベルのベストプラクティスを念頭に置いてください：

HTMLを軽量に保つ

重いCSSとJavaScriptを外部ファイルに移動します。初期HTMLドキュメントは2MBに制限されていますが、外部スクリプトとスタイルシートは個別に取得されます（独自の制限の対象）。

順序が重要

メタタグ、<title>要素、<link>要素、canonical、必須の構造化データなど、最も重要な要素をHTMLドキュメントの上位に配置します。これにより、カットオフ以下で見つかる可能性が低くなります。

サーバーログを監視

サーバーの応答時間に注意してください。サーバーがバイトの提供に苦労している場合、フェッチャーはインフラストラクチャの過負荷を避けるために自動的にバックオフし、クロール頻度が低下します。

この制限は石に刻まれたものではなく、Webが進化しHTMLページのサイズが大きくなる（または縮小する。うまくいけば縮小する）につれて、時間とともに変更される可能性があることに注意してください。

クローリングは魔法ではありません。それは高度に組織化された、スケールされたバイトの交換です。中央フェッチインフラストラクチャがこれらのバイトをどのように取得し制限するかを理解することで、サイトの最も重要なコンテンツが常に基準を満たすことを確実にできます。

最適化を楽しんでください！

舞台裏の詳細をもっと聞きたいですか？YouTubeまたはポッドキャストを入手する場所でSearch Off the Recordポッドキャストのエピソード105をチェックしてください！

Garyによる投稿