大規模サイトを運営していて「新しいページがなかなか検索結果に反映されない」「一部のページだけインデックスされない」という問題に直面することがあります。原因のひとつがクロールバジェットの不足です。
クロールバジェットとは、Googlebotがあるサイトに対して一定期間内にクロール（巡回・情報収集）できるURLの上限枠を指します。Google公式ドキュメントでは「Googleがクロール可能であり、かつクロールを希望するURLの集合」（the set of URLs that Google can and wants to crawl）と定義しています。
出典: Google検索セントラル「大規模サイトのクロール バジェット管理」
ただし注意すべき点として、Google自体は「クロールバジェット」という用語を正式には採用していません。2017年1月の公式ブログでは「クロールの割り当てが表すあらゆるものを一言で説明できるような言葉はない」と明言されています。SEO業界で慣例的に使われている概念であり、Googleが内部的に管理しているクロールのリソース配分を便宜的に呼んだものです。
クロールバジェットを決定する2つの要素
Googlebotのクロール上限は、 クロール容量の上限（Crawl Capacity Limit） と クロール需要（Crawl Demand） の2つの要素で決まります。
クロール容量の上限（Crawl Capacity Limit）
Googlebotが特定のサイトに同時接続できる数の上限です。サーバーに過度な負荷をかけないよう、Google側が自動的に調整しています。
以下の要因によって変動します。
| 影響要因 | 容量が増加する場合 | 容量が減少する場合 |
|---|---|---|
| サーバー応答速度 | レスポンスが高速・安定 | レスポンスが遅い・タイムアウト多発 |
| サーバーエラー | 5xx系エラーが少ない | 5xx系エラーが頻発 |
| Google側リソース | 十分なクローラーリソースがある | クローラーリソースが逼迫 |
クロール需要（Crawl Demand）
Googleがそのサイトを「どれだけクロールしたいか」という必要性の度合いです。次の3点が需要を左右します。
- 認知済みURL数（Perceived inventory）: Googleが把握しているサイト内のURL総数。多いほどクロール需要は高まります
- 人気度: 外部リンクやアクセス数が多いURLほど頻繁にクロールされます
- 鮮度（Staleness）: コンテンツの更新頻度が高いサイトはクロール需要が上がります
つまり、サーバーが高速で安定しているほどクロール容量は拡大し、人気が高く更新頻度も高いサイトほどクロール需要も高まる構造です。
クロールバジェットの影響を受けるサイト・受けないサイト
すべてのサイトがクロールバジェットを意識する必要があるわけではありません。Google公式ドキュメントによると、クロールバジェット管理が特に必要なのは以下のケースです。
クロールバジェットを気にすべきサイト:
- ページ数が100万を超える大規模サイト（ECサイト、求人サイト、不動産ポータルなど）
- 1万ページ以上で毎日コンテンツが更新される中規模サイト（ニュースサイト、メディアなど）
- URLパラメータで大量の重複ページが生成されるサイト
- Google Search Consoleの「検出 - インデックス未登録」が多数報告されているサイト
クロールバジェットを気にしなくてよいサイト:
- ページ数が数千以下の小規模サイト
- 新しいページが公開当日にクロールされているサイト
- コンテンツ更新頻度が低い企業サイトやブログ
Google公式ガイドにおいても、対象読者は「100万ページ以上の大規模サイト」または「1万ページ以上で毎日更新がある中規模サイト」で、インデックスの遅延問題が発生しているケースとされています。
出典: Google検索セントラル「大規模サイトのクロール バジェット管理」
クロールバジェットを浪費する6つの要因
Googlebotが重要でないページのクロールにリソースを費やすと、本来クロールすべき価値の高いページへの巡回が後回しになります。Google公式ブログでは、以下のような低価値URLがクロールバジェットを浪費する要因として挙げられています。
1. ファセットナビゲーション（絞り込み検索）で生成される動的ページ
ECサイトで「価格」「ブランド」「カラー」などの絞り込み条件を組み合わせると、内容がほぼ同一の大量のURLが自動生成されます。これらのURLはそれぞれクロール対象になるため、クロールバジェットを著しく消費します。
2. URLパラメータによる重複コンテンツ
トラッキングパラメータやセッションIDがURLに付与されると、同一ページなのに異なるURLとして認識されます。?sort=price と ?sort=popularity のように、並び順を変えただけのページも別URLとして扱われます。
3. ソフト404エラー
存在しないページにアクセスした際に、HTTPステータスコード200（正常）を返してしまうケースです。Googlebotはこのページを正常なものとしてクロールし続けるため、リソースが無駄に消費されます。
4. 無限ループで生成されるページ
カレンダー機能やフィルター機能が、クリックのたびに新しいURLを生成し続ける構造です。Googlebotがこれらを延々とクロールし、有限のバジェットを使い果たすことがあります。
5. ハッキングされたページ
不正なページが大量に生成されると、それらもクロール対象になります。サイトのセキュリティ維持はクロールバジェットの観点からも重要です。
6. 低品質・スパムコンテンツ
自動生成された薄いコンテンツや、価値のないページが大量に存在すると、Googleはサイト全体のクロール優先度を下げる場合があります。
クロールバジェットを改善する8つの施策
施策1: robots.txtでクロール不要なパスをブロックする
クローラーに巡回させる必要がないディレクトリやパスは、robots.txtで明示的にブロックします。管理画面、検索結果ページ、カートなどが対象です。
User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /search?
Disallow: /*?sort=
Disallow: /*?session_id=
注意点: robots.txtでブロックしたURLはクロール自体が行われなくなりますが、他サイトからリンクされている場合はインデックスに残る可能性があります。インデックスから完全に除外したい場合はnoindexを使用してください。
施策2: 重複コンテンツをcanonicalタグで正規化する
同じ内容のページが複数URLで存在する場合、canonicalタグで正規URLを指定します。
<link rel="canonical" href="https://example.com/products/item-001" />
canonicalタグを設定することで、Googlebotが重複ページを繰り返しクロールする無駄を削減し、評価の分散も防ぎます。
施策3: 削除済みページには404または410を返す
廃止したページのURLが200（正常）を返し続けると、Googlebotはそのページを有効なものとしてクロールし続けます。完全に削除したページには適切なステータスコードを設定してください。
| ステータスコード | 意味 | 使い分け |
|---|---|---|
| 404 Not Found | ページが見つからない | 一般的な削除 |
| 410 Gone | ページが恒久的に消滅した | 意図的・永久に削除した場合 |
| 301 Redirect | 恒久的リダイレクト | 別URLに移行した場合 |
410を返すと、Googlebotは404よりも早くそのURLのクロールを停止する傾向があります。
施策4: XMLサイトマップを最新の状態に維持する
XMLサイトマップは、Googlebotにクロールすべき重要なURLを直接伝える手段です。次のポイントを押さえてください。
- 存在するページのみ記載する: 404ページやリダイレクト先のURLを含めない
- lastmodタグを正確に設定する: ページの実際の更新日を記載する（形式的に毎日更新する行為は逆効果）
- Google Search Consoleに送信する: サイトマップのインデックス状況を定期的に確認する
- サイトマップの分割: 50,000URL/50MBの上限があるため、大規模サイトではサイトマップインデックスで分割管理する
施策5: リダイレクトチェーンを解消する
URL A → URL B → URL C → URL D のようにリダイレクトが連鎖すると、Googlebotがゴールにたどり着くまでに複数回のリクエストを必要とし、クロールバジェットを消費します。
リダイレクトは最終URLへの直接リダイレクト（1ホップ）に修正してください。Google Search Consoleの「ページのインデックス登録」レポートで、リダイレクトに関する問題を確認できます。
施策6: ページの読み込み速度を改善する
サーバーのレスポンス速度が速いほど、Googlebotは同じ時間内により多くのページをクロールできます。結果として、クロール容量の上限が引き上げられます。
主な高速化の手法は次のとおりです。
- サーバーのTTFB（Time to First Byte）を200ms以下に最適化する
- 画像の圧縮・次世代フォーマット（WebP、AVIF）への変換
- CSSやJavaScriptの圧縮・遅延読み込み
- CDNの導入による地理的な配信最適化
- サーバーサイドキャッシュの適切な設定
施策7: 内部リンク構造を整理する
Googlebotはリンクを辿ってサイト内を巡回します。重要なページへのリンクが深い階層にしかないと、クロールされにくくなります。
- フラットな構造を目指す: トップページから3クリック以内で全ページに到達できるのが理想
- パンくずリストの設置: 階層構造をクローラーに明示する
- 孤立ページをなくす: どのページからもリンクされていないページ（オーファンページ）は発見自体されない
- 不要な内部リンクを整理: 削除済みページへのリンクや、重複ページへのリンクを除去する
施策8: noindexタグを適切に使う
検索結果には表示したくないが、サイト内では必要なページ（タグ一覧、アーカイブページなど）にはnoindexを設定します。
<meta name="robots" content="noindex, follow">
robots.txt、noindex、canonicalの使い分け:
| 手段 | クロール | インデックス | 主な用途 |
|---|---|---|---|
| robots.txt Disallow | ブロック | 他サイトからのリンクでインデックスされる場合あり | 管理画面・検索結果・パラメータ付きURL |
| noindex | される | ブロック | タグページ・アーカイブ・テスト環境 |
| canonical | される | 正規URLに集約 | 重複コンテンツの統合 |
この使い分けを誤ると、意図しないページがインデックスされたり、逆に重要なページがクロールされなくなったりするため、用途に応じて正しく選択することが重要です。
Google Search Consoleでクロール状況を把握する方法
クロールバジェットの最適化を進めるうえで、現状を数値で把握することが不可欠です。Google Search Console（GSC）では、以下のレポートを活用できます。
クロールの統計情報を確認する
GSCの「設定」→「クロールの統計情報」から、以下のデータを確認できます。
- クロールリクエストの合計数: 日別・週別のクロール数推移
- ダウンロードサイズ: Googlebotが取得したデータ量
- 平均応答時間: サーバーの応答速度
- レスポンスコード別の内訳: 200、301、404、5xxなどの割合
5xxエラーやタイムアウトが増加していると、クロール容量の上限が下がっている可能性があります。
各ページの最終クロール日を確認する
GSCの「URL検査」ツールに特定のURLを入力すると、「前回のクロール日時」が表示されます。重要なページのクロール頻度が低い場合は、内部リンクの見直しやサイトマップへの追加を検討してください。
「ページのインデックス登録」レポートを監視する
「インデックス作成」→「ページ」から、インデックスされていないページの理由別一覧を確認できます。「検出 - インデックス未登録」が大量に存在する場合、クロールバジェットが不足している兆候です。
クロールバジェットに関するよくある疑問
クロール頻度が上がると検索順位も上がりますか？
クロール頻度と検索順位には直接の因果関係はありません。Googleのジョン・ミューラー氏も「クロール頻度はランキング要素ではない」と明言しています。ただし、クロールバジェットの最適化を通じてサイト構造や表示速度を改善すること自体は、SEO評価の向上につながります。
nofollowリンクはクロールバジェットに影響しますか？
影響する場合があります。ある内部リンクにnofollowを設定しても、同じURLが別のページからnofollowなしでリンクされていれば、Googlebotはそのページをクロールします。リンク先URLへのクロールを確実に停止したい場合は、robots.txtで制御するのが確実です。
alternateURLや埋め込みリソースもバジェットに含まれますか？
含まれます。AMPページ、hreflangで指定した多言語版URL、CSSやJavaScriptなどの埋め込みコンテンツもすべてクロールバジェットの対象です。また、長いリダイレクトチェーンもバジェットに悪影響を与えます。
noindexページはクロールバジェットに影響しますか？
影響します。noindexタグはインデックス登録を防ぐ指示ですが、クロール自体は行われます。クロールバジェットへの影響を最小限にしたい場合は、robots.txtによるクロールブロックを検討してください。ただし、robots.txtでブロックするとnoindexの指示自体もGooglebotが読めなくなるため、すでにインデックスされているページには使えない点に注意が必要です。
クロール頻度を手動で調整できますか？
Google Search Consoleの旧バージョンにはクロール速度の設定がありましたが、現在は廃止されています。クロール頻度を上げたい場合は、サーバーの応答速度を改善する、コンテンツを定期的に更新する、サイトマップを最新にするなど、間接的な手段で対応することになります。
クロールバジェット診断チェックリスト
自サイトのクロールバジェットに問題がないか、以下の項目で簡易診断ができます。
- GSCの「検出 - インデックス未登録」が全URL数の10%を超えていないか
- 5xxサーバーエラーの発生率が1%未満か
- サーバーの平均応答時間が500ms以下か
- XMLサイトマップに404ページやリダイレクトURLが含まれていないか
- robots.txtで管理画面・検索結果ページ・パラメータURLをブロックしているか
- リダイレクトチェーン（2段階以上のリダイレクト）が存在しないか
- ソフト404エラーが報告されていないか
- 重複コンテンツにcanonicalタグが設定されているか
3つ以上の項目に該当する場合は、クロールバジェットの最適化に取り組むことでインデックス効率が改善する可能性があります。
まとめ
クロールバジェットは「クロール容量の上限」と「クロール需要」の2つの要素で構成されており、Googlebotが効率的にサイトを巡回するための仕組みです。ページ数が数千以下の小規模サイトではほとんど問題になりませんが、数万ページ以上の規模になると、クロールバジェットの管理がSEOの成果を左右します。
改善施策の中でも特に効果が大きいのは、robots.txtによる不要ページのブロック、重複コンテンツのcanonical統合、そしてXMLサイトマップの適切な管理です。Google Search Consoleのクロール統計情報を定期的にチェックし、エラー率の上昇やクロール頻度の低下がないか監視することが、安定したインデックスを維持する鍵になります。