[レベル: 上級]
Googlebot がクロールするファイルサイズの 2MB 上限の仕組みを解説した検索セントラルブログの記事を昨日の投稿で紹介しました。
この解説記事に先立って、ゲイリー (Gary Illyes) とマーティン (Martin Splitt) が Search Off the Record ポッドキャストで Googlebot および Google のクロールインフラが実際にどのように機能するかをわかりやすく説明していました。
2 人は、「Googlebot は一枚岩のプログラムやアプリケーションである」という一般的な誤解を否定するところから始めます。
実際のところ、Googlebotとは、ある特定のチーム（検索チーム）が Google の集中管理された社内 SaaS クロールインフラに API コールを行う際に使用している名称に過ぎません。
さらに 2 人は、クローラーとフェッチャーの違い、外部サイトへの過負荷を防ぐために Google が採用している組み込みのセーフガード、そしてファイルサイズやジオブロッキングに関する技術的な制約についても取り上げます。
Googlebot とは何なのか？ 何をするのか
ポッドキャストの主要ポイントをまとめます。
Googlebot の実態
- スタンドアロンプログラムではない：Googlebot は、.exe ファイルのような単一のソフトウェアではない。この名称は、Google が製品もクローラーも一つしか持っていなかった 2000 年代初頭からの時代遅れの呼び名である。
- 社内 SaaS：Google のクロールインフラは社内 SaaS として機能している。Google 内のさまざまなチームが「クライアント」として、この中央インフラに API リクエストを送信する。
- 設定可能な API コール：チームがページをクロールしたい場合、特定のパラメーター（例：ユーザーエージェント、待機時間、robots.txt のプロダクトトークン）を指定した API リクエストを送信する。「Googlebot」とは、検索チームがこの共有サービスへの呼び出しに使用している名称に過ぎず、それ自体が設定プロファイルというわけではない。
クローラーとフェッチャー
- クローラーはバッチ処理で動作し、バックグラウンドで継続的な URL のストリームを処理する（「時間があるときにやる」という方式）。
- フェッチャーは URL を一度に一つずつ処理し、ユーザーが能動的にレスポンスを待っている状態、すなわちユーザー主導であることを求める社内ポリシーに従っている。
セーフガード：「インターネットを壊さない」
- 自動スロットリング：中央クロールインフラは訪問先サイトの健全性を監視している。サイトの接続時間が増加し始めると、インフラはクロール速度を落とす。特に、
503（Service Unavailable）レスポンスに対してはさらに速度を落とす。Google はこれをサーバーが過負荷状態にあるサインとして扱っている。403や404エラーは通常のクライアントサイドエラーとして扱われるため、追加のスロットリングは発生しない。 - 積極的なキャッシング：冗長なフェッチを減らすために、Google は積極的な社内キャッシングを使用している。あるプロダクトが最近ページを取得した場合、別のプロダクトがそのコピーを再利用することがあるが、他のプロダクト向けに取得したコンテンツの再利用を明示的に禁じるポリシーを持つプロダクトも存在する（例：Ads はウェブ検索向けに取得したコンテンツを再利用できない）。
- 厳格なアクセス制御：Google の個々のエンジニアは、これらのセーフガードを迂回してウェブサイトから大量のデータを手動でストリーミングすることはできない。すべてのフェッチは、規制された中央 API を通じて行う必要がある。
技術的な制限とジオブロッキング
- ファイルサイズの制限：クロールインフラのデフォルトの切り捨て上限は 15MB である。チームはこれを上書きすることができる。ウェブ検索では HTML を 2MB に制限している一方、PDF にはより大きなサイズが許可されている場合がある。設定はコンテンツの種類によって同一プロダクト内でも異なる場合がある。
- ジオブロッキングは非推奨：Google のクロールは主に米国の IP アドレス（具体的にはカリフォルニア州マウンテンビュー）から行われる。高い価値を持つコンテンツに対しては他の地域から IP をリースすることも稀にあるが、これをグローバルに大規模に展開するための大容量インフラは備えていない（ゲイリーはこれを頼りにすることを「非常に、非常に、非常に悪い考えだ」と表現）。
ドキュメント
- Google が公式にドキュメントを公開しているのは、主要かつ高頻度のクローラーとフェッチャーのみである。ドキュメント化のトリガーは、クローラーまたはフェッチャーが 1 日あたり一定数のフェッチ数を超えたときに作動する社内アラートである。Google 社内のプロジェクト数の多さを考えると、細かなものや社内向けのクローラーをすべてドキュメント化することは現実的ではない。
◇◇◇
Googlebot が単一のプログラムではなく、 Google 社内の巨大な API ベースの SaaS 型インフラとして機能しているという裏話は、 SEO 担当者として非常に解像度が上がるエピソードでした。
テクニカル SEO の実務において、特に重要だと再認識させられたのは次の 3 点です。
- 2MB の HTML サイズ制限：検索用の Googlebot は HTML ファイルを 2MB で切り捨てる。一般的なサイトがこの上限に達することはまずないため過度な心配は不要だが、たとえば、巨大な画像を Base64 エンコードして HTML 内に直接大量に埋め込むような特殊な実装をしてしまうと、 2MB を超過して重要なコンテンツやリンクが認識されないリスクがあるという知識として持っておくべき。
- ジオブロック（地域制限）の危険性：クロールは基本的に米国（カリフォルニア）の IP アドレスから実行される。セキュリティ目的などで安易に米国の IP をブロックしてしまうと、サイトがクロールされなくなる致命的な問題に直結する。
- サーバーパフォーマンスとクロール頻度：サーバーの応答が遅かったり、 503 エラーを返したりすると、サイトを守るために Google のインフラ側で自動的にクロールが制限（スロットル）される。安定したサーバー環境がクロールバジェットの確保にも重要となる。
2MB 制限など通常の運用では気にする必要のない裏側の仕様も知れつつ、サーバーの健全性や正しいアクセス制御といったテクニカル SEO の基礎が、 Google のインフラ側の視点からなぜ重要なのかを論理的に理解できる学びの多いポッドキャストでした。