Google Search Relations TeamのMartin Splitt氏とGary Illyes氏が、5/29のSearch Off the RecordポッドキャストでGooglebotとウェブクローリングの仕組みについて詳細に解説しました。この回では、Googleの初期から現在に至るまでのクローラー技術の進化、統合インフラストラクチャの導入背景、そして将来の展望まで、SEO担当者が知るべき重要な情報が数多く語られています。
Googlebotの歴史と技術的進化
初期のクローリング技術から現代まで
Gary Illyes氏によると、クローラーは本質的に「非常にシンプルなHTTPクライアント」であり、ブラウザと同様にネットワーク上のデータを取得するツールです。1990年代のインターネット黎明期には、CNNやWall Street Journalのような人気サイトのホームページから始めて、リンクを辿るだけで「インターネット全体をクロールできた」と説明されています。
当時のウェブページは現在と比較して極めて軽量で、7,000バイト程度のHTMLファイルが一般的でした。現在では単一の画像ファイルよりも小さなサイズです。しかし、帯域幅のコストが現在よりもはるかに高額だったため、クローリングには異なる課題がありました。
Googlebotの命名と発展
Googlebotという名称は1999年頃に付けられ、それ以前は特別な名前がありませんでした。ただし、Googleの創設当初からrobots.txtプロトコルはサポートされており、サイト所有者がクローリングを制御できる仕組みが整備されていました。
Google内部のクローラー統合戦略
複数プロダクトによるクローリング課題
2000年代初頭にAdWords（2000年代前半）やAdSense（2003年頃）、Gmail（2005-2006年）などの新しいプロダクトが登場すると、それぞれが独自のデータ取得ニーズを持つようになりました。
特にGmailでは、ユーザーのメタデータを外部サイトに漏らさないよう、メール内の画像を代理で取得する必要がありました。当初はすべてのプロダクトがGooglebotを共用していましたが、これではサイト所有者が「どのプロダクトのためのクローリングなのか」を判別できない問題がありました。
統合インフラストラクチャの導入
この課題を解決するため、Googleは2006年頃にGoogle AdSenseBot（現在のGoogle-AdSense）を導入し、統合クローリングシステムを構築しました。このシステムでは、各プロダクトが独自のユーザーエージェント文字列を指定できる一方で、robots.txtの遵守やホスト負荷の監視などの基本的な動作は統一されています。
ユーザー主導型フェッチとクローラーの違い
異なるアプローチが必要な理由
Gary Illyes氏は、ユーザーが直接操作するアクション（例：スプレッドシートへのデータ読み込み）では、robots.txtを無視することが適切な場合があると説明しています。これは「ユーザーの代理で行う取得」であり、自動化されたクローリングとは本質的に異なるためです。
レイテンシーの重要性
通常のクローラーは大量のURLデータベースから順次処理を行うため、ユーザーが追加したURLの処理に数週間かかることがあります。一方、ユーザー主導型のフェッチでは、サイトからの信号を無視してでも即座に処理を実行する必要があります。
Search Consoleの「ライブテスト」機能がこの例として挙げられており、ユーザーがリアルタイムで結果を確認できるよう設計されています。
現在のGooglebotの技術仕様
ファイルサイズ制限とクローリング頻度
Googleの公式ドキュメントによると、Googlebotは以下の制限があります。
①HTMLファイルの15MB制限
Googlebotは、HTMLファイルまたはサポートされているテキストベースのファイルの最初の15MBまでをクローリングします。この制限を超えると、Googlebotはクロールを停止し、最初の15MBのみをインデックス登録の対象とします。
②サブリソースの15MB制限
この15MB制限は、Googlebotが行う初回リクエストで受信するバイト（コンテンツ）にのみ適用され、ページ内で参照されるリソースには適用されません。例えば、HTMLファイルを開く際、ブラウザは最初にHTMLファイルのバイトをダウンロードし、そのバイトに基づいて外部JavaScript、画像、その他URLで参照されるものに対して追加のリクエストを行います。
③非圧縮データへの適用
この制限は非圧縮データに適用されます。
④クローリング頻度について
クローリング頻度はクロール予算によって決定され、これは「Googlebotがクロールできる、かつクロールしたいURL数」として定義されます。クロール予算は以下の2つの主要要素で決まります。
- クロール容量制限：Googlebotがサイトを圧迫することなくクロールするために計算される、同時並列接続の最大数とフェッチ間の時間遅延
- クロール需要：サイトのサイズ、更新頻度、ページ品質、関連性に基づいてGoogleが必要と判断するクロール時間
⑤サーバー応答時間の重要性
Google PageSpeed Insightsでは、サーバー応答時間を200ミリ秒未満に削減することを推奨しています。サイトが迅速に応答する場合、制限が上がり、より多くの接続を使用してクロールできるようになります。サイトが遅くなったりサーバーエラーで応答したりする場合、制限が下がり、Googlebotのクロールが少なくなります。
この15MB制限は新しい変更ではなく、何年も前から存在していた制限が2022年6月に公式ドキュメントに追加されただけです。HTMLファイルの中央値サイズは約30KBであるため、ほとんどのウェブサイトには影響しません。
モバイルファーストインデックスの実装
モバイルファーストインデックスの実装は段階的に行われ、2020年9月の当初計画から数度の延期を経て、2023年11月に実質的に完了しました。2024年7月5日以降は、スマートフォン用Googlebotのみでウェブサイトをクロールし、インデックスに登録していますが、技術的問題を抱える極少数のサイトについては例外的にデスクトップGooglebotでのクロールが継続されています。
クロールバジェット管理の重要性
クロールバジェットの基本概念
Googleの公式ガイドによると、クロールバジェットは「クロール容量制限」と「クロール需要」の2つの要素によって決定されます。
クロール容量制限は、Googlebotがサイトを圧迫しないよう計算される同時並行接続数の上限と、フェッチ間の時間遅延です。この制限は以下の要因で変動します。
- クロールヘルス：サイトの応答が速い場合は制限が上がり、遅い場合やサーバーエラーが発生する場合は制限が下がります
- Googleのクローリング制限：Googleのマシンリソースには限りがあるため、全体的な制約があります
クロール需要は、サイトのサイズ、更新頻度、ページ品質、関連性に基づいて決定されます。
クロール効率化の実践的手法
Googleの公式ガイドでは、以下の最適化手法が推奨されています。
- サーバー応答時間の短縮により、より多くのページがクロールされる可能性があります
- ただし、低品質なページを高速化してもクロール量は増加しません
- robots.txtを使用して重要でない大きなリソースのクロールを防止
- 長いリダイレクトチェーンの回避
- 画像やスクリプトなどの埋め込みリソースの読み込み時間と実行時間の最適化
Web Rendering Serviceとリソースクロール
レンダリングプロセスの仕組み
Googleの公式ブログによると、現代のウェブサイトのクロールプロセスは以下のように動作します。
- GooglebotがHTMLをダウンロード
- Web Rendering Service（WRS）にデータを渡す
- WRSがGooglebotを使用して参照されるリソースをダウンロード
- WRSがすべてのリソースを使用してページを構築
リソースキャッシュによるクロールバジェット保護
WRSは参照されるすべてのリソース（JavaScriptとCSS）をキャッシュし、最大30日間保持します。このキャッシュはHTTPキャッシュディレクティブの影響を受けず、サイトのクロールバジェットを他のクロールタスクのために保護する役割を果たします。
地域対応クローリングの進化
多言語・多地域サイトへの対応
Googleは2015年から地域対応ページのクロール設定を導入しています。
地理分散クローリングでは、Googlebotが米国外からのIPアドレスも使用してクロールを実行します。言語依存クローリングでは、Accept-Language HTTPヘッダーを含むリクエストでクロールを行います。
これらの設定は、地域適応型ページとして検出されたページに対して自動的に有効化されます。
AI時代のクローラー戦略
Google-Extendedクローラーの導入
2025年4月、GoogleはAIモデル訓練専用のGoogle-Extendedクローラーの説明を大幅に更新しました。このクローラーは以下の特徴があります。
- Gemini、Vertex AIの訓練データ収集専用
- 検索結果のインデックス化とは完全に分離
- SEOランキングに一切影響しない
- robots.txtで個別に制御可能
データ収集目的クローラーの増加
実際のサイト運営者の調査によると、GoogleOtherやGPTbotなどのデータ収集目的のクローラーが増加しており、これらをブロックすることで本来のGooglebotのクロール数が増加することが確認されています。
クローラーブロック方法例
User-agent: GPTBot Disallow: /
User-agent: GoogleOther
Disallow: /日本市場におけるクローリング最適化の実践的アドバイス
モバイルファーストの徹底
日本では通勤時間中のモバイル検索が特に多く、モバイルファーストの最適化が不可欠です。Googlebotの大部分がモバイルクローラーによる要求となっているため、モバイル体験の最適化は検索パフォーマンスに直結します。
クロールバジェット最適化の具体策
- Googlebotのアクセス頻度を適切に管理
- robots.txtを活用した不要なクローリングの制限
- サイトの応答速度向上によるクローリング効率の改善
- schema.orgマークアップによる検索エンジンの理解促進
- 日本語コンテンツに適した構造化データの設計
- 日本語サイトの階層構造を明確にする内部リンク設計
- ユーザーエクスペリエンスとクローリング効率の両立
技術的な最適化ポイント
サーバー応答速度の改善も重要です。
- サーバー応答時間の短縮
- 重要でないリソースの読み込み最適化
- リダイレクトチェーンの最小化
JavaScript SEOの強化
Googleは2025年2月にJavaScript SEOドキュメントを見直し、動的レンダリングを非推奨の回避策として明確化しました。最新のChrome版を使用したレンダリングプロセスに対応することが重要です。
SEO担当者が押さえるべきクローリング最適化の要点
今回のポッドキャストとGoogleの公式ドキュメントから得られる実践的な知見として、以下の点が重要です。
統合的なクローリング戦略の理解
- Googleの各プロダクト（検索、広告、AI訓練）が異なるクローラーを使用
- それぞれのクローラーが同一の基本ポリシーに従って動作
- サイト所有者は用途に応じてクローリングを制御可能
技術的な最適化の継続
- モバイルファーストインデックスへの完全対応
- ページ読み込み速度の継続的な改善
- 適切なrobots.txt設定による効率的なクローリング誘導
将来への準備
- AI時代に向けたコンテンツ戦略の見直し
- Google-Extendedクローラーへの適切な対応
- Web Rendering Serviceのキャッシュ機能を活用したリソース最適化
Googleのクローリング技術は単純なHTTPクライアントから始まり、現在では高度に統合されたシステムへと進化しています。SEO担当者は、この技術的進化を理解し、自社サイトの最適化に活用することで、検索エンジンからの適切な評価を獲得できるでしょう。
出典
- Crawling December Resources, Google Search Central Blog, 2024年12月3日
- Mobile Indexing Vlast Final Final, Google for Developers, 2024年6月
- Googlebot and the 15 MB thing, Google Search Central Blog, 2022年6月28日
- What Crawl Budget Means for Googlebot, Google Search Central Blog, 2017年1月16日
- Improve Server Response Time, PageSpeed Insights – Google for Developers, 2024年9月3日
- Crawl Budget Management For Large Sites, Google for Developers, 2025年2月5日
- Mobile Analysis in PageSpeed Insights, Google for Developers, 2024年9月3日
