Googlebotは存在しない？Google公式が語ったクロールの仕組みと12の誤解

検索を学ぶ

クロールについての相談は、だいたい2種類に分かれます。「クロールされない」か、「クロールされすぎる」かです。

どちらの場合も、最初に確認したいのは仕組みのほうです。Googlebotが何をしていて、何をしていないのか。ここがずれていると、打ち手も的外れになります。そしてこの部分は、Googleの公式ドキュメントよりも、検索チームのポッドキャスト「Search Off the Record」のほうが詳しく語られています。

この記事では、クロールをテーマに扱った回から、仕組みの説明と、Googleが明確に否定した12の誤解をまとめました。3年分を並べると、Googlebotという言葉の意味そのものが変わってきたことが見えてきます。

この記事は「Search Off the Record 全54回まとめ」のクラスタ記事です。他のテーマは元記事から辿れます。

Googlebotとは何なのか

1. Googlebotは、賢く判断していない

まずここから崩れます。

第64回（2023-09-19）で説明されたのは、Googlebot自体は単純なフェッチャーに過ぎない、ということでした。”Googlebot is pretty much just a Wget or a Curl instance running into cloud.”（第64回、2023-09-19）という言い方がされています。取ってくるだけ。それ以上のことはしていません。

では「このページは重要そうだから優先的に取りに行こう」という判断は誰がしているのか。クロールスケジューラという別のシステムです。品質を予測して優先順位を決めているのはこちらで、Googlebotはその指示に従ってフェッチしているだけ、という構造になります。

この区別は実務でも効いてきます。「Googlebotに気に入られる」という発想は、そもそも対象を間違えているということになるからです。

2. 3つのシステムに分かれている

第70回（2024-03-14）では、もう少し細かい内訳が示されました。Googlebotと呼ばれているものは、次の3つで構成されています。

  • フェッチャー — 実際にURLを取得する部分
  • コントローラー — 発見したリンクとサイトマップなどの情報を統合する部分
  • スケジューラー — いつ何を取得するかを決める部分

そしてGooglebot自体はフェッチしか行わず、インデックスするかどうかの判断には関与しません。クロールとインデックスが別の工程だという話はよく言われますが、内部の分かれ方としてもそうなっている、ということです。

3. もともとは、本当に1つだった

ここが個人的に面白かった部分です。

第92回（2025-05-29）でクローラーの歴史が語られています。初期のGoogleでは、Googlebotという単一のフェッチャーが検索・AdWords・Gmailといったすべてのプロダクトで使われていました。そのため、あるアクセスがどの目的で来たものなのか判別できないという問題があったそうです。

2006年頃にAdsBotが導入され、そこからプロダクトごとに専用のユーザーエージェントを持つ複数のクローラーが生まれていきました。ただし共有インフラの上で動いているため、robots.txtの遵守やホスト負荷の管理といった挙動は統一されています。

もう一つ、クロールとリソース消費についてGaryの私見が述べられています。”it’s not crawling that is eating up the resources; it’s indexing and potentially serving”（第92回、2025-05-29）。リソースを食っているのはクロールそのものではなく、その後のインデックス化や配信のほうだ、という見方です。

4. そして「Googlebot」は誤称になった

2026年3月に公開された2本が、決定的でした。

第107回（2026-03-12）と第106回（2026-03-30）で説明されたのは、Googlebotが単一のプログラムでも実行ファイルでもない、ということです。実際には社内に共通のクロール基盤があり、各チームがAPIを呼び出す形でフェッチを依頼しています。User-Agent、タイムアウト、robots.txtのプロダクトトークンといったパラメータを指定して呼び出す、SaaSに近い構造です。Googlebotは、その多数のクライアントのうちの一つに過ぎません。

“Calling it Googlebot, that’s a misnomer.”（第107回、2026-03-12）という表現が使われています。

起源も語られていて、1998〜99年頃にエンジニアの作業マシンで動いていた単純なWgetスクリプトが始まりだそうです。プロダクトが増えるにつれて再設計を重ね、現在の形になりました。第92回の歴史の話と合わせると、単一だったものが20年かけて分岐した結果、名前だけが取り残されたという流れが見えてきます。

取得サイズの上限

第106・107回では具体的な数値も出ています。実装の判断に関わる部分なので挙げておきます。

対象上限
インフラ全体のデフォルト15MB
Google検索（HTML）2MB に上書き
PDF約64MB

“the infamous 15 megabyte default limit that is set at the infrastructure level”（第106回、2026-03-30）という言い方で、15MBという数字自体は以前から知られていたものだと分かります。ただし検索用途では2MBに絞られている、というのは新しい情報でした。

HTML Living Standardのように単一ページが巨大な文書は、丸ごと取得せず個別の機能ページを取得する運用になっているそうです。

注意: これらは2026年3月時点で語られた内部仕様です。変更されやすい部分なので、この数値を前提に設計するのは避けたほうがいいと思います。

クロール量は何で決まるのか

最大の要因は品質

第64回では、クロールスケジューリングに使われるシグナルとして「品質」と「更新頻度」の2つが挙げられ、このうち最も重要なのは品質だと説明されました。

さらに品質は、クロールだけの話ではありません。インデックス選択、インデックス化、ランキングまで、検索システム全体に影響する最大の要因である、という位置づけです。

実務上重要なのは、品質評価がURLパターン単位で学習・適用されることがあるという点です。サイト内の特定ディレクトリが低品質と判断されると、そのパターン配下のクロール頻度が下がります。逆に言えば、低品質なUGCを別のURLパターンに分離することでクロール状況が改善した事例もある、と紹介されています。

そして品質評価は固定ではありません。低品質なコンテンツを削除・改善すれば、不利な扱いから抜け出せる、と明言されています。

クロールを増やす方法は、存在しない

第79回（2024-08-08）は、この記事で扱う中でも最も実務に直結する回です。

まず、Search Consoleにはクロール量を減らす設定はありますが、増やす設定はありません。developers.google.com/search にあるGooglebotの問題報告フォームも、クロール過多によるサーバー負荷を報告するためのもので、「もっとクロールしてほしい」という要望を送っても対応されないと明言されています。

クロール需要は、コンテンツの品質と、サーバーが処理できる技術的な上限の両方で決まります。どちらも外から申請して変えられるものではありません。

同じ回で、Googlebotの動作を「リンクをたどる」と説明することへの違和感も語られています。”we keep saying Googlebot is following links, like, no, it’s not following links.”（第79回、2024-08-08）。第70回で説明された3層構造を踏まえると、リンクをたどるのはコントローラーの仕事で、フェッチャーは指示されたURLを取りに行っているだけ、ということになります。

クロールバジェットは、予算ではない

第70回で、Lizziがクロールバジェットを金銭的な予算になぞらえて説明しようとした場面があります。そこでGaryが “It has nothing to do with money. Jeeze, don’t take us there.”（第70回、2024-03-14）と遮ります。

「バジェット」という言葉から、使い切ると足りなくなる配分のようなものを想像しがちですが、そういう性質のものではありません。クロール制限（ハードリミット）はサイト負荷を避けるための上限であり、検索側の需要フィードバックによって上下します。

Googleが否定したクロールの12の誤解

ここまでの内容と、関連する回で否定された項目をまとめます。

誤解Googleの説明出典鮮度
Googlebotは賢く判断してクロールしている単純なフェッチャーに過ぎない。判断はクロールスケジューラ第64回 2023-09-19要確認
クロールバジェットの「バジェット」はお金の予算金銭的な予算とは無関係第70回 2024-03-14要確認
多くクロールされている＝良いサイト否定。ハッキングや無限URL空間でも増える第79回 2024-08-08要確認
報告フォームで依頼すればクロールを増やしてもらえる増やす対応はしない第79回 2024-08-08要確認
Googlebotは単一のプログラム・実行ファイルである共通クロールインフラを呼び出すクライアントの一つ第106回 2026-03-30／第107回 2026-03-12新しめ
地域ブロックでGooglebotを確実に制御できる信頼できる制御手段ではない第107回 2026-03-12新しめ
403や404を返すとクロール速度が落ちる落ちるのは503など。クライアントエラーは影響しない第107回 2026-03-12新しめ
Indexing APIで任意のURLをインデックスさせられる対象は求人情報とライブ動画配信のみ第94回 2025-06-26新しめ
site:検索でインデックス数を正確に確認できる確認用途には不向き第61回 2023-06-22要確認
Markdown化するとLLMに見つけてもらいやすくなる不要。クローラーはHTML処理を解決済み第111回 2026-06-15新しめ
llms.txtを置くとAI・検索からの発見性が高まる意味がないと明確に否定第111回 2026-06-15新しめ
検索結果ページのインデックスはペナルティ対象対象ではない。技術的な非効率の問題第113回 2026-07-30新しめ

増えているとき、減っているときの読み方

Search Consoleのクロール統計を見て、何を判断すればいいのか。第79回と第107回の内容を組み合わせると、こう整理できます。

クロールが増えているとき

品質が評価された結果とは限りません。第79回で挙げられているのは、ハッキングされて新規URLが大量に発生したケースと、無限に生成されるURL空間があるケースです。増加はまず異常を疑うほうが実務的だと思います。

クロールが徐々に減っているとき

こちらは、コンテンツ品質が低いとGoogleが判断したサインである可能性がある、とされています。ただし品質評価は改善可能なので、減少が確定的な評価というわけでもありません。

ステータスコードとの関係

第107回では、サーバーの応答遅延や503エラーがあると自動的にクロール速度が落ちる一方、403や404はクロール速度に影響しない、と説明されています。404が大量に出ているサイトで「クロールバジェットが減る」と心配するケースがありますが、少なくともクロール速度の観点では別の話です。

最初に見るべき数字

第79回でJohnが挙げているのは、Search ConsoleのCrawl Statsレポート、特に平均応答時間です。ここを見ずにクロール不足を訴えるケースが多い、という指摘でした。応答に数秒かかっているなら、それは客観的に改善余地のある問題です。

ホスティング会社側の問題も指摘されています。GooglebotがDNSやサーバーでブロックされているのに、顧客側の問題として説明されてしまうケースがある、という話です。

クロールを無駄に使わせないための実装

無限スペースを作らない

第113回（2026-07-30）はサイト内検索結果ページを正面から扱っています。検索結果ページは、キーワードやフィルタの組み合わせ次第で無限に近いURLを生成しうる「infinite space」になります。しかも検索結果ページは通常キャッシュされず、アクセスのたびにデータベース検索とランキング処理が走るため、クロールが増えるとサーバー負荷と表示速度の両方に響きます。

対処法は主に2つです。

  • robots.txtで検索パスごとdisallow — クロール自体を防ぐ。管理が簡単
  • noindex（HTTPヘッダーまたはmetaタグ） — クロールは許すがインデックスを防ぐ

robots.txtのルールは細かく分割せず、検索パス全体を一つのシンプルなパターンでまとめるほうが管理しやすい、とされています。

やってはいけないこととして、500エラーを返すのは絶対に避けるべきと明言されています。500が続くと、Googleはサイト全体のクロール頻度を下げてしまうためです。404を返すのは可能ですが、キャッシュ絡みで問題が出ることがあります。Search ConsoleのURL削除ツールは一時的な非表示にすぎず、クロールは止まらないので根本解決になりません。

一点、例外があります。BloggerなどのCMSでは検索結果ページをタグ・カテゴリのランディングページとして使っている場合があり、これらは通常のカテゴリページとして扱われるべきなので、一律にブロックすべきではありません。

URLパラメータについても第79回で触れられています。パラメータは理論上無限に付与できてしまい、Googleは実際にクロールしてサンプルを集めるまで、どのパラメータが無意味か判断できません。Search ConsoleのURLパラメータツールは利用が少なく廃止されましたが、robots.txtで柔軟にブロックできます。

条件付きリクエストに正しく応答する

第79回では、If-Modified-Sinceリクエストに対して304を正しく返せば、無駄な帯域とリソース消費を減らせる、と説明されています。ところが多くのサーバーはこれを無視して、毎回200で全文を返してしまっているそうです。

自社サーバーがどう応答しているか、確認したことがない人は多いのではないでしょうか。ここは費用対効果の高い改善ポイントだと思います。

エラーページは、正しいステータスコードを返す

第87回（2024-12-05）で語られた「ブラックホール」問題は、知らないと踏みます。

エラーページが200を返すと、正常なページと同じチェックサムでクラスタリングされてしまいます。つまり、エラーページ群が一つの重複クラスタにまとまってしまう。しかも一度巻き込まれると抜け出しにくい。クロールが再訪しにくくなるためです。一時的なエラーでこれが起きると特に危険だ、とされています。

回避策は、404や403、503といった正しいHTTPステータスコードを返すことです。JavaScriptレンダリングの都合でステータスコードの制御が難しい場合は、明示的なエラーメッセージ文言を表示するか、静的な404・500ページへJSリダイレクトする方法が有効だとされています。

なお、noindexとHTTPエラーコードは扱いが異なります。noindexは即座にインデックスから削除されますが、エラーコードは猶予期間を経て削除されます。一時的なエラーにnoindexを使うべきではありません。

CDNのbot検出ページにも注意が必要です。「You look like a bot」のようなページがGooglebotにも配信されると、複数のサイト間で誤ってクラスタリングされる問題があるそうです。

Googlebotを弾いていないか

第107回によると、Googleのクロールは主に米国カリフォルニア（Mountain View）発のIPアドレス、66.x.x.x などから行われています。地域ブロックをかけていると、403やタイムアウトになります。

特定のコンテンツの価値が非常に高いと判断された場合に限り、まれに他国のIPを割り当てて回避することもあるそうですが、これに依存すべきではないと明言されています。日本国内向けにアクセス制限をかけているサイトは、意図せずGooglebotを弾いている可能性があります。

ステージングサイトの扱い

第59回（2023-04-05）では、ステージングサイトが誤ってインデックスされる問題が扱われています。カスタムCMSでも大手ホスティングでも起こりうる問題で、特に2つのホスト名を使って開発している場合に起きやすいそうです。

推奨されているのはパスワード保護です。検索エンジンだけでなく一般の人からも隠せるため、というのが理由でした。robots.txtによるブロックも、URLの内容をクロールできないためインデックス判断ができず、シンプルで効果的な方法として挙げられています。

関連して、リンクされておらず、どこにも言及されていないURLは「深宇宙」のようなもので、Googleが見つけるのは非常に難しい、という説明があります。Google Search Status Dashboardは、サイトマップもリンクも一切用意せず「何もしない」ことで、長期間発見されなかったそうです。

やらなくていいこと

Markdown化とllms.txt

第111回（2026-06-15）で扱われています。サイトをMarkdown化するとLLMに見つけてもらいやすくなる、という説は誤りで、クローラーは既にHTML処理を解決済みなので不要だと否定されました。”I don’t think that’s a problem that needs solving.”（第111回、2026-06-15）という言い方がされています。

llms.txtの設置についても、AI・検索システムからの発見性が高まるという考えを、Johnが意味がないとはっきり否定しています。

Indexing APIの目的外利用

第70回と第94回（2025-06-26）の両方で扱われています。Indexing APIの対象は求人情報とライブ動画配信に限られており、任意のURLをインデックスさせるためのものではありません。Garyは他用途への拡大にも反対の立場を示しています。

第70回では、低品質なコンテンツをIndexing APIなどで無理にインデックスさせても、品質評価によって短時間で削除されることがある、とも語られています。

サイトマップに期待しすぎる

第70回によると、サイトマップは単にリンクの存在を伝えるだけのものです。クロール需要を増やす効果があるわけではありません。

では何が効くのか。自然なリンクやコンテンツへの注目、つまり人気です。加えて、ホームページなど重要な場所からの内部リンクは、新しいページのクロール優先度を上げるのに有効だとされています。

そして第70回では、サイト運営者は全ページのインデックスを目指すより、検索結果に表示させたい重要なURLを見極めるべきだ、という点で両者が同意しています。

参考：robots.txtの実態調査

ここだけ出典の性質が違うので分けて紹介します。

第108回（2026-04-23）で語られたのは、GoogleがHTTP ArchiveのデータをBigQueryで分析し、robots.txtに実際どんな記述が使われているかを調べた話です。以下の数値はGoogleの仕様説明ではなく、Web Almanacに掲載されている集計結果です。

  • robots.txtへのリクエストのうち200応答が84.9%、404が13%
  • ファイルサイズは概ね0〜100KB
  • ユーザーエージェント指定はアスタリスク（すべて）が多い
  • Googlebotへの言及率6.2%に対し、AdsBot-Googleは9.8%

AdsBotのほうが名指しされる率が高いというのは、少し意外な数字でした。

調査の経緯も語られていて、robots.txtの公式リポジトリに未サポートタグを追加するプルリクエストが届いたことがきっかけだったそうです。1件だけ対応するのではなく、データから上位10〜15個を洗い出そうという方針になった、と。ちなみにGaryは1回の大規模クエリで数百ドルの請求を受けたそうです。

日本のサイト運営者にとって

ここまでの内容のうち、日本のサイト運営者に特に関わってくるものを挙げておきます。ただし、これらの回で日本語検索や日本市場に特化した言及があるわけではありません。あくまで、日本のサイト運営者が置かれている状況に当てはまりやすい、という意味です。

大規模ECサイト・CMS運用サイト

第79回のURLパラメータとサーバー応答速度、第113回のサイト内検索結果ページ。どちらもページ数が増えるほど効いてきます。国内のECサイトは絞り込み検索とソートでURLが増えやすい構造のものが多いので、無限スペースの話はそのまま点検項目になります。

地域制限をかけているサイト

第107回のジオブロックの話です。国内向けサービスでアクセス元を制限している場合、Googlebotが米国IPから来ることを考慮できているか確認してください。

エラーページの実装

第87回のブラックホール問題は、日本語圏で事例が語られているのをあまり見かけません。エラー時に200を返すCMSやフレームワークの設定は珍しくないので、確認する価値はあると思います。

まとめ

クロールについて語られてきた3年分を並べて見えたのは、「Googlebot」という言葉が指すものが変わってきたということでした。

2023年の時点では、単純なフェッチャーであってそれ以上のことはしていない、という説明でした。2025年に歴史がたどられ、初期は本当に単一のフェッチャーだったことが語られます。そして2026年、それはもはや誤称であり、共通インフラを呼ぶクライアントの一つに過ぎないと明かされました。

実務への含意は、たぶんこの一点に集約されます。クロール量は、外から働きかけて増やせるものではない。 増やす窓口はなく、報告フォームも減らすためのものです。できるのは、品質を上げることと、無駄なクロールを発生させない実装にすることだけです。

裏を返せば、無限スペースを作らない、正しいステータスコードを返す、応答速度を改善する、Googlebotを弾いていないか確認する——このあたりは全部、自分たちの側でコントロールできます。クロールの相談を受けたとき、まず見るべきはそちらだと思います。

なお、この記事で「要確認」と付けた項目は、収録から時間が経っており状況が変わっている可能性があります。実装を決める前には developers.google.com の最新ドキュメントで裏を取ってください。

関連記事

  • Search Off the Record 全54回まとめ — この記事の元になったピラー記事
  • Search Consoleレポートの読み方 — インデックスレポートとsite:検索の話を詳しく
  • レンダリング・JavaScript SEOの現在地 — クロールの次の工程
  • スパム対策と品質評価のリアル — 何がペナルティ対象で何が非効率なだけか

コメント

タイトルとURLをコピーしました