言語

GooglebotのSEO

Googlebotの実態を解説します。SmartphoneとDesktop、Evergreen Chromiumのレンダリング、ユーザーエージェント文字列、IP範囲の検証、バイト制限、クロールとランキングの違いを扱います。

初回公開：2026年6月24日 · 最終更新：2026年8月23日 · 上級者向け
AI執筆者：AI v2
このページには証拠シグナルが1件あります

GooglebotはGoogleのウェブクローラーで、Googleがページを取得してインデックス登録とランキングを行えるようにするソフトウェアです。robots.txtで同じトークンを共有する2種類があり、モバイルファーストインデックスの主役であるGooglebot SmartphoneとGooglebot Desktopです。Evergreen Chromiumを実行し、JavaScriptを別の後続キューでレンダリングします（クロールとレンダリングは別です）。クロールはランキング要素ではなく、robots.txtでGooglebotをブロックしてもインデックス削除とは同じではありません。ブロックされたURLでもURLだけでインデックス登録される場合があります。ユーザーエージェントは簡単に偽装できるため、逆引きと正引きDNS、またはGoogle公開のIP範囲で検証します。「Googlebot」は、はるかに大きなクロールプラットフォームのうちGoogle検索の一部です。

TL;DR — GooglebotはGoogle検索のクローラーで、モバイルファーストインデックスの主役であるSmartphoneとDesktopに分かれます。両者はrobots.txtで1つのGooglebotトークンを共有するため、別々に指定できません。Evergreen Chromiumを実行し、JavaScriptは別の後続キューでレンダリングします（クロールとレンダリングは別です）。クロールはランキングの前提ですが、ランキングシグナルではありません。robots.txtでブロックされたURLでも、URLだけがインデックス登録される場合があります。本物かどうかは、Googleドメインへの逆引きと正引きDNS、またはGoogleが公開するIP範囲で確認します。ユーザーエージェントは簡単に偽装できます。また「Googlebot」は、より大きなクロール基盤のうち、検索向けの一部分にすぎません。

この主張の根拠 Googlebot is Google's crawler, with smartphone and desktop crawler types that share the same product token. 対象範囲： Current Googlebot crawler and user-agent documentation. 信頼度： 高 · 検証日： Google Search Central: Googlebot この主張の根拠 A claimed Google crawler can be verified using reverse and forward DNS or Google's published IP ranges. 対象範囲： Google's current crawler-verification methods. 信頼度： 高 · 検証日： Google Search Central: Verify Googlebot

Googlebotの実態

Googleは名称を正確に定義しています。“Googlebot is the generic name for two types of web crawlers used by Google Search.” (翻訳)「Googlebotは、Google検索が使用する2種類のウェブクローラーの総称です。」 その2種類が、Googlebot Smartphone（“a mobile crawler that simulates a user on a mobile device” (翻訳)「モバイル端末の利用者を模倣するモバイルクローラー」）と、Googlebot Desktop（“a desktop crawler that simulates a user on desktop” (翻訳)「デスクトップ利用者を模倣するデスクトップクローラー」）です。

1台のマシン上で動く小さなプログラムではありません。私のGooglebotガイド で説明しているように、“Googlebot runs on thousands of machines,” (翻訳)「Googlebotは数千台のマシンで動作します。」 そして “they determine how fast and what to crawl on websites,” (翻訳)「それらのマシンが、ウェブサイトをどの速度で、何をクロールするか決定します。」 という分散システムです。世界各地のデータセンターで稼働しますが、送信元は主に米国のIPアドレスです。新しいURLは、“primarily from links embedded in previously crawled pages” (翻訳)「主に、以前クロールしたページに埋め込まれたリンクから発見します。」、つまり以前クロールしたページ内のリンクを中心に発見し、サイトマップも利用します。発見とスケジューリングの全体像はクロールのハブで扱います。

SmartphoneとDesktop — 「スマートフォン優先」の理由

モバイルファーストインデックスでは、スマートフォン用クローラーが主役です。Googleは、“For most sites Google Search primarily indexes the mobile version of the content. As such the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.” (翻訳)「大半のサイトで、Google検索は主にモバイル版のコンテンツをインデックス登録します。そのため、Googlebotのクロールリクエストの大半はモバイルクローラーから、少数はデスクトップクローラーから行われます。」 と説明しています。2023年10月以降、すべてのサイトでモバイルファーストインデックスへの移行が完了しているため、実務上はスマートフォンエージェントに見えないコンテンツはインデックス登録されないと考えてください。モバイル版とデスクトップ版で、本文、構造化データ、メタデータ、robotsタグを一致させます。

robots.txtの注意点は、“Both crawler types obey the same product token (user agent token) in robots.txt, and so you cannot selectively target either Googlebot Smartphone or Googlebot Desktop using robots.txt.” (翻訳)「両方のクローラーはrobots.txtで同じプロダクトトークン（ユーザーエージェントトークン）に従うため、robots.txtを使ってGooglebot SmartphoneまたはGooglebot Desktopだけを選択的に指定することはできません。」 という点です。両者を区別できるのは、自社のサーバー側ロジックでHTTPのuser-agentリクエストヘッダーを読む場合だけです。ヘッダー形式の詳細はモバイルファーストインデックスとユーザーエージェントをご覧ください。

ユーザーエージェント文字列

両方のrobots.txtプロダクトトークンはGooglebotですが、完全なUA文字列は異なります。

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Googlebot Smartphone:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

W.X.Y.Zは現在のChromeバージョンを表すプレースホルダーで、GooglebotのEvergreen Chromiumが更新されるたびに変わります。ただし、文字列だけを信頼しないでください。簡単に偽装できます（後述の検証方法を参照）。

Evergreen Chromiumとレンダリングキュー

最も混同されやすいのは、クロールとレンダリングが別工程だという点です。Googlebotは “an evergreen version of Chromium,” (翻訳)「常に更新されるバージョンのChromium」 を実行します。2019年5月に古いChrome 41から安定版へ追随する方式へ移行したため、現在はES6以降、IntersectionObserver、Web Components、現代的なCSSへ対応しています。しかし、HTMLを取得した瞬間にJavaScriptを実行するわけではありません。

Googleは次のように説明しています。“Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that. Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.” (翻訳)「robotsメタタグまたはヘッダーでインデックス登録しないよう指定されていない限り、GooglebotはHTTPステータス200のすべてのページをレンダリング用キューへ入れます。キューで数秒待つことも、それ以上かかることもあります。Googleのリソースが利用可能になると、ヘッドレスChromiumがページをレンダリングしてJavaScriptを実行します。」 レンダリングサービス（WRS）は現代的なブラウザーに似ていますが、注意すべき特徴があります。実質的にステートレスで、ページ読み込みのたびにローカル／セッションストレージとCookieが消去されます。帯域を節約するため画像や動画を取得せず、強いキャッシュを使ってキャッシュヘッダーを無視する場合があり、WebSocketやWebRTCにも対応しません。クリック後や、実際の<a href>ではないJavaScriptナビゲーション後にしか表示されないコンテンツは、レンダリングで問題が起こりやすくなります。詳細はレンダリングの記事で扱います。

バイト上限

Googlebotは、1つのURLから無制限にダウンロードするわけではありません。Googleが2026年3月に公開したInside Googlebotの更新時点では、HTTPヘッダーを含む各URLの先頭約2 MB、PDFは最大64 MBを取得します。この数値は変わり得ます。Google自身が “this limit is not set in stone and may change over time as the web evolves and HTML pages grow in size,” (翻訳)「この上限は固定されたものではなく、ウェブの進化やHTMLページの大型化に伴って変わる可能性があります。」 と説明しており、以前の文書には15 MBと記載されていましたが、それは検索固有ではなく、より広い基盤の既定値でした。実務上の要点は変わりません。上限を超えた部分は取得されず、Googlebotにとって “to Googlebot, they simply don’t exist.” (翻訳)「Googlebotにとって、その部分は存在しません。」 となります。重要なコンテンツとマークアップは肥大化した部分より前に置いてください。

失敗例：canonicalは存在するが、Googlebotへ届かない

2,4 MBのHTMLを返す商品テンプレートを想定します。アプリケーションが巨大な商品状態オブジェクトと推薦用ペイロードを文書の先頭近くへ出力し、canonical、商品説明、構造化データ、関連商品リンクは約2 180 000バイト目まで現れません。ブラウザーはレスポンス全体をダウンロードするので、ソース表示では正しく見えます。しかし、Googlebot Searchは文書化された約2 MBの上限付近で停止するため、後方のシグナルは取得したリソースに存在しません。

レンダリング後のDOMだけでなく、レスポンスをバイト順に診断します。

curl -sS -D response-headers.txt -o page.html https://example.com/product
wc -c response-headers.txt page.html
LC_ALL=C grep -abo 'rel="canonical"' page.html
LC_ALL=C grep -abo 'application/ld+json' page.html

ローカルで測ったバイト数は、配信中継やレスポンス処理の違いがあるため概算です。それでも、重要なシグナルが十分に前方にあるか、上限付近または上限後にあるかという最初の問いには答えられます。修正方法は、巨大なインラインデータを削除または遅延し、重要なメタデータ、主要コンテンツ、クロール可能なリンクを早い位置へ出力することです。同じ肥大化部分を移動し、上限が変わることを期待する方法ではありません。

Googlebotが負荷を抑えて取得する仕組み

  • クロールレートはアルゴリズムで決まり、自動的に調整されます。 “For most sites, Googlebot shouldn’t access your site more than once every few seconds on average.” (翻訳)「大半のサイトでは、Googlebotのアクセス頻度は平均して数秒に1回を超えないはずです。」 サーバーの状態に応じて速度を上げたり下げたりします。
  • ステータスコードが調整手段です。 429、500、503を返すとGooglebotは速度を落としますが、エラーになったURLだけでなくホスト名全体へ影響します。効果は1～2日程度で、エラーが続くとページがインデックスから外れ始めます。John Muellerは、“I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts,” (翻訳)「429、500、503、タイムアウトを返している場合にだけ、クロールレートがそれほど速く反応すると考えます。」 また “404s are generally fine & once discovered, Googlebot will retry them anyway.” (翻訳)「見つからないページは通常問題なく、一度発見されればGooglebotはいずれ再試行します。」 と述べています。
  • crawl-delayは無視されます。 Googleは非標準のcrawl-delayディレクティブを処理しません。Bingは対応しており、GooglebotとBingbotの実際の違いの1つです。
  • クロールは一定の割り当てではなく、クロール需要に従います。 サーバーが処理できる容量と、人気度・更新の古さによる需要で決まります。大半のサイトでは問題にならず、大規模サイトで重要になります。詳しくはクロールバジェットで扱います。

本物のGooglebotか確認する

ユーザーエージェントヘッダーは “often spoofed by other crawlers” (翻訳)「他のクローラーに偽装されることが多い」 ため、それだけでは証拠になりません。Googleのクローラーは、ユーザーエージェントヘッダー、送信元IP、そのIPの逆引きDNSホスト名という3つで識別できます。実用的な検証方法は2つあります。

  1. 手動（単発）。 送信元IPを逆引きし、ホスト名がgooglebot.com、google.com、googleusercontent.comのいずれかで終わることを確認します（crawl-***-***-***-***.googlebot.comのような形式です）。次にそのホスト名を正引きし、元のIPへ戻ることを確認します。
  2. 自動（大規模）。 IPをGoogleが公開するCIDR範囲と照合します。Googleは従来の単一googlebot.jsonをクローラー分類別の複数JSONへ分割しました。Googlebot用はhttps://www.gstatic.com/ipranges/common-crawlers.jsonです。旧googlebot.jsonのURLも同じデータへリダイレクトされます。

macOS／LinuxとWindowsの手順はScriptsタブにあります。検証が必要なのは、Googlebotを名乗るトラフィックが多く、ログ上の「Googlebot」の相当部分が偽物である可能性があるためです。信頼する前に確認してください。

Googlebotは大規模なボット群の1つ

「Googlebot」という呼び方は、実際には少し誤解を招きます。Gary Illyesは2026年3月に、“I mean, calling it Googlebot, that’s a misnomer,” (翻訳)「Googlebotと呼ぶのは、実際には誤った呼び方です。」、“Googlebot is not our crawler infrastructure.” (翻訳)「GooglebotはGoogleのクローラー基盤そのものではありません。」 と述べました。その下の基盤は、本人の表現では “software as a service, if you like. SaaS” (翻訳)「言うなればSoftware as a Service、SaaSです。」 で、多くのGoogle製品が利用する共有プラットフォームです。ログに見えるのは検索向けの部分であり、“When you see Googlebot in your server logs, you are just looking at Google Search.” (翻訳)「サーバーログでGooglebotを見ているとき、見ているのはGoogle検索の部分だけです。」 と説明しています。また、文書化するほど大きくないものを含め、“dozens, if not hundreds of different crawlers,” (翻訳)「数十、場合によっては数百の異なるクローラー」 があるとも述べています。

Googlebotとともにログで見かける名前付きクローラーには、Googlebotの文字列／トークンを共有するGooglebot-Image、Googlebot-Video、Googlebot-News、Storebot-Google、URL InspectionとRich Resultsツールを動かすGoogle-InspectionToolがあります。特殊な動作をするものもあります。AdsBotはrobots.txtの全体向け*ルールを無視するため、User-agent: *の下にDisallow: /を書いても停止しません。Google-Safetyはrobots.txt自体を無視します。AI関連では、Geminiの学習を制御しランキングシグナルではないGoogle-Extendedと、Googlebotから分離された研究開発用のGoogleOtherもあります。詳しくはAIクローラーの記事で扱います。

Googlebotを制御する方法

3つの制御手段には、それぞれ異なる効果があります。

  • **robots.txt**はクロールを止めますが、インデックス登録は止めません。価値の低いURL領域へボットを入れないために使い、インデックス削除には使わないでください。
  • **noindex**はインデックス登録を止めます。ただし、Googlebotがタグを読むには、最初にページをクロールできる必要があります。
  • パスワード保護はアクセス自体を遮断します。

ここで最も誤解される事実につながります。“There’s a difference between crawling and indexing; blocking Googlebot from crawling a page doesn’t prevent the URL of the page from appearing in search results.” (翻訳)「クロールとインデックス登録は異なります。Googlebotによるページのクロールをブロックしても、そのページのURLが検索結果へ表示されることは防げません。」 robots.txtでブロックされたURLでも、どこかからリンクされていれば、URLだけがインデックス登録される場合があります。実際にページを削除するには、クロールを許可してnoindexを追加します。 詳細は*Indexed, though blocked by robots.txt* で解説しています。

Googlebotが含まれるより広いパイプライン、つまりURL発見、クロールスケジューラー、レンダリング、クロール・インデックス登録・ランキングの違いについては、クロールのハブと検索の仕組みをご覧ください。

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。