Googleのクロールは2MBで止まる ── 最新の公式解説と、自分のサイトで確認する13項目

01 いま最新のクロール事情 — Googlebotは単一のプログラムではない

「Googlebot」という名前が指しているもの

2026年3月31日、Google Search Central Blogに「Inside Googlebot: demystifying crawling, fetching, and the bytes we process」という記事が公開されました。Search Off the Recordポッドキャストのエピソード105と連動した内容で、Googlebotの内部構造をこれまでになく具体的に説明しています。まず記事が最初に訂正しているのが、「Googlebot」という名前そのものへの誤解です。2000年代初頭、Googleが検索という単一のプロダクトしか持っていなかった頃は、クローラーもひとつでした。その頃の名残で「Googlebot」という呼び方が定着していますが、現在のGooglebotは、中央集権的なクローリング基盤を利用する多数のクライアントのひとつにすぎません。

サーバーのアクセスログに「Googlebot」という表記を見つけたとき、それは実際にはGoogle検索が使っているクロール基盤へのアクセスを意味します。Google Shopping、AdSenseなど、他にも数十のクライアントが同じ基盤を経由してクロールリクエストを送っており、規模の大きいものはGoogleクローラー(User-Agent)の一覧ページにドキュメント化されています。クローラーは大きく「一般的なクローラー」と「特殊用途クローラー」の2種類に分かれ、前者はcommon-crawlers.jsonで公開されたIPレンジから、後者はspecial-crawlers.jsonのIPレンジから、それぞれアクセスしてきます。

2MBの壁 — バイト単位のフェッチ上限

この記事でもっとも実務的な情報は、フェッチできるバイト数の上限です。Googlebotは、PDFを除く個々のURLについて最大2MBまでしか取得しません。この2MBには、HTTPヘッダーも含まれます。PDFファイルだけは例外で、上限は64MBに引き上げられています。画像や動画のクローラーはしきい値の幅が広く、取得先の製品によって異なります。たとえばファビコンの取得はごく低いしきい値になる一方、画像検索向けの取得はそれよりも大きくなります。しきい値を明示していないその他のクローラーについては、コンテンツの種類を問わずデフォルトで15MBが適用されます。

上限を超えた部分に、実際は何が起きているか

公式記事は、上限に達した場合の挙動を4段階に分けて説明しています。まず部分的なフェッチです。HTMLファイルが2MBより大きい場合、Googlebotはページを拒否するのではなく、ちょうど2MBの位置でフェッチを打ち切ります。次に打ち切り部分の処理です。ダウンロードされた最初の2MBは、あたかも完全なファイルであるかのように、インデックスシステムとWeb Rendering Service(WRS)に渡されます。そして見えなくなるバイトです。2MBのしきい値を超えた後ろのバイトは完全に無視されます。フェッチもレンダリングもインデックス登録も行われません。最後に参照リソースの扱いです。HTML内で参照される各リソース(メディア・フォント・一部の特殊ファイルを除く)は、親のHTMLと同じようにWRSがGooglebotとしてフェッチしますが、それぞれ個別のバイトカウンターを持ち、親ページのサイズには加算されません。

レンダリングにも同じ上限がかかる

クローラーがバイト(上限まで)を取得し終えると、その内容はWRSに引き渡されます。WRSは最新のブラウザに近い形でJavaScriptを処理し、クライアントサイドのコードを実行して、ページの最終的な見た目とテキストの状態を理解しようとします。レンダリングの過程ではJavaScriptとCSSファイルを取得・実行し、XHRリクエストも処理してページの構造を把握しますが、画像や動画そのものはリクエストしません。ここで取得する各リソースにも、同じ2MBの上限が個別に適用されます。ただし、WRSが実行できるのはクローラーが実際に取得できたコードだけです。さらにWRSはステートレスに動作し、リクエストのたびにローカルストレージとセッションデータをクリアします。動的でJavaScript依存の要素が、この特性によって想定と違う形で解釈される可能性がある点は、実装側が覚えておくべきポイントです。

02 なぜ、こう動くのか — クロール容量制限とクロール需要

クロール容量制限とは何か

「クロールバジェット」という言葉は、公式ガイドでは「Googleがクロール可能かつクロールしたいと考えるURL群」と定義されています。これは2つの独立した要素の掛け合わせで決まります。ひとつめがクロール容量制限(Crawl Capacity Limit)です。これはサーバー接続を保持する総時間量を制限する仕組みで、Googleは並列接続の数と接続にかかる時間を考慮しながら、サイトに過負荷をかけないよう自動的に調整しています。サーバーの応答が遅くなったり、5xxエラーが増えたりすると、この制限が自動的に絞られ、結果としてクロール頻度が下がります。

クロール需要を決める4つの要因

もうひとつの要素がクロール需要(Crawl Demand)です。これは「Googleがそのサイトをクロールしたい」という欲求の強さを指し、クロールバジェット管理ガイドによれば以下の4つの要因で決まります。サイトの規模、更新頻度、ページの品質、そして他サイトと比較した相対的な関連性です。

なお同じガイドは、これとは別の枠で「運営者が影響を与えられる主な要因」として、認識されているURLの数、人気度、鮮度の3つを挙げています。この2つの列挙は別のものなので、混ぜて数えないほうがいい。前者はGoogle側が需要を測る軸であり、後者は運営側から動かせる軸です。なお、更新頻度を上げることは後者でいう鮮度にあたる、と整理できます（これは筆者の整理であって、公式ドキュメントが2つの列挙を対応づけているわけではありません）。この2つのうち、運営側の努力で直接 変えられるのは後者であり、逆に言えばここが弱いサイトほど、そもそもクロール需要そのものが低い状態にあります。

どのサイトがクロールバジェットを気にすべきか

クロールバジェット管理ガイドは、すべてのサイト向けの内容ではなく、上級者向けのガイドだと明記しています。対象になるのは、ページ数が100万以上で週に1回程度の頻度でコンテンツが変わる大規模サイト、ページ数が1万以上で日次更新があるサイト、あるいはSearch Consoleの「ページのインデックス登録」レポートで「検出 — インデックス未登録」の割合が大部分を占めているサイトです。この基準に当てはまらない中小規模のサイトにとって、クロールバジェットそのものはボトルネックになりにくいというのが公式の立場です。中小規模のサイトで表示が遅い、クロールされないという場合、多くはクロールバジェットではなく、次章で扱う別の原因が関わっています。

ページの複雑化と、クロールにかかる時間の変化

クロールにかかる時間そのものも変化しています。Googleが公開している解説によれば、モバイルページのサイズ中央値は0.8MBから2.3MBへと増加し、平均的なページは60以上の異なるファイルを読み込むようになりました。ページが複雑になるほど、Googlebotが1ページを完全に把握するまでに必要なリクエストの回数は増えます。01章で見た2MBのバイト上限が実務上効いてくる場面が増えているのは、こうしたページの重量化と無関係ではありません。

クロールは自動的に最適化されている

クロール頻度の調整は、人手ではなくシステムによって自動的に行われています。公式の解説によれば、サイトの応答速度が落ちた場合、Googleのシステムは自動的にクロール率を調整して負荷を抑えます。また、キャッシュを活用することで無駄なクロールを制限し、カレンダーページのように全件をクロールする必要のないパターンについても、システム側が認識して調整を行っているとされています。運営側が個別にクロール頻度を細かく指定する仕組みではなく、サーバーの状態とコンテンツの性質から、Google側が継続的に最適化しているという理解が実態に近いです。

ログイン後のコンテンツやペイウォールについても触れておきます。Googlebotは既定では許可なくペイウォールやサブスクリプション限定のコンテンツにはアクセスしません。有料会員向けコンテンツを検索結果に反映させたい場合は、構造化データを使って「ここから先は限定コンテンツである」ことを明示し、訪問者にはログイン画面を見せながら対応する仕組みが用意されています。無料公開のつもりが実装上ペイウォール扱いになっている、あるいはその逆といった食い違いは、意図せずクロールを妨げる原因になり得ます。

03 この記事で出てくる用語

本文で繰り返し使う用語を、先に整理しておきます。

クロールの目的を示す2つの分類 — DiscoveryとRefresh

Search Consoleのクロール統計情報レポートでは、個々のクロールが「Discovery(新規発見)」なのか「Refresh(既知ページの再クロール)」なのかを分類して確認できます。まだ一度もクロールされていないURLへのアクセスがDiscovery、既にインデックスされているURLへの再訪問がRefreshです。頻繁に更新されるページはサイトマップに含めることで、Discoveryのクロールを呼び込みやすくなります。

robots.txtとcanonicalは別の道具である

robots.txtはクロールそのものを制御する道具であり、canonicalタグは複数の類似URLのうち、どれを代表として扱うかをインデックス側に伝える道具です。両者は目的が異なるため、重複ページを統合したい場合はcanonical、そもそも見せたくないURL群のクロールを避けたい場合はrobots.txt、という使い分けが基本になります。robots.txtでブロックしたURLはクロールされなくなりますが、後述するとおりインデックスから除外されることを保証するものではありません。

soft 404という見えない障害

ページ自体は正常なHTTP 200を返しているのに、内容が「見つかりません」というエラーメッセージだけで構成されているケースを、Googleはsoft 404として扱います。ステータスコード上は成功しているため、サーバーログだけを見ていては気づきにくく、Search Consoleの「ページのインデックス登録」レポートで初めて発覚することが多い障害です。

04 クロールされない・遅い、主な原因の分類

サーバー側の問題 — 応答速度とホストステータス

02章で見た通り、Googleはサーバーへの負荷を避けるため、応答が遅い・エラーが多いサイトに対して自動的にクロール容量制限を絞ります。Search Consoleのクロール統計情報レポートにあるホストステータスは、この状態を3段階(良好・過去1週間以上前に問題発生・最近1週間以内に問題発生)で示し、robots.txt取得の失敗率、DNS解決エラー、サーバー接続エラーの内訳を確認できます。ここが「問題あり」の状態のまま放置されていると、いくらコンテンツを増やしても新規クロールの絶対量が増えません。

robots.txtによるブロック — 意図的な場合とそうでない場合

robots.txtで意図的にブロックしている領域(管理画面・内部検索結果ページなど)であれば問題ありませんが、CMSの初期設定や過去の作業の残骸で、公開したいページまで巻き込んでブロックしてしまっているケースは珍しくありません。robots.txtの公式ガイドは、これがウェブページを検索結果から隠すための仕組みではないと明記しています。ブロックしたつもりのページが、他サイトからのリンクを通じてインデックスされてしまう可能性がある一方で、公開したいページを誤ってブロックしてしまえば、そちらは確実にクロールされなくなります。

クロールバジェット不足 — 大規模サイト特有の制約

02章の基準(ページ数100万以上・週次更新、あるいは1万以上・日次更新)に当てはまる規模のサイトでは、クロールバジェットそのものが不足し、更新したページになかなかクロールが回ってこないという事態が起こり得ます。この場合の対処は、コンテンツを増やすことではなく、重複コンテンツの統合、低品質な自動生成ページの整理、リダイレクトチェーンの解消など、クロールの「ムダ」を減らす方向の作業が中心になります。

URLインベントリの問題 — 重複・soft 404・リダイレクトチェーン

クロールバジェット管理ガイドが繰り返し強調しているのが、URLインベントリの管理です。重複コンテンツはcanonicalやリダイレクトで統合し、削除したページには一時的な302ではなく恒久的な404または410のステータスコードを明確に返すこと、そしてリダイレクトチェーンを可能な限り1段で完結させることが推奨されています。連続する複数回のリダイレクトは、それぞれの段でクロールリソースを消費し、最終到達までの時間も延びます。

原因の分類	典型的な兆候	確認する場所
サーバー側 応答遅延・エラー	クロール頻度が突然下がる	クロール統計情報レポートのホストステータス
robots.txt 意図しないブロック	特定パス配下だけクロールされない	robots.txtの目視確認・URL検査ツール
クロールバジェット 大規模サイト特有	更新後もインデックスの反映が遅い	「検出 — インデックス未登録」の件数
URLインベントリ 重複・soft404	似たページが大量にクロールされている	ページのインデックス登録レポート

05 自分のサイトで確認するチェックリスト

チェックリストの3つの観点

ここまでの内容を、公開済みのページに対して今日から確認できる動作に翻訳しました。観点は大きく3つに分かれます。ひとつはサーバーとGoogle側の疎通状況の確認、ふたつめはアクセスしてきているクローラーが本物かどうかの検証、みっつめはクロールを妨げている設定が残っていないかの確認です。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• Search Consoleの「URL検査」ツールを開き、対象URLの最終クロール日時とインデックス登録状況を確認する
• Search Consoleの「クロール統計情報」レポートで、直近90日間の総リクエスト数の推移グラフを確認する
• 同レポートのホストステータスで、robots.txt取得の失敗率・DNS解決エラー・サーバー接続エラーが「良好」表示になっているか確認する
• レスポンス別の内訳を開き、5xxエラーの割合を書き出す
• サーバーのアクセスログから直近7日分を開き、User-Agentに「Googlebot」を含む行を抽出する
• 抽出したアクセス元IPアドレスを3件選び、コマンドラインで逆引きDNSを実行し、ドメイン名がGooglebot.com・google.com・googleusercontent.comのいずれかで終わっているか確認する
• 逆引きで得たドメイン名を今度は正引きDNSにかけ、結果が元のIPアドレスと一致するか確認する
• robots.txtファイルを開き、公開したいディレクトリを意図せずDisallowしている行がないか確認する
• sitemap.xmlに掲載されているURLの件数と、Search Console上のインデックス登録済みページ数を突き合わせる（🔧 sitemap.xml作成ツールで最新のURL一覧を出力できる）
• 「ページのインデックス登録」レポートで「検出 — インデックス未登録」の件数を控える
• サイト内の主要な内部リンクを3本辿り、リダイレクトが2回以上連続していないか確認する（🔧 リンク漏れ・チェックツールでまとめて確認できる）
• 重要なページのHTMLをブラウザの開発者ツールで開き、title・canonicalタグ・構造化データが文書の先頭付近に配置されているか確認する
• クロールバジェットの対象基準(ページ数100万以上・週次更新、または1万以上・日次更新)に自サイトが該当するかどうかを判定する

13項目の内訳と、かかる時間の目安

最初の4項目はサーバーとGoogle側の疎通状況、5番目から7番目はアクセス元の正当性検証、8番目から10番目はクロールを妨げる設定の有無、11番目・12番目はページ側の構造、13番目は自サイトの規模感の把握に対応しています。特に6番目・7番目の逆引きDNS検証は、User-Agentの文字列だけではなりすましと本物のGooglebotを区別できないという公式の注意点に直接対応する項目です。すべてを一度に終える必要はなく、まずは主要なページを1本選んで上から順に手を動かしてみることを想定しています。13項目すべてに目を通すのにかかる時間の目安は、1本あたり20〜30分程度です。

06 クロール状況を確認する4つの方法

4つの方法の使い分け

クロールされているかどうかを確認する手段はひとつではありません。それぞれ確認できる範囲と、確認にかかる手間が異なります。以下は、05章のチェックリストで使った4つの方法を、確認できることと確認できないことで整理した表です。

方法	確認できること	確認できないこと
URL検査ツール	個別URLのインデックス状況・最終クロール日時・ライブテスト結果	サイト全体の傾向・過去のクロール推移
クロール統計情報 レポート	サイト全体の総リクエスト数・応答時間・ホストステータス・直近90日の推移	個別URLがいつクロールされたか
サーバーログの 逆引き検証	アクセスしてきたクローラーが本物のGooglebotかどうか	クロールされなかったURLの理由
robots.txt テスター	特定のURLパターンがルール上ブロックされているか	実際にクロールされているかどうか

それぞれの方法が測っていないこと

この4つを組み合わせても、埋まらない空白があります。robots.txtテスターは「ブロックされていない」ことしか確認できず、クロール統計情報レポートは「サイト全体でどれだけリクエストが来たか」までしか分からず、個々のページの中身までは踏み込みません。実際に対象ページがクロールされ、内容が正しく理解されたかを最終的に確認できるのは、URL検査ツールのライブテスト機能だけです。

07 当サイトでの確認方法

逆引きDNS検証は、特別な作業ではない

当サイトでも、05章・06章で紹介した公式の逆引きDNS検証の手順を、実際のアクセスログに対して定期的に実施しています。公式ドキュメントが示している4ステップ(逆引きDNS検索・ドメイン確認・正引きDNS検索・IPアドレスの一致確認)をそのまま実行しているだけで、特別なツールを使っているわけではありません。この手順自体が本記事の05章のチェックリストにそのまま入っているのは、当サイトで日常的に行っている確認作業を、そのまま読者が使える形に翻訳したためです。

08 このテーマの、これまで

再クロール待ちを記録した回

以前、公式に「最長2週間」とされている再クロール待ち行列の実態を、当サイトの実件数とともに記録したことがあります(archives/108)。「待つ」という受け身の状態を、サイトマップの更新やインデックス登録リクエストを使って能動的な行動に変えるという内容で、本記事の05章・06章で扱ったクロール統計情報レポートの読み方とも直接つながっています。

Search Consoleを読む力について書いた回

Search Consoleの各種レポートをどう読み解くかについても、以前にまとめて記録しています(archives/16)。データを眺めるだけでなく、そこから次の一手を判断する材料としてどう使うかを扱った内容で、本記事のチェックリストが前提としている読み方の基礎になっています。

curlで整合性を確認する手順を書いた回

sitemap・canonical・内部リンク・URLの末尾スラッシュという4つの整合性を、curlコマンド3行で確認する手順を記録した回もあります(archives/39)。本記事の05章で「meta情報がHTMLの先頭付近に配置されているか確認する」という項目を挙げていますが、こうした構造面の確認は、この回で扱った整合性チェックの延長線上にあります。