DocsDigest
Back to listLanguage: JA
OpenAIGoogle 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.

openaienmodel: gpt-5-mini-2025-08-07

Inside Googlebot: crawling, 2MB limits, and rendering implications

googlebotcrawlingweb-renderingbyte-limitsseoindexing

Key Points

  • Googlebot is a centralized crawler platform
  • HTML fetch capped at 2MB (PDFs 64MB)
  • WRS only renders bytes actually fetched

Summary

This post explains how Googlebot is actually a set of clients using a centralized crawling platform, highlights per-URL byte limits (notably a 2MB HTML fetch limit), and describes how the Web Rendering Service (WRS) processes only the bytes that the crawler retrieved. Bytes beyond the configured cutoff are ignored and never indexed or rendered.

Key Points

  • Googlebot is an umbrella user of a centralized crawler platform; many Google products route fetches through it.
  • Default per-URL fetch limits: HTML and most resources — 2MB (includes HTTP headers); PDFs — 64MB; unspecified crawlers — 15MB.
  • If a resource exceeds the per-URL limit, the fetch stops at the cutoff and the remainder is ignored (not rendered or indexed).
  • WRS renders client-side JS/CSS only from the bytes the fetcher retrieved; it operates statelessly (clears local/session storage between requests).
  • External resources (scripts, styles) are fetched separately and have their own per-URL counters; images/videos are typically not rendered by WRS.

Practical guidance for engineers

  • Keep initial HTML lean: move large CSS/JS and base64 blobs to external files to avoid hitting the 2MB cutoff.
  • Place critical metadata and structured data early in the document (title, meta, canonicals, essential JSON-LD).
  • Monitor server response times and logs; slow servers cause fetchers to back off and reduce crawl frequency.
  • Test pages with realistic fetch-size constraints and ensure client-side rendering doesn’t rely on bytes that may be truncated.

Takeaway

Treat crawling as a byte-limited exchange: prioritize and surface your most important content early and externally reference heavy assets so Google’s fetcher and renderer can reliably see and index your site.

Full Translation

Translations

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

openaijamodel: gpt-5-mini-2025-08-07

Googlebotの内部：クロール、フェッチ、そして処理するバイトの仕組みを解明

もし Search Off the Record の Episode 105 を視聴したなら、私たちが愛してやまない（そしてサーバーを悩ませる）トピック、つまり Googlebot の内部動作について深掘りしたのを聞いたかもしれません。長い間「Googlebot」という名前は、インターネットを体系的に読み取る単一の疲れを知らないロボットを想起させてきました。しかし現実はもう少し複雑で、ずっと興味深いものです。

本記事では、クロール基盤の中身を覗き、特に私たち自身を混乱させる「バイトサイズの上限（bytesize limits）」に焦点を当てて説明します。

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

歴史的な誤解をまず解消しましょう。2000年代初頭、Google は一つの製品だけを提供していたため、クローラも一つでした。その名称「Googlebot」は残りましたが、今日では Googlebot は中央集約型クロールプラットフォームの一利用者に過ぎません。

サーバーログに Googlebot と表示されるとき、実際には Google Search がアクセスしています。Google Shopping、AdSense などの数十のクライアントも、それぞれ異なるクローラ名で同じ基盤インフラを経由してクロール要求をルーティングします。大きなものは Google Crawler infrastructure site に記載されています。

2MB の制限：サーバーから送られるバイトに何が起きるか

ここでやや混乱が生じます。クロール基盤の各クライアントは、フェッチに関する設定を指定する必要があります。これにはユーザーエージェント文字列、robots.txt でどのユーザーエージェントトークンを参照するか、そして単一 URL からフェッチするバイト数の上限が含まれます。

  • Googlebot は現在、個々の URL につき最大 2MB（PDF を除く）までをフェッチします。これはリソースの最初の 2MB（HTTP ヘッダーを含む）のみをクロールすることを意味します。PDF ファイルの場合は 64MB です。
  • 画像や動画を対象とするクローラは、プロダクトによって閾値が大きく異なります。例えば favicon を取得するクローラは非常に低い上限を持つかもしれませんが、Image Search のクローラは別です。
  • 上限を指定しないその他のクローラに対しては、コンテンツタイプに関係なくデフォルトで 15MB が適用されます。

サーバーから送られるバイトにおける具体的挙動

  • 部分的な取得: HTML ファイルが 2MB を超える場合、Googlebot はページを拒否しません。代わりにフェッチをちょうど 2MB の切り捨て点で停止します。なお、この上限には HTTP リクエストヘッダーも含まれます。

  • カットオフの処理: ダウンロードされたその部分（最初の 2MB 相当のバイト）は、完全なファイルであったかのようにインデックス作成システムと Web Rendering Service（WRS）に渡されます。

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

  • リソースの取得: HTML 内で参照されるあらゆるリソース（メディア、フォント、いくつかの特殊なファイルを除く）は、親 HTML と同様に WRS によって Googlebot として取得されます。各リソースは独自の URL ごとのバイトカウンタを持ち、親ページのサイズには合算されません。

大多数のウェブでは 2MB の HTML ペイロードは非常に大きく、通常この上限に達することはありません。しかし、ページに巨大な inline base64 画像、膨大な量のインライン CSS/JavaScript、あるいはメガバイト単位のメニューが先頭にあると、実際のテキストコンテンツや重要な構造化データが 2MB を超えてしまう可能性があります。重要なバイトが取得されないと、Googlebot にとってそれらは存在しないのと同じです。

バイトのレンダリング

フェッチャが上限まで（あるいはそれ以下まで）バイトを正常に取得すると、そのバトンは WRS に渡されます。WRS は JavaScript を処理し、現代のブラウザに似た方法でクライアントサイドのコードを実行して、ページの最終的な視覚・テキスト状態を把握します。

レンダリングでは JavaScript や CSS のファイルが取り込まれ実行され、XHR リクエストが処理されてページのテキストコンテンツや構造をより良く理解します（画像や動画はリクエストしません）。各リソースに対しても 2MB の上限が適用されます。

ただし、WRS はフェッチャが実際に取得したコードしか実行できません。さらに WRS はステートレスに動作し、リクエスト間でローカルストレージやセッションデータをクリアします。これにより、動的で JavaScript に依存する要素の解釈に特別な影響が出る場合があります。

バイトに関するベストプラクティス

Googlebot が効率的にあなたのコンテンツを取得し理解できるよう、以下のバイトレベルのベストプラクティスを心に留めてください：

  • HTML を軽く保つ: 重い CSS や JavaScript は外部ファイルに分離しましょう。初期 HTML ドキュメントは 2MB に制限されていますが、外部スクリプトやスタイルシートは別個にフェッチされ（それぞれの上限の対象です）、親ページのサイズには合算されません。
  • 順序は重要: meta タグ、<title>、<link>、canonicals、重要な構造化データなど、最も重要な要素は HTML の上部に置いてください。これによりカットオフより下に埋もれる可能性を減らせます。
  • サーバーログを監視する: サーバーの応答時間を注視してください。サーバーがバイト配信に苦戦している場合、フェッチャはインフラへの過負荷を避けるため自動的にバックオフし、クロール頻度が低下します。

この上限は固定されたものではなく、ウェブの進化や HTML ページの肥大化（あるいは縮小）に伴って将来変更される可能性があります。

クロールは魔法ではなく、バイトの大規模かつ綿密に調整された交換です。私たちの中央フェッチ基盤がどのようにこれらのバイトを取得し制限しているかを理解することで、サイトの最も重要なコンテンツが常に取り込まれるようにできます。

Happy optimizing!

詳しい舞台裏をもっと聞きたいですか？Search Off the Record の Episode 105 を YouTube やお使いのポッドキャスト配信サービスでチェックしてください。

投稿者: Gary