CloudflareのAIクローラールールがGooglebotをブロックする危険性
CloudflareがAIクローラー対策の仕組みを抜本的に見直し、2026年9月15日から新たなデフォルト設定を適用する。この変更は単なるAIボット対策の強化にとどまらず、Googlebotのような検索クローラーまで巻き込む可能性がある。AIにコンテンツを学習されたくないという意図で設定したブロックが、結果的に検索エンジンからの流入を断つリスクをはらんでいるのだ。
特に影響が大きいのは、Cloudflareの無料プランを利用するWordPressサイトや中小企業のオウンドメディアだ。AI学習ブロックの意図がなくても、9月15日以降にデフォルト設定が自動適用され、知らぬ間にGooglebotのクロールが制限される可能性がある。本記事では3つの振る舞い分類、デフォルト変更の詳細、そして今すぐ取るべき対応策を解説する。
CloudflareがAIクローラー対策の方針を転換した背景
Cloudflareは2026年7月2日、第2回「Content Independence Day」の一環として、AIクローラー管理の新方式を発表した。従来の単一の「AIボットをブロック」スイッチを廃止し、クローラーの振る舞いに基づいた3つのカテゴリで制御する仕組みへ移行する。この変更は全顧客（無料プランを含む）に即時適用され、9月15日にはデフォルト設定も自動変更される。
背景にあるのは、AIクローラーによるコンテンツ収集の爆発的な増加だ。Cloudflareのネットワーク上では、AI訓練目的のクローラーリクエストが全体の過半数を占めるまでに成長した。2025年春時点では約20%だったが、1年で状況は一変した。AIエージェントのリクエスト数も前年比1700%増と、指数関数的な伸びを示している。
この急増に対し、多くのパブリッシャーやサイト運営者はAIクローラーを一律ブロックする方向に動いてきた。しかし、その「一律ブロック」が検索クローラーまで巻き込む副作用を生みつつあった。Cloudflareの今回の方針転換は、この問題に正面から取り組むものだが、同時に新たなリスクも生じさせている。
3つの振る舞い分類がクローラー制御を変える
Cloudflareの新方式は、クローラーを「AIかどうか」ではなく「サイト上で何をするか」で分類する。この考え方は、サイト運営者にとってクローラー制御の解像度を格段に上げるものだ。3つのカテゴリは以下のとおり。
Cloudflareは、ボット運営者に対して「振る舞いごとに別々のクローラーを用意すべき」と要求している。サイト側が「なぜそのボットが来ているのか」を判断し、許可・ブロックを適切に選択できるようにするためだ。この考え方自体は合理的だが、現実にはGooglebotのように検索とAI訓練の両方を行う「マルチパーパスクローラー」が存在する。この点が後述する問題の核心となる。
検索クロールとAI訓練クロールの同居がリスクを生む
Googlebot、Applebot、Bingbotは、いずれも検索インデックス作成とAIモデル訓練の両方に使用される。Cloudflareの新ルールでは、こうした「混合用途のクローラー」に対して最も厳しい制限が適用される。つまり、AI訓練目的のクロールをブロックしているサイトでは、同じクローラーによる検索目的のアクセスも自動的にブロックされるのだ。
これはrobots.txtとは根本的に異なる。robots.txtはクローラーへの「お願い」に過ぎず、無視されることもある。しかしCloudflareのブロックはネットワークレベルで動作するため、robots.txtよりはるかに強力だ。グーグルでさえバイパスできない。AI訓練を止めたい一心で設定したブロックが、検索流入というサイトの生命線を断ち切ってしまう皮肉な構造が生まれている。
9月15日のデフォルト変更が生む3つのリスク
2026年9月15日に自動適用されるデフォルト設定の変更は、Cloudflareを利用するあらゆるサイトに影響を及ぼす。特に注意すべきは以下の3点だ。
とりわけ危険なのはリスク3だ。従来の「AIボットをブロック」設定を有効にしたまま放置しているサイトは、9月15日以降にGooglebotのアクセスがネットワークレベルで遮断される可能性がある。検索クロールが停止すれば、新規コンテンツのインデックス登録が滞り、既存ページの再クロール頻度も低下する。検索順位への影響は数週間から数カ月かけて徐々に表面化するため、原因特定が遅れやすい。
robots.txtとの違いを理解しておくべき理由
多くのサイト運営者は「robots.txtでブロックしているから大丈夫」と考えがちだ。しかし、robots.txtはクローラーに対する紳士協定に過ぎず、グーグルも状況によって無視することがある。一方、Cloudflareのブロックはリクエストがオリジンサーバーに到達する前にネットワークエッジで遮断する。この違いは決定的だ。
robots.txtでのブロックは「できれば来ないでほしい」というお願いであり、Cloudflareのネットワークブロックは物理的な門番が門を閉ざすようなものだ。後者のほうが確実だが、その分だけ設定ミスの代償も大きい。AI訓練ブロックのつもりが検索クローラーまで締め出してしまうと、サイトの検索パフォーマンスは確実に悪化する。
実務者が今すぐ取るべき対応チェックリスト
9月15日までに対応を完了する必要がある。以下に具体的なアクションを時系列で整理した。
STEP 5のクロール統計監視は特に重要だ。9月15日以降にGooglebotのクロール頻度が急落した場合、Cloudflare設定に原因がある可能性が高い。Search Consoleの「クロール統計レポート」で1日あたりのクロールリクエスト数を確認し、急激な減少があれば即座にCloudflareダッシュボードを再確認する習慣をつけておきたい。
無料プランユーザーが特に注意すべきポイント
Cloudflareの無料プランを利用しているサイトは、9月15日までに一度もAIクローラー設定を変更していない場合、自動的に新デフォルトへ移行される。つまり「設定を触っていないから大丈夫」という認識が最も危険だ。何もしないことが、意図せずGooglebotブロックを招く可能性がある。
無料プランであっても、ダッシュボードから3カテゴリの設定を手動で確認・変更することは可能だ。Searchカテゴリだけは明示的に「許可」に設定し、TrainingやAgentはサイトのポリシーに応じて判断する。この一手間をかけるかどうかで、9月15日以降の検索パフォーマンスが大きく変わる。
今後の展望とサイト運営者が持つべき視点
Cloudflareは、マルチパーパスクローラーの運営者に対して「振る舞いごとにクローラーを分離する」ことを求めている。グーグルやアップル、マイクロソフトがこの要求に応じてGooglebotを用途別に分割するかどうかが、今後の分岐点となる。仮に分割が実現すれば、サイト運営者はAI訓練だけをブロックし、検索インデックスは許可するという選択が可能になる。
しかし、現時点ではその保証はない。9月15日以降もGooglebotは単一のクローラーとして動作し続ける可能性が高い。つまり、AI訓練をブロックするという選択は、当面の間「検索流入とのトレードオフ」であり続ける。この現実を直視した上で、サイト運営者は自社のコンテンツ戦略とAIポリシーを再定義する必要がある。
Cloudflareは新しいコンテンツ利用シグナルもテスト中だ。robots.txtに記述するContent Signalsの拡張で、immediate（保存しない）、reference（インデックスしてリンクバック、新デフォルト）、full（要約・複製を許可）の3段階を指定できるようにする。ただしこれは設定上の「希望表明」であり、単体ではブロック機能を持たない点に注意が必要だ。
サイト運営者が今から準備すべき3つのこと
AIにコンテンツを学習されることを完全に拒否するのか、それとも検索流入を優先するのか。この問いに明確な答えを持たないまま9月15日を迎えると、Cloudflareの新デフォルトによって想定外のブロックが発生し、検索パフォーマンスが毀損するリスクがある。サイトの規模や収益構造に応じて、今のうちに方針を固めておくことが重要だ。
この記事のポイント
- CloudflareのAIクローラー管理が3つの振る舞い分類（Search、Agent、Training）に再編された
- 9月15日から広告表示ページでTrainingとAgentがデフォルトブロックされ、無料プランユーザーも自動移行の対象
- Googlebotのような混合用途クローラーは、AI訓練をブロックすると検索クロールも停止する
- robots.txtと異なり、Cloudflareのブロックはネットワークレベルで動作しバイパスが困難
- Searchカテゴリの許可確認とSearch Consoleでのクロール統計監視が当面の最優先対応
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
2026年3月のGoogleコアアップデートとクロール制限、Gemini流入増加の最新動向
Googleは2026年3月27日、2026年最初の広範なコアアップデートの適用を開始した。このアップデートは最大2週間かけて段階的に展開される。同時に、Googlebotのクロールアーキテクチャと2MBのバイト制限に関する技術的な詳細が明らかになった。
さらに、AI検索エンジンからの流入データでは、Google Geminiが2025年11月から2026年1月にかけて流入数を115%増加させ、Perplexityを上回った。これらの動向は、2026年上半期のSEO戦略に直接影響を与える要素だ。
2026年3月Googleコアアップデートの詳細
Googleの2026年3月コアアップデートは、2026年最初の広範なランキングアルゴリズム更新となる。前回の広範なコアアップデートは2025年12月29日に完了しており、約3ヶ月ぶりの更新だ。2026年2月のアップデートはDiscoverフィードのみに影響したため、検索結果のランキング自体は約3ヶ月間調整されていなかった。
アップデートの特徴と期間
このアップデートは「より関連性が高く、満足度の高いコンテンツをあらゆる種類のサイトから表示する」ことを目的とした定期的な更新と説明されている。適用開始は2026年3月27日で、完了までに最大2週間を要する見込みだ。
注目すべきは、このコアアップデートが3月のスパムアップデート完了からわずか2日後に開始された点だ。スパムアップデートは20時間未満で完了したが、コアアップデートとは目的が異なる。GoogleのサーチリレーションチームのJohn Mueller氏は、Blueskyでの投稿で「一方はスパムに関するもの、もう一方はスパムに関するものではない」と両者の違いを説明している。
Mueller氏はさらに、コアアップデートが単一のデプロイメントメカニズムに従わない理由を解説した。異なるチームとシステムが変更を提供し、それらのコンポーネントは単一のリリースではなく段階的なロールアウトを必要とする。これがアップデートに数週間かかり、ランキングの変動が一斉ではなく波状に現れる理由だ。
SEO担当者が取るべき対応
Search Engine JournalのRoger Montti氏は、スパムアップデートとコアアップデートの近接が偶然ではない可能性を指摘している。スパム対策は、コアアップデートにおけるより広範な品質再評価の論理的な一部だ。
ランキングの変化は4月上旬を通じて現れる可能性がある。Googleは、ロールアウトが完了してから少なくとも1週間待ってからSearch Consoleのパフォーマンスを分析することを推奨している。比較基準は3月27日以前の期間に設定するべきだ。
コアアップデートの影響を評価する際は、単一の要因に注目するのではなく、コンテンツの総合的な品質を検証する必要がある。E-E-A-T（経験、専門性、権威性、信頼性）の観点から自社コンテンツを見直し、ユーザーの意図に真に応えているかどうかを確認することが重要だ。
Googlebotの2MBクロール制限とアーキテクチャ
GoogleのGary Illyes氏は、GooglebotがGoogleのより広範なクロールシステム内でどのように機能するかを説明するブログ記事を公開した。この記事は、今年初めに公開された2MBのクロール制限に新たな技術的詳細を追加するものだ。
集中型クロールプラットフォームの仕組み
Illyes氏はGooglebotを、集中型クロールプラットフォームの一つのクライアントとして説明している。Google Shopping、AdSense、その他の製品もすべて、異なるクローラー名で同じシステムを通じてリクエストをルーティングする。HTTPリクエストヘッダーは2MB制限にカウントされる。CSSやJavaScriptなどの外部リソースは、それぞれ別個のバイトカウンターを持つ。
この集中型プラットフォームの詳細は、異なるGoogleクローラーがサーバーログで異なる動作をする理由も説明する。各クライアントは独自の設定、バイト制限を含めて設定する。Googlebotの2MBは、プラットフォームのデフォルト15MBを上書きする検索固有の設定だ。
2MB制限が実際に意味すること
Googlebotが2MBに達すると、ページを拒否するわけではない。取得を停止し、切り詰められたコンテンツを完全なファイルであるかのようにインデックス作成に渡す。2MBを超える部分は決してインデックスされない。これは、大きなインラインbase64画像、重いインラインCSSやJavaScript、巨大なナビゲーションメニューを持つページにとって重要だ。
Zyppy SEOの創業者Cyrus Shepard氏はLinkedInで「非常に大きなページで特定のコンテンツがインデックスされていないことに気付いた場合は、サイズを確認したい」と述べている。
Googleは2ヶ月以内に、ドキュメント更新、ポッドキャストエピソード、そしてこのブログ記事でこれらの制限をカバーした。Illyes氏は、2MB制限は永久的なものではなく、ウェブの進化に伴って変更される可能性があると述べている。
ページサイズの増大とその影響
10年で3倍に膨らんだウェブページ
Gary Illyes氏とGoogleのデベロッパーアドボケートMartin Splitt氏は、最近のSearch Off the Recordポッドキャストエピソードでページ重量の増加とクロールについて議論した。ウェブページは過去10年で約3倍に成長している。15MBのデフォルトはGoogleのより広範なクロールシステム全体に適用され、Googlebotのような個々のクライアントはそれを2MBに下方修正する。
Illyes氏は、Googleがウェブサイトに追加を求める構造化データがページの肥大化に貢献しているかどうかという問題を提起した。Googleはリッチリザルトのためにスキーママークアップを追加することをサイトに促しており、そのマークアップは各ページの重量を増加させる。
実務的なチェックポイント
2025年のWeb Almanacは、モバイルホームページの中央値サイズを2,362KBと報告している。これはページが大きくなっていることを示すが、Googlebotの2MB取得制限を安全に下回っていると考えるべきではない。Splitt氏は、ページサイズを削減する具体的なテクニックについて将来のエピソードで取り組む予定だと述べている。
重いインラインコンテンツを持つページは、重要な要素が応答の最初の2MB以内にロードされることを確認する必要がある。HTMLドキュメント自体のサイズに加え、HTTPヘッダーも制限に含まれる点に注意が必要だ。大規模なメディアファイルやスクリプトをインラインで埋め込む場合は、特に注意深くサイズ管理を行うべきだ。
Geminiからの流入がPerplexityを上回る
SE Rankingの分析によると、Google Geminiは2025年11月から2026年1月の間にウェブサイトへの流入数を115%以上増加させた。このデータは、Google Analyticsがインストールされた10万1,000以上のサイトを分析したものだ。
AI流入市場の勢力図変化
SE Rankingは2ヶ月間で115%の合計増加を測定し、この跳躍はGoogleがGemini 3を展開した時期に始まった。1月には、Geminiは世界的にPerplexityより29%、米国では41%多くの流入を送った。ChatGPTは依然として全AI流入の約80%を生成している。透明性のために、SE RankingはAI可視性追跡ツールを販売している。
2025年8月には、PerplexityはGeminiより約2.9倍多くの流入を送っていた。Geminiの12月から1月の急増は、2026年1月までにそれを逆転させた。ChatGPTのGeminiに対するリードも、10月の約22倍から1月の約8倍に狭まった。
AI流入の全体像と実務への影響
すべてのAIプラットフォームを合わせても、依然として全世界のインターネットトラフィックの約0.24%を占めるにすぎない。これは2025年の0.15%から増加している。これは測定可能な成長だが、オーガニック検索と比較するとまだ小さなシェアだ。2ヶ月間のGemini成長は既知の製品ローンチと相関するが、持続的なパターンと呼ぶには時期尚早だ。
実務的には、Geminiは流入レポートでChatGPTやPerplexityと並んで注目する価値がある。AI検索エンジンからの流入はまだ全体のごく一部だが、特定の業界やコンテンツタイプでは無視できない割合に達している可能性がある。流入元分析ツールでAIトラフィックを個別にセグメント化し、その傾向を追跡することが推奨される。
今週のテーマ：Googleが自社システムを説明する
今週の4つのストーリーのうち3つは、Googleが自社のシステムの仕組みを説明するものだ。Illyes氏はGooglebotのアーキテクチャを詳述するブログ記事を公開した。同じ週に、Search Off the Recordポッドキャストはページ重量とクロール閾値をカバーした。Mueller氏は、コアアップデートが一斉ではなく波状にロールアウトされる理由を説明した。それぞれがドキュメントだけでは残っていたギャップを埋める。
Gemini流入データは新たな視点を提供する。Googleは自社のクローラーとランキングシステムがどのように動作するかについてオープンになっている。そのAIサービスを通じるトラフィックは、第三者のデータに反映されるほど急速に増加しており、Googleはその部分については説明していない。
この傾向は、Googleがアルゴリズムの透明性を高める方向に進んでいることを示唆する。SEO担当者は、これらの技術的説明を表面的な情報としてではなく、自社サイトの最適化に直接応用できる実用的な洞察として扱うべきだ。
この記事のポイント
- 2026年3月コアアップデートは最大2週間かけて適用され、ランキング変動は波状に現れる。分析はロールアウト完了1週間後から行うべきだ。
- Googlebotの2MBクロール制限は絶対的な拒否ではなく、2MB以降のコンテンツはインデックスされない。HTTPヘッダーも制限に含まれる。
- ページサイズは10年で約3倍に増加。構造化データの追加も肥大化要因の一つとして認識されている。
- Geminiからの流入は2026年1月にPerplexityを上回ったが、AI流入全体では依然としてChatGPTが8割を占める。
- Googleは自社システムの技術的詳細を積極的に開示する方向にシフトしている。これらの情報は実践的なSEO最適化に活用できる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Googlebotの正体は「数百のクローラー」の集合体。未公開システムの仕組みとSEOへの影響
Googlebotは単一のプログラムではなく、実際には数百もの異なるクローラーやフェッチャーが組み合わさった巨大なシステムの総称だ。GoogleのGary Illyes（ゲイリー・イリェーシュ）氏とMartin Splitt（マーティン・スプリット）氏が公開したポッドキャストにより、その複雑な内部構造が明らかになった。
2026年3月に公開されたこの情報によると、Googleが運用するクローラーの大部分は公開ドキュメントに記載されていない。これは、特定のチームが小規模な目的で使用するクローラーが膨大に存在するためだという。
Webサイト運営者やSEO担当者にとって、この事実はログ解析やクローラー制御の考え方を根本から見直すきっかけとなる。Googlebotという名称の裏側に隠された、巨大なクロール・インフラの実態を詳しく紐解いていく。
Googlebotは単一の存在ではない？クローラーの正体
一般的に「Googlebot」といえば、Webサイトを巡回してインデックスを作成する一つのロボットをイメージしがちだ。しかし、著者のGary Illyes氏によれば、現在のGooglebotは独立した一つのシステムではない。
「Googlebot」という名称の歴史的背景
Googlebotという名前が使われ始めた2000年代初頭、Googleには実際に一つのクローラーしか存在しなかった。当時は提供しているサービスも検索エンジンのみであり、単一のシステムで事足りていたからだ。しかし、AdWords（現在のGoogle 広告）などの新サービスが登場するたびに、専用のクローラーが追加されていった経緯がある。
現在では、ニュース、画像、動画、広告など、用途別に最適化された無数のクローラーが動いている。それでも「Googlebot」という名称が使われ続けているのは、歴史的な慣習によるものだ。実態としては、一つの巨大な「クロール・インフラ」を多くのクライアントが利用している状態に近い。
内部インフラとクライアントの関係性
Googlebotの本質は、クロール・インフラそのものではなく、そのインフラを利用する「クライアント」の一つである。これは、図書館（インフラ）に対して、本を借りに行く利用者（Googlebot）が複数いる状態に例えられる。利用者はGooglebotだけでなく、他にも何百人と存在するのだ。
この仕組みにより、Google内部の各開発チームは、共通の強力なクロール基盤を利用しながら、自分たちの目的に合わせた独自のクローラーを走らせることができる。私たちが普段目にしているGooglebotは、氷山の一角に過ぎないのである。
クロール・インフラの仕組みと「SaaS」的側面
Google内部で運用されているクロール・インフラには特定の名称があるが、Gary Illyes氏はその公開を控えた。彼はこのインフラを、ソフトウェアをサービスとして提供する「SaaS（Software as a Service）」のようなものだと説明している。
内部APIを通じたデータの取得プロセス
Googleのエンジニアがインターネット上のデータを取得したい場合、このインフラが提供するAPIエンドポイントを呼び出す。API（Application Programming Interface）とは、ソフトウェア同士が機能を共有するための窓口のことだ。エンジニアはこの窓口を通じて、「このURLのデータを取ってきてほしい」というリクエストを送る。
リクエストを受けたインフラ側は、クラウドやデータセンターのリソースを使い、対象のWebサイトに負荷をかけすぎないよう配慮しながらフェッチ（取得）を実行する。つまり、クローラーをゼロから開発する必要はなく、共通のAPIを叩くだけで高度なクロール機能を利用できる仕組みが整っているのだ。
パラメータ設定による柔軟な制御
APIを呼び出す際には、さまざまなパラメータを指定できる。例えば、データの返信を待つ時間（タイムアウト設定）、名乗る名前（ユーザーエージェント）、遵守すべきrobots.txtのルールなどだ。多くの場合はデフォルト設定が適用されるため、開発者は複雑な設定なしに利用できる。
ユーザーエージェントとは、クローラーがWebサーバーにアクセスする際に提示する「自己紹介文」のようなものだ。この設定を変更することで、特定のチーム専用のクローラーとして振る舞うことが可能になる。この柔軟性が、数百種類ものクローラーを生み出す要因となっている。
なぜ「未公開」のクローラーが数百も存在するのか
Googleの公式サイトには主要なクローラーの一覧が掲載されているが、そこに含まれないクローラーが圧倒的に多い。これには、ドキュメント管理の現実的な限界と、情報の重要度による線引きが関係している。
公開ドキュメントに記載される基準
Gary Illyes氏によれば、すべてのクローラーをドキュメント化することは事実上不可能だという。Googleは巨大な組織であり、数多くのチームがそれぞれの目的でクローラーを運用しているからだ。もし数百のクローラーをすべて詳細に記載すれば、開発者向けのドキュメントページは膨大な量になり、かえって利便性を損なうことになる。
そのため、Googleは「トラフィック量」という基準で線を引いている。インターネット全体に対して目に見えるほどの影響力を持つ、あるいは頻繁にサイトを訪れる主要なクローラーのみを公開対象としている。小規模なテスト用や特定の機能限定のクローラーは、あえて非公開のままにされているのだ。
内部チームによる多様な用途
未公開のクローラーは、検索以外の多種多様な目的で使用されている。例えば、新機能のプロトタイプ作成、内部的なデータ分析、あるいは特定のセキュリティチェックなどが考えられる。これらのクローラーは取得するURLの数が非常に少ないため、一般的なWebサイト運営者がその存在に気づくことはほとんどない。
ただし、特定のクローラーが一定の閾値を超えて大量のアクセスを行うようになった場合、Gary Illyes氏らはそのチームに連絡を取り、動作の正当性を確認した上でドキュメント化を検討するという。これにより、Webエコシステムへの悪影響を防ぐ監視体制が敷かれている。
「クローラー」と「フェッチャー」の決定的な違い
Google内部では、データを取得する仕組みを「クローラー（Crawler）」と「フェッチャー（Fetcher）」の2種類に明確に使い分けている。これらは動作の仕組みも、実行されるタイミングも大きく異なる。
バッチ処理と個別リクエストの使い分け
クローラーは「バッチ処理」で動作する。バッチ処理とは、大量のデータをまとめて一括で処理する方式のことだ。クローラーには常に巡回すべきURLのリストが供給され、24時間365日、システムが空いている時間に継続的にデータを取得し続ける。これが一般的な検索インデックス作成の仕組みだ。
一方、フェッチャーは「個別URL」単位で動作する。特定のURLを指定して、その1件だけを即座に取得するのが役割だ。クローラーが「広範囲を網羅する網」だとすれば、フェッチャーは「ピンポイントで狙う釣り竿」のようなものだと言える。
ユーザー操作がトリガーとなるフェッチ
フェッチャーが動く際の特徴は、多くの場合「ユーザーの操作」が起点となっている点だ。例えば、Search Consoleで「URL検査」を実行し、現在の状態をライブテストする場合などがこれに当たる。画面の向こう側に、結果を待っている人間がいる状態だ。
Googleの内部ポリシーでは、フェッチャーはユーザーの制御下にあるべきだと定められている。これに対してクローラーは、システムの都合に合わせて自律的に動く。この違いを理解しておくことは、サーバーログを見て「なぜ今このアクセスが来たのか」を推測する際の大きなヒントになる。
Webサイト運営者が知っておくべき実務上の注意点
Googlebotが数百のクローラーの集合体であるという事実は、実務においてどのような意味を持つのか。特にセキュリティやパフォーマンスの観点から、サイト運営者が意識すべきポイントを整理する。
未知のユーザーエージェントへの対応
サーバーログを分析していると、GoogleのIPアドレス帯域からのアクセスであるにもかかわらず、ドキュメントに載っていないユーザーエージェントを見かけることがあるかもしれない。これまでは「偽装されたボット」と判断して遮断していたケースもあるだろうが、その一部はGoogle内部の正当な未公開クローラーである可能性がある。
重要なのは、ユーザーエージェント名だけで判断せず、IPアドレスの逆引き（DNSルックアップ）を行って、本当にGoogleからのアクセスかどうかを確認することだ。正当なGoogleのインフラからのアクセスであれば、むやみにブロックせず、サイトのクロールバジェット（クローラーが巡回できる許容量）の範囲内で許容するのが賢明だ。
サーバー負荷とログ解析の視点
数百のクローラーが存在するということは、それだけ多様な目的でサイトがスキャンされる可能性があることを意味する。しかし、Gary Illyes氏が述べている通り、未公開のクローラーは通常、極めて低頻度でしか動作しない。もし特定のボットが大量のアクセスを行い、サーバー負荷を高めているのであれば、それは主要なクローラーであるか、あるいは設定ミスによる異常動作である可能性が高い。
また、robots.txtでの制御も、基本的には「Googlebot」というメインのトークン（識別子）で大部分をカバーできる。個別の未公開クローラーをすべて制御しようとするのは現実的ではなく、主要な指示系統を整理しておくことこそが、SEOにおけるクローラビリティ最適化の王道であることに変わりはない。
この記事のポイント
- Googlebotは単一のプログラムではなく、数百種類のクローラーやフェッチャーが共通のインフラを利用する集合体である。
- Google内部ではクロール機能を「SaaS」のように提供しており、APIを通じて誰でもフェッチリクエストを送れる仕組みがある。
- 公開ドキュメントに載っているのは主要なクローラーのみで、トラフィックの少ない小規模なものは非公開とされている。
- 「クローラー」はバッチ処理で継続的に動き、「フェッチャー」はユーザー操作などを起点に個別URLを取得する。
- サイト運営者は、ドキュメント外のクローラーも存在することを前提に、IPアドレスベースでの正当性確認を行うことが推奨される。
出典
- Search Engine Journal「Google Says Hundreds Of Their Crawlers Are Not Documented」（2026年3月13日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験