この記事の要点：
- クロールバジェットとは、Google が 1 つのサイトのクロールに使える時間とリソースの割り当てのことです。Google は「クロールが可能であり、かつクロールが必要な URL セット」と定義しています。
- 決まり方は「クロール能力の上限」（サーバーに負担をかけない範囲）と「クロールの必要性」（URL の数・人気・古さ）の 2 つです。
- Google のガイドの対象は、重複のないページが 100 万以上で週 1 回程度更新されるサイトや、1 万以上で毎日更新されるサイトなどです（出典：Google for Developers：クロール バジェットの管理）。数百ページの企業サイトやブログでは、サイトマップを最新に保ち、インデックス登録の状況を確かめれば十分です。
- クロールを減らしたい URL には robots.txt を使います。noindex はクロールを減らしません。完全に削除したページは 404 か 410 を返し、長いリダイレクトのつながりを避けます。
クロールバジェットとは：Googleが1つのサイトのクロールに使える量
クロールバジェットとは、Google が 1 つのサイトをクロール（ページを取得すること）するために使える時間とリソースの割り当てのことです。Google のクロール インフラストラクチャの文書「クロール バジェットの管理」は、ウェブはほぼ無限に近いため、Google が 1 つのサイトのクロールに費やせる時間とリソースには限界があり、「これらのリソースの割り当ては、通常、サイトのクロール バジェットと呼ばれます」と説明しています（Google for Developers：クロール バジェットの管理、最終更新日 2026-09-16、2026年10月13日確認）。
この文書は、もとは Google 検索セントラルの「大規模なサイト所有者向けのクロール バジェット管理ガイド」として公開されていたもので、2026年10月13日時点では、旧 URL（developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget）を開くと上の新しい URL へ転送されます。
同じ文書は、クロールの単位となる「サイト」を一意のホスト名として扱うと説明しています。例えば https://www.example.com/ と https://code.example.com/ は別々のサイトで、それぞれにクロール バジェットが割り当てられます。また、クロールされたページが必ずインデックスに登録されるわけではなく、クロールの後に評価・統合を経て登録の可否が判断されます。クロールバジェットは「検索結果に出る数」ではなく、「取りに来てもらえる量」の話です。
Googlebot（Google 検索のクローラー）の仕組みや種類は「クローラーとは」で説明しています。この記事では、クロールバジェットの決まり方と、自社のサイトで対策が必要かどうかの判断に絞って説明します。
クロールバジェットが決まる仕組み：クロール能力の上限とクロールの必要性
クロールバジェットは、「クロール能力の上限」と「クロールの必要性」の 2 つで決まります。Google の文書は、この 2 つを合わせて、サイトのクロール バジェットを「Google によるクロールが可能であり、かつクロールが必要な URL セット」と定義しています。
クロール能力の上限（ホスト負荷）
クロール能力の上限とは、サーバーに負担をかけずに Google がクロールできる量の上限です。並列の接続の数と接続の時間で決まり、すべてのサイトは同じ控えめな上限から始まります。Google の文書によると、サイトが一貫して応答し、応答時間（Time-to-First Byte など）が安定または改善していると上限が上がります。反対に、応答が遅くなったり、サーバーエラー（5xx）や HTTP 429（リクエストが多すぎる）が返されたりすると、上限が下がってクロールが減ります。
クロールの必要性（クロールの需要）
クロールの必要性とは、Google がそのサイトの URL をどれだけ取りに行きたいかの度合いです。Googlebot の場合は、サイトの規模、更新の頻度、ページの品質、関連性で変わり、運営者が影響を与えられる主な要因として次の 3 つが挙げられています。
| 要因 | Googleの説明の要旨 | 運営者ができること |
|---|---|---|
| 検出された URL 群 | Google は認識している URL のすべてまたはほとんどをクロールしようとする。重複や不要な URL が多いと時間が無駄になる。「最も確実に管理できる要素」 | 重複をまとめ、不要な URL を作らない・クロールさせない |
| 人気度 | インターネット上で人気の高い URL ほど頻繁にクロールされる傾向がある | 読まれ、リンクされるページを作る |
| 古さ | 変更を反映できる頻度で再クロールしたい | 更新したページをサイトマップに載せ、lastmod を正しく出す |
サイトの移転のようにサイト全体が変わるときも、新しい URL を処理するためにクロールの必要性が高まることがあります。なお、クロール能力の上限は Google のすべてのクローラーで共有されるため、広告用の AdsBot など別のクローラーの需要が高いと、他のクローラーが使える容量が減ることがあると説明されています。
クロールバジェットを気にすべきサイト・気にしなくてよいサイト
クロールバジェットを気にする必要があるのは、主に大規模で頻繁に更新されるサイトです。Google の文書は、ガイドの対象を次のようなサイトとしています。
- 大規模（重複のないページが 100 万以上）で、コンテンツが中程度に（1 週間に 1 回）更新されるサイト
- 中規模以上（重複のないページが 1 万以上）で、コンテンツがかなり頻繁に（毎日）更新されるサイト
- Search Console で URL の大部分が「検出 – インデックス未登録」に分類されるサイト
同じ文書は、これらの数値は「大まかな目安」で正確なしきい値ではないとしたうえで、頻繁に更新されるページがそれほど多くない場合や、ページが公開日と同じ日にクロールされると考えられる場合は「このガイドを読む必要はありません」と書いています。その場合、Google 検索については、サイトマップを最新の状態に保ち、ページのインデックス登録レポートを定期的に確認するだけで十分とされています。
| サイトの状況 | どうする | 理由 |
|---|---|---|
| 数十〜数千ページの企業サイト・ブログ | クロールバジェットの対策は不要。サイトマップと内部リンクを整える | Google のガイドの対象の目安より小さい |
| 新しい記事がなかなか登録されない | 先に内部リンク、サイトマップ、robots.txt、noindex、記事の内容を確かめる | 小さなサイトでは、バジェットより発見や品質の問題であることが多い |
| URL の大部分が「検出 – インデックス未登録」 | 不要な URL の組み合わせが無いか、サーバーの応答が遅くないかを確かめる | Google のガイドが対象として挙げている状態 |
| 絞り込みや並べ替えで URL が数十万以上できる EC サイトなど | 重複をまとめ、不要な組み合わせを robots.txt で止める | 検出された URL 群が多いほど、クロールの時間が無駄になる |
「検出 – インデックス未登録」の原因の調べ方は「検出 – インデックス未登録の原因と対処」で説明しています。Search Console のクロールの統計情報レポートのヘルプも、サイトのページ数が 1,000 未満の場合は「このレポートを使用する必要はありません」としています（Search Console ヘルプ：クロールの統計情報レポート、2026年10月13日確認）。
当サイト（seoagent.jp）の規模と、小さなサイトで実際に起きる問題
当サイト（seoagent.jp）は、2026 年 10 月 13 日の自動の SEO 点検で、リンクをたどって取得できた URL が 279 件の小さなサイトです。Google のガイドの目安（1 万ページ以上）から大きく離れているため、クロールバジェットの対策は行っていません。代わりに、Google が「最も確実に管理できる要素」とする URL 群を、余計な URL が増えないように点検しています。
| 点検の項目 | 2026年10月13日の結果（自動の SEO 点検） |
|---|---|
| robots.txt | 200 を返す。中身は管理画面（/wp-admin/）だけを止め、サイトマップの場所を書いたもの |
| 内部リンクの先のステータス | エラーを返すリンク 0 件、リダイレクトするリンク 0 件 |
| サイトマップに入っている noindex のページ | 0 件 |
| noindex にしている一覧ページ | 記事が少ない英語の一覧やニュースの分類の一覧など。サイトマップから外し、リンクはたどれる状態（follow） |
小さなサイトで実際に起きたのは、バジェットの不足ではなく URL の扱いの問題でした。当サイトでは、SEO プラグインのサイトマップが古いキャッシュのままで 4 件しか載っていなかったこと、記事のない一覧や範囲外のページ番号が検索対象になりうる状態だったこと、日本語版の URL を変えた際に旧 URL からの 301 が必要になったことがありました。それぞれ、サイトマップの作り直し、noindex・404・301 の設定、旧 URL から新 URL への 1 対 1 の 301 で対応しています。
2026 年 10 月 13 日には、記事の本文の外部リンク 326 URL を点検し、公式の文書の構成の変更によるリダイレクトが 27 件あったため、24 URL を転送先に直しました。自分のサイトの中のリンクも同じで、リダイレクトを経由するリンクは、クロールのたびに余分なリクエストを生みます。Search Console のクロールの統計情報レポートでは、リダイレクトのつながりの各リクエストが別々に数えられます。
クロールの状況の確かめ方：クロールの統計情報レポート
Google がサイトをどれだけ、どのようにクロールしているかは、Search Console の「クロールの統計情報」レポートで確かめます。開き方は、Search Console の「設定」から「クロールの統計情報」を選びます。ドメイン プロパティか、ルートの URL プレフィックス プロパティでだけ使えます。
レポートには、クロール リクエストの合計数、ダウンロードの合計サイズ、平均レスポンス時間、ホストのステータスと、レスポンス・ファイル形式・目的・Googlebot の種類別の内訳が表示されます。クロールバジェットの観点で見るのは次の 3 つです。
- 平均レスポンス時間とホストのステータス：応答が遅くなっていないか、robots.txt の取得・DNS・サーバーの接続に問題が出ていないかを見ます。応答の遅れやエラーは、クロール能力の上限を下げる要因です。
- レスポンス別：Google のヘルプは、サイトの再編成や移転をしていない限り、ほとんどが 200 などの正常なレスポンスであるべきとしています。5xx やリダイレクトの割合が高い場合は、該当する URL の例を開いて原因を探します。
- 目的別：「検出」はこれまでクロールされたことのない URL、「更新」は既知のページの再クロールです。新しいページを公開しているのに検出がほとんど無い場合は、内部リンクとサイトマップを確かめます。
各項目の詳しい読み方と、サーバーログで Googlebot のアクセスを確かめる方法はクローラーの記事の「クロールの統計情報」の節で説明しています。
クロールを無駄にする原因と対処：robots.txt・404/410・リダイレクト・サイトマップ
クロールを無駄にする主な原因は、重複した URL、クロールさせる必要のない URL、soft 404、長いリダイレクトのつながり、遅いサーバーの応答です。Google の文書は、ベスト プラクティスとして次の項目を挙げています。
| 原因 | Googleが勧める対処 |
|---|---|
| 重複したコンテンツの URL が多い | 重複を 1 つにまとめ、一意のコンテンツだけをクロールさせる |
| 無限スクロールのページ、並べ方が違うだけのページなど | まとめられない場合は robots.txt で重要でないページをブロックする |
| 完全に削除したページ | 404 または 410 を返す。404 は再度クロールしないよう強く求めるシグナル |
| soft 404（中身が無いのに 200 を返すページ） | クロールが続くため、ページのインデックス登録レポートで見つけて直す |
| サイトマップが古い | クロールさせたいコンテンツをすべて載せ、更新したページには lastmod を付ける |
| 長いリダイレクトのつながり | 避ける。リンクは最終の URL に直接向ける |
| 読み込みが遅い | サーバーの応答時間を改善する。変更の無いページに 304（Not Modified）を返せるようにする |
リダイレクトについて、Google の文書「HTTP ステータス コードが Google のクローラーに及ぼす影響」は、Google のクローラーは既定で最大 10 回のリダイレクトをたどると説明しています（Google for Developers：HTTP ステータス コードが Google のクローラーに及ぼす影響、最終更新日 2026-03-06、2026年10月13日確認）。10 回までなら追えるとしても、つながりが長いほど取得のリクエストは増えます。サイトの移転の後は、内部リンクとサイトマップを新しい URL に直します。
サーバーの側では、5xx と 429 のエラーが続くと、Google はクロールのペースを落とします。同じ文書は、4xx のエラー（429 を除く）はクロール頻度に影響しないとし、クロールを減らす目的で 401 や 403 を使わないよう注意しています。
noindex・robots.txt・404とクロールの関係
クロールを減らしたい URL には robots.txt を使い、noindex は使いません。Google の文書は、noindex のページも Google は引き続きリクエストし、noindex を確認した時点で対象外にするため「クロール時間が無駄になります」と説明しています。一方で、検索結果から確実に外したいページは、robots.txt で止めずに noindex にする必要があります。目的によって使い分けます。
| 方法 | クロール | インデックス | 使う場面 |
|---|---|---|---|
| robots.txt の Disallow | 止める | 確実には外れない（他からリンクされると URL だけ登録されることがある） | 重要でない URL のクロールを減らす |
| noindex | 続く（取得してから対象外にする） | 外れる（クロールを許可している場合） | ページは残すが検索結果には出したくない |
| 404 / 410 | 徐々に減る | 外れる | ページを完全に削除した |
| 301 リダイレクト | 転送先を取りに行く | 転送先が処理される | ページを移した |
注意点が 2 つあります。1 つ目に、robots.txt で止めたページに noindex を付けても、Google はページを取得できないため noindex を読めません。2 つ目に、Google の文書は、他のページのためにクロール バジェットを一時的に再配分する目的で robots.txt を使わないよう求めています。クロール能力の上限に達していない限り、空いたバジェットが他のページに回ることはないためです。robots.txt の書き方はrobots.txtの書き方、noindex の設定は「noindexとは」で説明しています。
AI検索とクロールバジェット
AI による概要や AI モードのために、クロールバジェットで特別な対策をする必要はありません。Google は、AI による概要や AI モードにサポートリンクとして表示されるには、ページがインデックスに登録され、スニペットが表示でき、検索の技術的要件を満たしていることが必要で、それ以外の追加の技術要件は無いとしています。そのうえで、SEO の基本として「クロールが robots.txt に加え、CDN またはホスティング インフラストラクチャで許可されていることを確認します」「コンテンツがウェブサイトの内部リンクから簡単に見つけられるようにします」を挙げています（Google 検索セントラル：AI 機能とウェブサイト、最終更新日 2025-12-31、2026年10月13日確認）。
つまり、AI 検索で必要なのも、まず Google にクロールされ、登録されることです。サーバーの保護のために CDN やファイアウォールでボットを止める設定をしている場合は、Googlebot まで止めていないかを確かめます。一方、Google の文書が扱っているのは Google のクローラーです。ChatGPT など他社の AI のクローラーからのアクセスは、Google のクロールバジェットとは別に、サーバーの負荷として表れます。AI のクローラーの種類と robots.txt での扱いは「AIクローラーとは」で説明しています。
よくある質問
小さなサイトでもクロールバジェットの対策は必要ですか？
ほとんどの場合、必要ありません。Google のガイドの対象の目安は、重複のないページが 1 万以上で毎日更新されるサイトや、100 万以上で週 1 回程度更新されるサイトです。小さなサイトでは、サイトマップを最新に保ち、ページのインデックス登録レポートを確かめれば十分とされています。
noindexはクロールバジェットを節約しますか？
節約しません。Google は noindex のページも引き続きリクエストし、noindex を確認してから対象外にします。クロールを減らしたい重要でない URL は robots.txt でブロックします。ただし、検索結果から外したいページは robots.txt で止めずに noindex を使います。
クロールの頻度は順位に影響しますか？
クロールの回数が多いことで順位が上がる、という説明は Google の文書にはありません。クロールはページを取得する段階で、取得されたページが登録されるか、どの順位に出るかは別に判断されます。クロールの不足が問題になるのは、更新や新しいページが反映されないときです。
クロールの頻度を上げるには？
Search Console のヘルプは、Google にクロール頻度を上げるよう伝えることはできないとしています。小規模・中規模のサイトでは、サイトマップを更新し、必要なページをブロックしていないかを確かめます。Google の文書は、バジェットを増やす方法として、サーバーの容量が原因の場合のサーバー リソースの追加と、コンテンツの品質の改善を挙げています。
SEOAGENTでできること
SEOAGENT は、記事の企画から公開後の分析までを支援するツールです。Search Console と GA4 を連携すると、記事ごとの表示回数・クリック・インデックスの状況を確認できます。AI 検索向けのクローラーの設定は、robots.txt を 1 日 1 回読み、検索の表示に使われるクローラーと学習に使われるクローラーを分けて示します。
できないこと：クロールの統計情報レポートやサーバーのログの取り込みは行いません。robots.txt やサーバーの設定を自動で変更することもありません。クロールやインデックスへの登録、検索順位を保証するものではありません。クロールバジェットと関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。
