クロールバジェット対応が必要なサイトを先に判定する
Googleは、クロールバジェット管理を非常に大きいサイトや更新の速いサイト向けの高度なガイドとして位置付けています。次の条件は入口であり、一つだけ該当しても直ちに問題とは限りません。重要URLが適切な時期に取得されていない証拠まで確認します。
100万URL以上
固有URLが100万以上あり、内容が週1回程度の頻度で変わる大規模サイトは主な対象です。パラメータ違いを水増しして数えず、Googleが認識し得るURL在庫を確認します。
判断例例：大規模EC、求人、不動産、UGC
1万URL以上・日次更新
固有URLが1万以上で、在庫、価格、ニュース、イベントなどが毎日変わるサイトは、更新の発見と再取得の遅れを監視する価値があります。
判断例例：日次で商品状態が変わる一覧
検出済み・未登録が多い
Search Consoleの「検出 - インデックス未登録」が全URLの大きな割合を占める場合は対象候補です。ただし、品質、重複、canonical、レンダリングも切り分けます。
判断例例：重要カテゴリ配下に偏る
取得が必要時期に間に合わない
公開・重要更新からGooglebot取得までの遅れが業務上の許容時間を超える場合に調査します。通常サイトは公開当日の取得を前提にしません。
判断例例：時限情報が終了後に取得される
host availabilityに問題がある
Crawl Statsでホスト可用性の警告、5xx、DNS、接続、タイムアウトが見つかる場合は、URL整理より先に配信基盤を直します。
判断例例：Googlebot要求時に5xxが集中
重要URLだけ未クロール
サーバーログで重要URL群が取得されず、不要な並べ替え、絞り込み、重複URLへの要求が大量にある場合は、URL在庫管理を検討します。
判断例例：商品は未取得、filter URLは大量取得
クロールバジェットは「クロール能力」と「クロール需要」で決まる
Googleはクロールバジェットを、そのサイトでGoogleがクロールでき、かつクロールしたいURLの集合として説明しています。能力の上限に達していなくても需要が低ければ取得は増えません。サイトは基本的に固有hostname単位で扱われるため、`www.example.com`と`shop.example.com`は別に観察します。
クロール能力
並行接続数 × 接続時間 × サーバー応答
Googleがサーバーを過負荷にしない範囲です。host availability、応答時間、5xx、DNS、ネットワーク障害が制約になります。サーバー増強が有効なのは、実際に能力上限へ達している証拠がある場合です。
クロール需要
更新必要性・人気・品質・サイト変更
GoogleがURLを再取得したい度合いです。人気、全体的な利用価値、固有性、更新、サイト移転などが関係します。高速化だけで低価値URLの需要が増えるとは限りません。
認識URL在庫
canonical + 重複 + filter + sort + soft 404
Googleが知っているURLが対象です。重複、不要なパラメータ、無限空間、soft 404が増えると、重要URLより先に取得される可能性があります。制御しやすい主要因です。
HTTP応答
200 / 304 / 301 / 404 / 410 / 5xx
変更がなければ304を正しく返すと帯域と処理を節約できます。永久削除は404または410、移転は直接のリダイレクト、障害は5xxとして意味を保ちます。
発見経路
内部リンク + canonical URLのsitemap
サイトマップはクロールのヒントであり保証ではありません。検索結果に出したいcanonical URLを掲載し、重要更新だけ正確なlastmodを使い、クロール可能な内部リンクも維持します。
小規模・低頻度更新サイトの場合
公開後に妥当な期間でクロールされているなら、専用のクロールバジェット施策は不要です。最新サイトマップ、Page Indexingレポート、内部リンク、canonical、robots.txtの誤設定、コンテンツ品質を通常運用で確認します。「毎日クロールされない」ことだけを問題にしません。
症状、確認データ、最初の対応を対応付ける
Crawl Statsは要求総数、ダウンロード量、平均応答時間、レスポンスコード、ファイル種別、目的、Googlebot種別、ホスト状態とURL例を確認する集計です。特定URLの履歴を完全に追う用途ではないため、サーバーログと組み合わせます。クロール済みかとインデックス登録済みかも別に判定します。
| 症状 | 確認する証拠 | 最初の対応 |
|---|---|---|
| ホスト障害 | 5xx、DNS、接続、timeout、Hostload exceeded | Crawl Statsのhost availability、URL Inspection、監視、サーバーログを照合する。継続して能力上限へ達する場合だけ基盤増強を検討する。 |
| 重要URLが未取得 | 公開日時はあるがGooglebotログがない | 内部リンク、canonical、robots.txt、sitemap、HTTP状態を確認する。Page Indexingだけで取得時刻を推測せず、ログでURL群を追う。 |
| 不要URLへ集中 | filter、sort、session、重複、soft 404 | canonical統合、URL生成停止、内部リンク除去、適切なrobots.txt、404・410を役割に応じて使う。影響範囲を小さく試す。 |
| 取得済み・未登録 | ログに200、Page Indexingでは未登録 | コンテンツ品質、重複、canonical、レンダリング、index可否を調べる。取得済みならクロール回数の増加だけで解決しない。 |
Crawl StatsはURL台帳ではない
レポートはサイト全体の傾向と例示URLを確認するものです。ディレクトリ、テンプレート、特定URL群の取得日時と頻度は、検証済みGooglebotのサーバーログから集計します。
クロールとインデックスを分ける
クロールされても、評価、重複統合、品質判断を経てインデックスされない場合があります。順位や流入はさらに後段です。一つの指標で全工程を説明しません。
改善は、可用性と誤設定を先に、URL在庫の整理を次に行う
優先度は、重要URLを取得不能にする原因、サーバー障害、広範囲の誤ブロックから付けます。「クロール数が多いURLを全部止める」「404を全部リダイレクトする」「noindexを付ければ節約できる」といった一括変更は避けます。
先に直す
- 5xx、DNS、接続、タイムアウト、過負荷など、重要URLの取得を妨げる可用性問題。
- 重要URLのrobots.txt誤ブロック、誤canonical、誤noindex、壊れた内部リンク、sitemap漏れ。
- 無限に増えるfilter・sort・calendar・session URL、重複URL、soft 404、長いリダイレクトチェーン。
- 永久削除URLの正しい404・410、変更のないページへの304、canonical URLだけを含む正確なsitemap。
証拠なしで行わない
- 小規模サイトでクロール回数の増加をKPIにし、毎日取得されないことを障害とみなす。
- noindexをクロール停止策として付ける。Googleはnoindexを読むためにURLを取得する。
- 404をすべてトップへリダイレクトする。代替先のない削除は404または410を返す。
- robots.txtで一時的に空きを作れば、他ページへ必ず再配分されると期待する。
robots.txt、noindex、404は目的が異なる
robots.txtは主にクロール交通を制御しますが、URLを検索結果から必ず消す仕組みではありません。noindexはインデックスを止めるためにクロール可能である必要があります。永久削除は404または410です。秘密情報は認証で保護します。目的を決めずに組み合わせると、Googleがnoindexを読めない、重要ページが取得されない、削除URLがsoft 404として残るといった逆効果が生じます。
クロールバジェットを7段階で診断・改善する
一度にサイト全体を遮断せず、URL群と期間を固定して、原因仮説ごとに変更します。クロール要求には自然な週次・季節変動があるため、変更直前だけでなく同曜日を含む基準期間を持ちます。
- 1
重要URLと許容時間を定義する
商品、記事、求人、イベントなどをURL群に分け、公開・重要更新から何日以内にクロールされる必要があるかを業務要件で決めます。全URLの取得頻度最大化を目標にしません。
- 2
URL在庫を正規化する
canonical・index対象、重複、filter、sort、ページネーション、検索結果、削除、soft 404、リダイレクトを分類します。hostnameも分け、URL生成規則と内部リンク元を記録します。
- 3
基準データを保存する
Crawl Statsの要求数、応答コード、ファイル種別、目的、Googlebot種別、ホスト状態を保存します。検証済みGooglebotログからURL群別の最終取得、取得間隔、状態コード、応答時間を集計します。
- 4
取得不能を先に直す
可用性、5xx、DNS、timeout、誤robots.txt、壊れた内部リンク、誤canonical、誤noindexを修正します。重要URLをURL Inspectionと実HTTP応答で確認します。
- 5
不要URL在庫を減らす
重複はcanonicalへ統合し、新規生成と内部リンクを止めます。クロール不要URLはrobots.txt、永久削除は404・410、代替先がある移転は直接リダイレクトを使います。soft 404とチェーンを解消します。
- 6
発見と再取得の信号を整える
検索結果に出したいcanonical URLをsitemapへ載せ、重要変更だけ正確なlastmodを付けます。Googleはpriorityとchangefreqを無視します。重要ページへのクロール可能な内部リンクも確認します。
- 7
URL群ごとに再測定する
変更後も同じ集計条件で、重要URLの取得遅延、不要URL比率、5xx、応答時間、Page Indexingを比較します。改善しない場合はクロール能力、需要、品質、発見の仮説を分け直します。
変更は小さなURL群から始める
robots.txtやURL生成規則の変更は広範囲に影響します。代表ディレクトリやパラメータ群で、重要コンテンツとレンダリング資源を巻き込まないことを確認してから拡大します。遮断前後のルール、対象件数、解除方法を記録してください。
効果測定は、取得・応答・インデックス・検索成果を分ける
クロール要求総数が減っても、重要URLの取得が遅くなれば失敗です。総数が増えても、新規・更新URLが適時に取得され、不要URLと障害が減っているなら改善の可能性があります。検索順位や流入は内容、競合、需要などの影響を受けるため、クロール施策だけへ帰属させません。
取得
重要URL群の公開・更新から最初のGooglebot取得まで、最終取得日、取得間隔、未取得率をログで測ります。平均だけでなく中央値と遅い上位群を見ます。
応答
Crawl Statsと監視でhost availability、5xx、DNS、timeout、平均応答時間、304比率、リダイレクトチェーンを確認します。障害時間帯とGooglebot要求を照合します。
URL在庫
Googlebot要求に占めるcanonical・重要URL、重複、filter、soft 404、永久削除URLの割合を比較します。要求数の単純な増減より構成を見ます。
後段成果
Page Indexing、URL Inspection、検索表示、流入、業務成果を確認します。クロール済みでも未登録なら、品質、重複、canonical、レンダリングへ診断を移します。
中止・ロールバック条件
重要URLがrobots.txtで遮断された、レンダリングに必要な資源が取得不能になった、重要URLの取得遅延が悪化した、誤404・誤410・誤canonicalが増えた、サイトマップからindex対象が消えた場合は変更を戻します。クロール総数の減少だけを成功条件にしません。
公式資料と確認日
仕様・判断基準は2026年7月25日に次の一次資料で確認しました。Google Crawling Infrastructureのcrawl budget文書は2026年7月22日更新、sitemap文書は2026年7月8日更新の内容です。
- Google Crawling Infrastructure：Optimize your crawl budget
- Google Search Central：Troubleshoot Google Search crawling errors
- Google Search Central Blog：Crawl Stats report
- Google Search Central：Build and submit a sitemap
- Google Search Central：Block Search indexing with noindex
- Google Search Central：Introduction to robots.txt
クロールバジェットのよくある質問
小規模サイトでもクロールバジェット対策は必要ですか？
多くの場合、専用施策は不要です。Googleは、大規模・高頻度更新サイトや「検出 - インデックス未登録」が大きな割合を占めるサイト向けの高度なガイドとしています。公開後に妥当な期間で取得されているなら、サイトマップ、内部リンク、canonical、Page Indexing、コンテンツ品質の通常確認を優先します。
クロール回数を増やせば検索順位は上がりますか？
保証されません。クロールは発見・再取得の工程であり、その後にレンダリング、評価、重複統合、インデックス判断があります。検索順位はさらに別の段階です。必要なURLが取得されていない問題を解消することと、順位上昇を同じ約束にしないでください。
noindexを付けるとクロールバジェットを節約できますか？
クロール停止策にはなりません。Googlebotはnoindexを読むためにURLを取得し、その後インデックスから除外します。長期的にクロール不要な重複・並べ替えURLなどは、URL生成・内部リンク・canonicalを整理し、目的に合えばrobots.txtを検討します。
404はすべて別ページへリダイレクトすべきですか？
いいえ。代替先がある移転は直接リダイレクトし、永久削除で代替先がなければ404または410を返します。関係のないトップへ一律転送するとsoft 404と判断される可能性があり、利用者にも分かりにくくなります。
サーバーを高速化すればクロールは必ず増えますか？
必ずではありません。応答改善はクロール能力の制約を緩める可能性がありますが、需要が低ければ取得は増えません。Crawl StatsやURL Inspectionでhostload・可用性の制約があることを確認し、低品質URLを速くするだけで需要が増えるとは考えないでください。
Search Consoleだけで特定URLのクロール履歴を確認できますか？
完全には確認できません。Crawl Statsはサイト全体の傾向とURL例を示します。特定URLやディレクトリの取得日時・頻度は、検証済みGooglebotのサーバーログを使います。URL InspectionとPage Indexingを組み合わせ、クロールとインデックスも分けて確認します。
次に確認する記事
結論：クロールバジェットは、対象サイトで重要URLの取得を妨げる原因を直すために管理する
まず規模、更新頻度、「検出 - インデックス未登録」の割合、重要URLの取得遅延から適用対象を判定してください。対象なら、クロール能力と需要を分け、Crawl Stats、検証済みGooglebotログ、Page Indexing、URL Inspectionを照合します。可用性と誤設定を先に直し、重複・無限URL・soft 404・チェーンを整理し、canonical URLと正確なlastmodをサイトマップへ反映します。noindex、robots.txt、404・410を同じ目的で使わず、クロール総数ではなく重要URLの適時取得で評価します。
執筆・検証
Finite Field 編集部
Googleの公式クロール管理資料、Search Console資料、サイトマップ、robots.txt、noindexの仕様を確認し、適用条件、診断、施策、測定を分離して構成しました。検索順位やインデックス結果を保証する表現は採用していません。
クロール診断・URL在庫設計
大規模サイトのクロール遅延や不要URL生成を切り分けられない場合はご相談ください
100万URL規模、日次更新する1万URL以上、faceted navigation、複数hostname、JavaScript生成URL、大量のsoft 404・重複・リダイレクト、継続するhostloadがある場合は、ログ集計とURL在庫設計を含めて支援します。
クロール診断を相談するクロール頻度、インデックス登録、順位、流入、売上の向上は保証しません。現状データと変更リスクを確認して対応範囲を決めます。