クロールバジェットとは？浪費の原因とGoogle推奨の最適化施策

「クロールバジェットが上限に達している」「インデックスされないページが増えている」などの課題は、大規模サイトやECサイトの運用担当者であれば、一度は直面したことがあるのではないでしょうか。

クロールバジェットは、Googleが1つのサイトに対して巡回に費やす時間とリソースの上限を指し、ここが浪費されると重要ページがいつまでも検索結果に反映されない原因になります。

この記事では、クロールバジェットの基本的な仕組みから、Googleが公式に推奨する最適化施策、そして2026年以降も注目されるLLMO（生成AI最適化）との関係まで、実務で押さえておくべきポイントを整理して解説します。

クロールバジェットの定義

「クロールバジェット（crawl budget）」とは、Googleが1つのWEBサイトに対してクロール（巡回）に費やす時間とリソースの容量を指す言葉です。

インターネット上には、ほぼ無限に近い数のWEBページが存在しています。
Google検索セントラル公式ガイドによると、Googleがすべての発見済みURLを調査してインデックスに登録する作業は、Google自身のクロール能力を超えてしまうと説明されています（※）。
だからこそ、サイトごとにクロールの上限、つまりバジェットが割り当てられているのです。

ここでまず整理しておきたい用語が、「クロール」「クローラー」「Googlebot」「インデックス」の4つです。

• クロール：GooglebotなどのクローラーがWEBページを発見し、内容を読み取る一連の動作を指す
• クローラー：巡回作業を自動で行うプログラムの総称
• Googlebot：Google検索の代表的なクローラー
• インデックス：クロールによって収集したWEBページの情報を検索結果としていつでも瞬時に引き出せるように整理・保存した「巨大なデータベース（索引）」のこと

クロールされたページがそのままインデックス（検索エンジンのデータベースへの登録）されるとは限らない点も重要です。
公式ガイドでも、クロールされた各ページは評価・統合・査定のプロセスを経てインデックス適合性が判断されると明記されています。

ただし、「クロールバジェット」の概念は、すべてのサイトが気にするべきものではありません。
公式ガイドが対象としているのは、主に次のようなサイトです。

• 重複のないページが100万以上あり、コンテンツが中程度の頻度（週1回程度）で更新される大規模サイト
• 重複のないページが1万以上あり、コンテンツがかなり頻繁に更新される中規模以上のサイト
• Google Search Consoleで大部分のURLが「検出 – インデックス未登録」に分類されているサイト

なお、これらの数値はサイトを分類する際の大まかな目安であり、正確なしきい値ではないと公式ガイドに明記されています。

個人ブログや数百ページ程度の中小規模サイトであれば、通常はクロールバジェットを意識する必要はありません。

サイトマップを最新の状態に保ち、定期的に「ページ」レポートでインデックスカバレッジを確認する程度で十分ですが、ECサイトのように商品ページが日々増減し、パラメータ付きURLも大量に生成されるようなサイトでは、このあと解説する浪費要因への対策が順位やカバレッジに直結するため、注意が必要です。

※参考：Google検索セントラル公式ガイド「クロール バジェットを最適化する」

クロールバジェットを構成する2つの要素

クロールバジェットは、以上の2つの要素のかけ合わせで決まります。

• クロール能力の上限
• クロールの必要性

これらの要素をふまえると、クロールバジェットを増やす方法は主に2つあります。

1つはサーバーリソースを増強してクロール能力の上限を引き上げること、もう1つは検索ユーザーにとってのコンテンツの価値・一意性を高めてクロールの必要性を高めることです。

これは公式ガイドが明言している唯一の方法であり、後述するような「robots.txtで一時的にバジェットを他のページへ再配分する」などの小手先のテクニックでは、恒久的にバジェットが増えることはない点に注意が必要でしょう。

クロール能力の上限

クロール能力の上限とは、Googleがサーバーに負荷をかけすぎないよう配慮したうえで、同時に使用できる接続数と、次回取得までの待機時間から算出される上限値です。
サイトがしばらく迅速に応答している状態が続けば上限は上がり、より多くの接続を使ってクロールが行われます。

反対に、応答が遅くなったりサーバーエラーが返されたりすると上限は下がり、クロール量は減少します。
Google側にもクロールに割けるマシンリソースの制約があるため、上限には天井があります。

クロールの必要性

クロールの必要性とは、そのサイトをどれだけクロールする価値・緊急性があるかなどの指標で、主に「検出されたURL群」「人気度」「古さ」の3要素で決まるとされています。

特に「検出されたURL群」は、サイト所有者がコントロールできる要素だと公式ガイドでは強調されています。
重複ページや削除済みページ、その他クロールされる必要のないURLが大量に存在すると、それだけクロールの時間が無駄になってしまうためです。

またサイト移転のような全体的なイベントが発生すると、新しいURL群を再処理する必要からクロールの必要性が一時的に高まることもあります。

クロールバジェットが「浪費」される主な要因

クロールバジェットが効率的に使われず浪費されるケースには、以下のようないくつかの典型的なパターンがあります。

• 低品質・重複コンテンツ
• パラメータ付きURL・ファセットナビゲーション
• 長いリダイレクトチェーン
• ソフトエラー（soft 404）
• サーバー負荷・動的ページのレンダリング負荷

クロールバジェットが浪費される原因を突き止めたうえで、適切な対策を講じましょう。

低品質・重複コンテンツ

内容がほぼ同じページや、ユーザーに価値を提供しない文字数の極端に少ないページが大量にある場合でも、Googlebotはそれぞれを「個別のURL」として認識し巡回してしまいます。

その結果、本来インデックスさせたい新着商品ページや重要なコラムページへのクロールが後回しになり、サイト全体の評価遅延を引き起こします。

パラメータ付きURL・ファセットナビゲーション

ECサイトなどで「色」「サイズ」「価格帯」「並び順」を複数組み合わせるファセットナビゲーションは、システム上、ほぼ無限に近いURLパターンを自動生成します。

また、アクセスするたびに付与されるセッションIDや、トラッキング用のパラメータを含むURLも同様です。
クローラーはこれらをすべて「新しいページ」と誤認して巡回し続けてしまうため、顕著なバジェット浪費要因となります。

長いリダイレクトチェーン

「A→B→C→D」とリダイレクトを複数回繰り返す（リダイレクトチェーン）設計は、Googlebotが最終的な移動先ページに到達するまでに複数回のHTTPリクエストを余分に消費させます。
公式ガイドでもクロールへの悪影響が名指しされており、途中で巡回を中断されてインデックス漏れにつながるリスクも高まります。

ソフトエラー（soft 404）

ページが削除済みや在庫切れで「実質的に中身が存在しない」にも関わらず、サーバーが「通常通りページが存在する」ことを意味する200番台のステータスコードを返してしまう状態を指します。
Googlebotはこの「存在しないページ」を有効なコンテンツと認識して定期的な再クロールを試み続けるため、無駄なリソース消費が慢性化します。

サーバー負荷・動的ページのレンダリング負荷

サーバーの応答速度が遅かったりエラーが頻発したりすると、Googleはサーバーをダウンさせないよう配慮してクロール接続数の上限を自動的に引き下げます。

また、JavaScriptを大量に用いて動的にコンテンツを描画（レンダリング）するページは、クローラー側の計算リソースと時間を多く消費します。
結果として、単位時間あたりに巡回できるページ数が減少し、バジェットを圧迫します。

これらはいずれも、サイト運営者が意図せず作り出してしまっているケースが多く、大規模サイトほど累積的な影響が大きくなります。

なお、明確に悪意のあるスパムコンテンツやハッキングによって大量の不正ページが生成されるケースも、同様にクロールバジェットを著しく浪費させる要因になります。
これは通常の運用改善とは切り分けて、セキュリティ対策として別途対応すべき領域です。

クロール状況の確認方法

自社サイトのクロール状況を把握するには、Google Search Consoleが基本のツールです。

「ページ」レポート（旧カバレッジレポート）では、「検出 – インデックス未登録」の件数を確認できます。
これは、GooglebotがURLの存在は認識しているものの、まだクロールが完了していないページを示す指標です。
似たステータスに「クロール済み – インデックス未登録（＝品質や重複問題による登録見送り）」がありますが、「検出」の場合はそもそもクロール自体が後回しにされている状態を指します。

この分類のURLが大部分を占めている場合は、クロールバジェットに課題を抱えている可能性のシグナルとされています。

また、「クロールの統計情報」レポートでは、ステータスコードの内訳（200、301、404、400番台など）や、ホストごとのクロールリクエスト数、平均応答時間の推移を確認できます。
404や410が急増している、あるいは応答時間が悪化傾向にある場合は、サーバー側の要因を優先して調査すべきタイミングです。

クロールバジェットを最適化する具体施策

ここからは、実際にクロールバジェットの浪費を防ぎ、最適化するための具体的な施策を解説します。

• robots.txtによる不要URLのブロック
• 重複URLの正規化
• 404/410ステータスコードとsoft 404の解消
• サイトマップの最新化
• リダイレクトチェーンの解消
• ページ表示速度・レンダリングの効率化

それぞれ解説していきます。

robots.txtによる不要URLのブロック

無限スクロールの一部や、内容が重複する並び替えページなど、ユーザーには価値があっても検索エンジンに再処理させる必要のないページは、robots.txtでブロックすることが有効です。
ただし注意点として、robots.txtは「クロールしてほしくないページを止める」ためのツールであり、あるページをブロックした分だけ他のページへバジェットが再配分されるとの考え方は誤りです。

公式ガイドも、Googleがすでにサイトの配信上限に達していない限り、空いたバジェットが自動的に他ページへ回されるわけではないと明言しています。

同様に、GooglebotはHTTPレスポンスを取得した時点でnoindexを確認するため、リクエスト自体は継続して発生します。したがって、noindexタグの使用もクロール時間の節約にはならない点に注意が必要です。

重複URLの正規化

パラメータ違いや大文字小文字違いなど、実質的に同じコンテンツを指すURLは、canonicalタグなどを使って正規化し、重複コンテンツを1つに統合するよう推奨されています。

ただし、canonicalタグはGooglebotが一度両方のURLをクロールし、ページ内容を見比べたうえで正規化を判断する仕様です。
設定したからといって、重複URLへのクロール自体が即座に止まるわけではありません。

クロールバジェットの浪費を直接防ぐには、サイト内のリンクURL表記を統一したり、不要なパラメータの生成処理を見直したりする根本的な対策もあわせて行うことが重要です。

404/410ステータスコードとsoft 404の解消

完全に削除したページには404または410を正しく返すことで、Googlebotに「今後このURLを再クロールする必要はない」というシグナルを送ることができます。

一方でsoft 404、つまり実質的には存在しないページなのに200を返してしまっているケースは、「ページのインデックス登録」レポート（旧カバレッジレポート）で定期的にチェックし、解消していく必要があるでしょう。

サイトマップの最新化

Googleへクロールしてほしいコンテンツはすべてサイトマップに含め、更新があったページには<lastmod>タグを付けることが推奨されています。
その際、 <lastmod>（最終更新日）の信頼性に注目しましょう。

ページの中身が変わっていないにも関わらず、日付だけを毎日自動更新するような実装を行うと、Googleからタグ自体を信用されなくなり無視されるようになると公式に警告されています。
設計の際は、「実際のコンテンツ変更がともなう場合のみ正確な日付を出力する」ことが重要です。

リダイレクトチェーンの解消

多重転送は、過去のサイトリニューアルや常時SSL化、URL正規化などの設定が年々積み重なることで、意図せず発生する傾向があります。

解消するには、サーバーの転送設定を見直し、開始URLから最終到達先へ1回で直接転送するよう書き換えることが重要です。
あわせて、サイトマップや内部リンクに古い転送元URLが残っていないか点検し、最新の正規URLへと差し替えましょう。

ページ表示速度・レンダリングの効率化

Googleがより高速にページを読み込み、レンダリングできるようになれば、同じ時間内でより多くのコンテンツを取得できる可能性が高まります。
これはサーバー応答速度の改善だけでなく、JavaScriptに依存した動的なレンダリング処理の軽量化も含まれます。

【2026年最新】LLMO時代におけるクロールの考え方

ここまで解説してきた「クロールバジェット」は、あくまでGoogle検索のクローラー（Googlebot）を対象とした概念です。

2026年に入り、GPTBot、ClaudeBot、PerplexityBotなどの生成AI事業者のクローラーがサイトへアクセスする機会が増加しています。
こうしたAIクローラーへの最適化を指す「LLMO（大規模言語モデル最適化）」の文脈でも、クロールと呼ばれる場面が増えています。

まず確定した事実として、Googleは2026年5月の公式発表で、AEOやGEOに関しても、Google検索の枠内で完結する話であればSEOの一部であり、独立した専門領域ではないとの見解を示しています。

その一方で、LLMOはChatGPTやClaudeのように独自のインデックスを構築する非Google系の生成AIも対象に含む点に注意が必要です。
業界内には、Google向けのSEO施策だけではカバーしきれない領域があるとの指摘も存在し、この点は情報源によって立場が分かれています。

また、robots.txtに加えて「llms.txt」など、AIクローラーに対して読み取ってほしい情報や要約の方針を伝えるための新しいファイルの実装が、一部の海外大手企業やSaaSベンダーを中心に広がりつつあります。

しかしこれはあくまで業界の一部で自主的に採用され始めている段階のものです。
Googleをはじめとする検索エンジンやAI事業者が公式な標準規格として採用を表明しているものではありません。
この点は現時点でわからない、確定していない部分として明確にしておく必要があるでしょう。

導入を検討する場合も、Google検索向けの正規のクロール最適化を優先したうえで、AIクローラー対応は補完的な施策と位置づけることが、現時点では妥当なスタンスだと考えられます。

クロールバジェット対策を「事業の成果」につなげるために

クロールバジェットは、主にページ数が数万〜数百万規模のECサイトや大規模サイトが向き合うべき技術的SEO課題です。

クロールバジェットは「クロール能力の上限」と「クロールの必要性」のかけ合わせで決まります。
クローラーの巡回回数や、一度に処理してもらえるページ数を増やす方法は、以下の2つに集約されます。

• サーバーリソースの増強（同時アクセス数や巡回スピードを増やす）
• コンテンツ価値の向上（クローラーが訪れる頻度を増やす）

日々の運用では、重複コンテンツやパラメータURL、リダイレクトチェーン、ソフトエラーなど「浪費」の芽を1つずつ潰していくことが、遠回りに見えて堅実な施策です。

加えて2026年以降はGoogle検索向けの土台を固めたうえで、LLMOによる新しい潮流にどう向き合うかも視野に入れておく必要があります。
これらの施策は技術的な正しさだけで完結するものではなく、「誰に、何を届けるためにクロールされる必要があるのか」を見据えた事業全体の設計と切り離せない部分です。

株式会社ハエモリ企画では、SEO・AIO・LLMO対策を、広告運用やインサイドセールスなど事業成長に関わる他の施策と切り離さずに一気通貫で支援しており、技術的なクロール改善を「順位が上がって終わり」にせず、事業の成果につながる形で設計・実行まで伴走しています。

自社サイトの技術的なSEO課題を、事業成長の文脈で根本から見直したい場合は、BtoB成長支援の専門家に相談してみるのも1つの選択肢です。

よくある質問