クロールバジェットとは、Googleのクローラーが1つのサイトについて「どのURLを、どれくらいクロールでき、クロールしたいか」を考えるための概念です。
ただし、すべてのサイトで重要になるものではありません。Googleの現行ガイドでは、主に非常に大規模なサイト、更新頻度が高いサイト、「検出-インデックス未登録」が大量にあるサイトを対象にした高度なSEOテーマとして扱われています。
30秒でわかる結論
- クロールバジェットは、Googleが「クロールできる量」と「クロールしたい量」で決まる
- Googleは「クロール能力の上限」と「クロール需要」の2要素で説明している
- 100万URL以上で週1回程度更新する大規模サイトは重要度が高い
- 1万URL以上で毎日更新するサイトも確認価値が高い
- 「検出-インデックス未登録」が大量にあるサイトも対象になりやすい
- 一般的な数十~数百ページのブログ・会社サイトでは通常気にしすぎなくてよい
- 重複URL・絞り込みURL・無限カレンダーなどが大量発生するとクロール効率が落ちやすい
- XMLサイトマップ、404/410、robots.txt、URL設計を目的に応じて使い分ける
- クロールされたからといって必ずインデックスされるわけではない
クロールバジェットとは?
クロールバジェットは、検索エンジンが1つのサイトに使うクロール資源を説明するときに使われる言葉です。
Googleは現在、サイトのクロールバジェットを「Googleがクロールでき、クロールしたいURLの集合」として説明しています。
初心者向けに一言でいうと
クロールバジェットは、Googlebotが限られた時間・処理能力の中で、サイト内のどこをどれだけ見に来るかを考えるための概念です。
Web上には膨大なURLが存在するため、GoogleがすべてのURLを常に同じ頻度でクロールすることはできません。そのため、サイトごとにクロールの量や優先度が変わります。
クロールバジェットを決める2つの要素
Googleは、クロールバジェットを主に次の2要素で説明しています。
| 要素 | 意味 |
|---|---|
| クロール能力の上限 | サーバーへ負荷をかけずにクロールできる量 |
| クロール需要 | GoogleがそのURLをどれくらいクロールしたいか |
クロールバジェット = クロール能力の上限 + クロール需要を踏まえた実際のクロール範囲
「サーバーが耐えられるから大量クロールされる」「ページ数が多いから必ず大量クロールされる」という単純な仕組みではありません。
クロール能力の上限とは?
Googleは、サイトへ過度な負荷をかけないようクロール量を調整しています。
Googleの現行ガイドでは、この上限はサーバーの応答状況などを見ながら自動的に調整されます。
上限に影響する主な要素
- サーバーの応答速度
- TTFBやレイテンシ
- 5xxサーバーエラー
- 429 Too Many Requests
- Google側の利用可能なクロール資源
サーバーが安定して速く応答できれば、Googleがより多くクロールできる可能性があります。反対に、応答が遅くなったり5xxが増えたりすると、Googleはクロール量を減らします。
速いサーバーにすれば無限に増えるわけではない
クロール量はサーバー能力だけでなく、Google側のクロール需要にも左右されます。サーバーを高速化しただけで、重要でないURLまで大量にクロールされるとは限りません。
クロール需要とは?
クロール需要は、Googleが「このURLをどれくらい確認したいか」を表す考え方です。
Googlebotでは、主に次のような要因が関係します。
- サイトの規模
- 更新頻度
- ページ品質
- 関連性
- URLの人気度
- ページの古さ・更新の必要性
Googleは、重複URLや重要でないURLが大量に存在すると、不要URLへクロール時間を使う可能性があると説明しています。
クロール需要のイメージ
毎日商品価格が変わるECページと、5年間変更されていない会社概要ページでは、再クロールの必要性は同じではありません。
どんなサイトでクロールバジェットが重要?
Googleの2026年版ガイドでは、主に次のサイトを対象にしています。
| サイト規模・状態 | 重要度 |
|---|---|
| 100万URL以上・週1回程度更新 | 高い |
| 1万URL以上・毎日更新 | 高い |
| 「検出-インデックス未登録」が大量 | 高い |
| 数十~数百ページの一般サイト | 通常は低い |
ここでの数値は、Google自身も厳密なしきい値ではなく大まかな目安としています。
小規模サイトは気にしすぎなくてよい
新しいページが公開後に通常どおりクロールされ、Search Consoleでも大きな問題がないなら、一般的なブログや会社サイトでクロールバジェット最適化を優先する必要は通常ありません。
クロールバジェットが問題になりやすいサイト例
大規模ECサイト
重要度:高い
商品、カテゴリ、色、サイズ、価格、並び替えなどでURLが大量発生しやすいため注意が必要です。
求人・不動産サイト
重要度:高い
地域・条件・駅・給与などの絞り込みURLが組み合わさり、URL数が膨らみやすいです。
ニュースサイト
重要度:高め
毎日大量に新規ページが増え、更新の鮮度も重要です。
会社サイト
重要度:低い
数十~数百URLなら、通常はXMLサイトマップと通常の内部リンク設計で十分です。
個人ブログ
重要度:低い
記事数が数百~数千程度で問題なくクロールされているなら、複雑な対策は不要です。
クロールバジェットを浪費しやすいURL
大規模サイトでは、検索に必要のないURLが大量に生成されるとクロール効率が下がる場合があります。
代表例
- 絞り込み・ファセットナビゲーションURL
- 並び替えだけが違うURL
- セッションID付きURL
- 無限に生成されるカレンダーURL
- 重複コンテンツURL
- soft 404ページ
- 長いリダイレクトチェーン
- 買い物かご・ログイン処理など検索不要のURL
Googleは、複雑なパラメータURLや絞り込み機能によって、似た内容のURLが大量生成される問題を明示的に注意しています。
例:100ページのサイトで10万URLが発生するケース
実際に価値のあるページが100URLしかなくても、並び替え・色・価格帯・日付などを組み合わせて10万URLが生成されることがあります。
単純化した例
必要なURL:100
自動生成されたURL:100,000
100 ÷ 100,000 × 100 = 0.1%
このようなサイトでは、検索に不要なURLのクロールへ時間が使われ、重要ページの発見や再クロールが遅れる可能性があります。
既存のrobots.txt記事でも同様に、無限カレンダーや並び替えURLはクロール制御の検討対象として扱われています。
改善1.不要URLを増やさない
クロールバジェット対策で最も重要なのは、不要URLを後から大量にブロックすることより、最初から無駄なURLを増やさない設計です。
見直す項目
- 絞り込み条件の組み合わせ
- 並び替えパラメータ
- セッションID
- 無限カレンダー
- 同じ内容を返す複数URL
- 不要な検索結果ページ
必要なURLだけを安定して生成できれば、Googlebotも重要ページへ集中しやすくなります。
改善2.重複URLを統合する
同じ内容へ複数URLでアクセスできる場合は、URL正規化を検討します。
代表的には、次の方法があります。
- 不要な重複URLを生成しない
- 301リダイレクトで統合する
- rel=”canonical”で正規URLを示す
- 内部リンクを正規URLへ統一する
canonicalだけで全部解決するわけではない
canonicalは正規URLを示すためのシグナルですが、Googlebotが重複URLへアクセスすること自体を完全に止める仕組みではありません。大規模サイトではURL生成そのものの見直しも重要です。
改善3.検索不要URLはrobots.txtを検討する
GoogleにクロールしてほしくないURLが大量にあり、サイト利用者には必要な場合は、robots.txtによるクロール制御を検討します。
たとえば、検索結果への掲載を狙わない並び替えURLや、一部の無限スペースなどが候補になります。
robots.txtとnoindexは目的が違う
robots.txtはクロール制御です。検索結果から削除する目的で使う仕組みではありません。検索結果への掲載を制御したい場合は、noindexなど別の方法を検討します。
Googleの現行ガイドでは、クロールしたくないURLをrobots.txtでブロックする一方、クロールバジェット節約目的でnoindexを使うことは推奨していません。noindexを確認するためにはGooglebotがページをクロールする必要があるためです。
改善4.削除済みURLは404または410を返す
完全に削除したページは、適切な404または410を返します。
Googleは、恒久的に削除されたURLへ404または410を返すことを、クロール効率改善の方法として案内しています。
soft 404を避ける
「ページはありません」と表示しているのにHTTP 200を返すsoft 404は、Googlebotが繰り返しクロールする原因になり得ます。存在しないページなら正しいHTTPステータスを返してください。
改善5.XMLサイトマップを最新にする
XMLサイトマップには、Googleにクロールしてほしい重要URLを掲載します。
Googleはサイトマップを定期的に確認するため、公開中の重要URLを正しく含め、削除済みURLや検索対象にしたくないURLを残さないことが重要です。
サイトマップの確認
- 公開中の正規URLだけを含める
- 404・410ページを残さない
- リダイレクトURLを残さない
- 更新日時を正確に管理する
- 必要ならlastmodを利用する
Googleは、更新コンテンツがある場合はXMLサイトマップのlastmodを正確に使うことも推奨しています。
改善6.長いリダイレクトチェーンを減らす
URL A → URL B → URL C → URL Dのように、何段階もリダイレクトが続くとクロール効率が落ちます。
改善例
変更前:A → B → C → D
改善後:A → D
サイト移転やURL変更を繰り返しているサイトでは、古い301設定が何段階にも積み重なっていないか確認します。
改善7.ページを効率よく読み込めるようにする
Googleは、ページの読み込み・レンダリングが速ければ、より効率的にクロールできる可能性があると説明しています。
確認すること
- サーバー応答時間
- 5xxエラー
- HTTP 429
- 重い画像・JavaScript
- キャッシュ
- レンダリング負荷
また、変更されていないページについてHTTPの304 Not Modifiedを適切に使える構成は、サーバー帯域や処理資源の節約につながります。
noindexでクロールバジェットを節約できる?
短期的なクロール制御としてnoindexを使うのは適切ではありません。
Googlebotはnoindexを確認するため、そのページ自体をクロールする必要があります。
使い分け
クロールさせたくない:robots.txtなどを検討
検索結果へ出したくない:noindexを検討
完全削除:404または410
ただし、robots.txtでブロックするとnoindexを読めない場合があるため、2つを無目的に重ねないでください。
クロールバジェットを増やす方法はある?
「Googleへ申請してクロールバジェットを増やす」という通常の設定はありません。
Googleの現行ガイドでは、クロール量を増やす方向として大きく次の2点を挙げています。
- サーバー能力がボトルネックなら、必要に応じてサーバー資源を増やす
- Googleが対象製品で価値を認識できる、高品質で独自性のあるコンテンツを提供する
「クロール回数を増やせば順位が上がる」ではない
クロール頻度そのものをSEO順位向上の目的にしないでください。Googleがクロールしても、品質・重複・需要などの理由でインデックスされないページはあります。
クロールとインデックスは別
クロールバジェットを理解するときは、クロールとインデックスを分けることが重要です。
Googlebotがページを取得します。
Googleも、クロールされたすべてのページがインデックスされるわけではないと明記しています。
重要
「クロール済みなのにインデックスされない」問題を、クロールバジェットだけで説明しないでください。ページ品質、重複、canonical、検索需要など別の要因も確認します。
Search Consoleで確認する方法
クロール状況はGoogle Search Consoleのクロール統計情報で確認できます。
主に次の情報を確認できます。
- クロールリクエスト数
- ダウンロードサイズ
- 平均応答時間
- レスポンスコード別の状況
- Googlebotの種類
- ホストの可用性
また、「ページのインデックス登録」レポートで「検出-インデックス未登録」が大量にないかも確認します。
見るべきなのは数字の多さだけではない
クロール回数が少ないから問題とは限りません。重要ページが適切な頻度でクロールされ、新規・更新ページが合理的な期間で発見されているかを確認します。
クロール頻度を意図的に下げる場面
通常はGoogleが自動調整するため、クロール頻度を手動で下げる必要はありません。
ただし、Googlebotのアクセスでサーバーが重大な負荷状態になるなど、例外的な場合は対処が必要です。
Googleの2026年10月版ガイドでは、緊急時に503 Service Unavailableや429 Too Many RequestsとRetry-Afterヘッダーを利用する方法が案内されています。
長期間続けない
Googleは503や429を1~2日を超えて長期間返し続けることを推奨していません。長く続くと、検索での表示に影響する可能性があります。
小規模WordPressサイトでやるべきこと
数十~数百記事程度の一般的なWordPressサイトなら、クロールバジェット専用の高度な対策は通常不要です。
まずこの5つで十分
- 重要ページを通常の内部リンクでつなぐ
- XMLサイトマップを送信する
- 不要な404・リンク切れを整理する
- 無限にURLが増える仕組みがないか確認する
- Search Consoleでインデックス状況を見る
複雑なrobots.txt対策を先にしない
小規模サイトでクロールバジェットを意識しすぎて重要ページをrobots.txtでブロックすると、かえって検索エンジンが内容を取得できなくなるリスクがあります。
教科書判定
一般的なブログ・会社サイトは気にしすぎなくてよい。大規模・高頻度更新サイトで重要
Googleの目安では、100万URL以上で週1回程度更新するサイト、1万URL以上で毎日更新するサイト、「検出-インデックス未登録」が大量にあるサイトでクロールバジェットを意識する価値があります。
数十~数百ページのWordPressサイトなら、まずXMLサイトマップ、内部リンク、正しい404、安定したサーバー応答を整えれば十分です。
大規模サイトでは、クロール回数を増やそうとするより、重複URL・絞り込みURL・無限URLを減らし、Googlebotが重要ページへ到達しやすいURL設計を優先してください。
FAQ
Q. 1000ページ程度でもクロールバジェット対策は必要ですか?
A. 通常は優先度が高くありません。新規・更新ページが合理的な期間でクロールされ、Search Consoleで大きな問題がなければ、複雑な専用対策は不要です。
Q. クロールバジェットが少ないと検索順位が下がりますか?
A. 単純にそうとは言えません。問題になるのは、重要な新規・更新ページが長期間クロールされない場合などです。順位はコンテンツ品質や関連性など多くの要素で決まります。
Q. noindexを付ければクロールバジェットを節約できますか?
A. 短期的なクロール制御には向きません。Googlebotはnoindexを確認するためページへアクセスします。クロール自体を不要にしたいURLでは、目的に応じてrobots.txtなどを検討します。
Q. サイトマップへURLを入れれば必ずクロールされますか?
A. いいえ。XMLサイトマップは重要URLをGoogleへ知らせる手段ですが、クロールやインデックスを保証するものではありません。
Q. クロール回数を増やす申請はできますか?
A. 通常の「クロールを増やす申請」はありません。サーバー能力が制約なら改善し、不要URLを減らし、重要で独自性のあるページをクロールしやすい構造にします。
まとめ
クロールバジェットは大規模サイト向けの高度なSEOテーマ
- クロールバジェットはGoogleがクロールでき、クロールしたいURLの範囲
- クロール能力の上限とクロール需要で決まる
- 100万URL以上・週次更新や1万URL以上・日次更新が目安
- 検出-インデックス未登録が大量にあるサイトも確認する
- 小規模ブログ・会社サイトでは通常気にしすぎなくてよい
- 絞り込み・重複・無限URLを増やさない
- 削除済みページは404または410を返す
- XMLサイトマップを最新に保つ
- robots.txt・noindex・canonicalを目的別に使い分ける
- クロールされても必ずインデックスされるわけではない
次に読む
「クロールとは?インデックスとの違いを解説」「インデックスとは?登録されない原因と対処法」「Googlebotとは?クロールの仕組みを初心者向けに解説」「パラメータURLとは?SEO上の注意点」もあわせて確認してください。