大規模サイトのクロールバジェット管理

01 何が起きたか — 「クロールバジェット」を気にすべきサイトの条件

この概念が向けられている3つの対象

クロールバジェットとは、Google公式ガイドの定義によれば「Googleがクロールできて、かつクロールしたいと考えるURLの集合」を指す。この概念を扱ったガイドは、すべてのサイトに向けたものではない。ガイド自身が対象読者を明確に限定しており、「この推奨事項は一般的に良い実践ではあるが、これは主に次のようなサイト種別を対象とした上級者向けガイドである」としたうえで、週単位で更新される100万ページ以上の大規模サイト、日単位で更新される1万ページ以上の中〜大規模サイト、そしてSearch Consoleで「検出 — インデックス未登録」に分類されるURLが多いサイト、の3つを挙げている。

公開直後にクロールされるサイトには、このガイドは不要

逆にいえば、ページ数が少ない、または更新頻度が低いサイトで、公開したページが同じ日のうちにクロールされているようなサイトには、このガイドの推奨事項は基本的に不要である。クロールバジェットを気にする前に、まず自分のサイトが3条件のどれかに当てはまるかを判定することが、本記事の出発点になる。判定を飛ばしていきなり細かいテクニックに着手すると、実際には効果の出ない最適化に時間を使うことになりかねない。特に中小規模のコーポレートサイトやサービスサイトでは、ページ数が数百〜数千件程度にとどまることが多く、公開から数日以内に主要なページがクロールされているのであれば、クロールバジェットを理由に大がかりな対策を組む優先度は低い。むしろ、対象条件に当てはまるかどうかを判定する作業そのものを、後回しにせず最初に済ませておくことが、限られた作業時間を正しい場所に使うための分かれ目になる。

02 なぜ・背景 — 2つの要素が、それぞれ何で決まるか

クロール容量制限は、サーバーの応答状況で自動的に動く

クロールバジェットを構成する1つ目の要素がクロール容量制限である。これは、Googlebotがサイトへの接続を保持する総時間量と、並列に張る接続数を制限する仕組みで、サーバーに過負荷をかけないよう自動的に調整される。公式ガイドは「サイトが一貫して応答し、応答時間が安定または改善すれば、上限は上がる」と説明しており、逆にサーバーエラーが増えたり応答が遅くなったりすると、この上限は下がる方向に動く。クロール容量制限は、サイト側の技術的なコンディションを、Googleが観測して調整している数値だという前提を押さえておく必要がある。

クロール需要は、コンテンツの価値で決まる

2つ目の要素がクロール需要で、こちらはサーバーの性能ではなく、コンテンツそのものの価値によって決まる。公式ガイドが挙げる要因は、サイトの規模・更新頻度・ページの品質・他サイトと比較したときの人気度である。低品質なページや重複したコンテンツが大量にあるサイトは、たとえサーバー側の受け入れ余力が十分にあっても、Google側がそれらのページを積極的にクロールしたいとは判断しない。サーバーを増強してもクロール需要そのものは増えない点が、この2つの要素を分けて考える必要がある理由である。

クロールバジェットを増やす、2つのアプローチ

クロールバジェットを増やしたい場合、公式ガイドが示すアプローチは2つに分かれる。1つはサーバー側のリソースを追加し、クロール容量制限そのものを引き上げる方法。もう1つは、対象とするGoogleのプロダクトにとっての人気度・ユーザーにとっての総合的な価値・コンテンツの独自性を高め、クロール需要側を引き上げる方法である。サーバーを増強しても、コンテンツの品質が低いままではクロール需要は増えず、逆にコンテンツを改善してもサーバーが頻繁にエラーを返していれば容量制限側で頭打ちになる。どちらか一方だけを見て対策すると、もう一方が効果を打ち消すことになる。

03 この記事で出てくる用語

「クロール済み」と「クロールバジェットを使った」は同じではない

混同しやすい点として、あるURLがクロール済みであることと、そのクロールがクロールバジェットの中で価値のある使われ方をしたかどうかは、別の話である。重複コンテンツ・セッションIDを含むURL・無限に組み合わせが増えるフィルタ条件のURLなどは、クロールされたとしても、その分のクロールバジェットが低品質な用途に消費されたことになる。「クロールされているか」ではなく「クロールが何に使われているか」を見る視点が、最適化の出発点になる。数の上でクロール頻度が高いことを喜ぶ前に、その頻度が価値のあるページに向いているかを、まず確かめる必要がある。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — 自分のサイトは対象に当てはまるか

01章で見た3つの条件（大規模サイト・日次更新の中〜大規模サイト・「検出 — インデックス未登録」が多いサイト）のうち、いずれか1つにでも当てはまれば、本記事の対象になる。特に3つ目の条件は、サイトの規模にかかわらず確認できる。Search Consoleの「ページのインデックス登録」レポートを開き、「検出 — 現在インデックス未登録」に分類されているURL数が、公開しているページ数に対してどれくらいの割合になっているかを見る。この割合が高いサイトほど、クロールバジェットの制約が実際にインデックス登録を妨げている可能性が高い。逆に、この分類のURLがほとんどなければ、現時点でクロールバジェットを理由に対策を急ぐ必要性は低い。

1,000ページ未満なら、レポートを気にしなくてよいという明言

公式ヘルプの「クロール統計情報レポート」のページには、対象サイトについてさらに具体的な一文がある。「1,000ページに満たないサイトを運営しているのであれば、このレポートを使う必要も、この水準のクロールの詳細を気にする必要もない」という趣旨の記述である。これは01章で見た3条件（100万ページ以上・1万ページ以上・「検出 — インデックス未登録」が多い）よりも手前にある足切り線であり、公開ページ数が1,000に届かないサイトなら、05章のチェックリストのうちクロール統計情報レポートに関わる項目（3〜5番目）は優先度を下げてよい。同じガイドは大規模サイトの基準についても「ここに示した数字はサイトを分類する助けとするための大まかな目安であり、正確なしきい値ではない」と明記しており、数字に当てはまるかどうかより、実際のクロール頻度を継続して見るほうが重要になる。

1,000ページに満たないサイトが、代わりに確認できること

クロール統計情報レポートの深堀りより先に確認できる、より簡単な方法が3つある。第一に、Search Consoleの「ページのインデックス登録」レポートで、登録済み・除外の大まかな内訳を見る。第二に、URL検査ツールで主要なページを個別に検査する。ページ数が少なければ数分で全ページの状態を把握できる。第三に、site:自分のドメインという検索演算子で、おおよそのインデックス件数の目安を得る。正確な件数は保証しないが、極端な過不足には気づきやすい。クロール容量制限の引き上げもサーバー増強だけが選択肢ではない。画像の圧縮やキャッシュの活用など、応答速度を改善する対策も、02章の「応答時間が安定または改善すれば、上限は上がる」という条件を満たす手段になる。

🅱 この記事が測っていないこと・分からないこと

公式ガイドを確認しても、明確にされていない点がある。第一に、クロール容量制限が具体的にどれくらいの応答時間・エラー率で上下するかという、数値的なしきい値は公開されていない。第二に、robots.txtでページをブロックしてから、そのブロックがクロール頻度の変化として現れるまでの具体的な日数も示されていない。第三に、サーバーリソースを追加した場合に、クロール容量制限がどの程度・どれくらいの期間で上がるかという相関も明文化されていない。「何をどれだけ改善すれば、クロール頻度が何%上がるか」を一律の数字で語ることはできない。改善の効果は、Search Consoleのクロール統計情報レポートで自分のサイトの推移を継続的に見て確認するしかない。

🅲 手順 — 自分のサイトで確認する流れ

実際の確認は、次の4段階で進める。第一にURL在庫の棚卸しとして、サイト内に存在するURLのパターンを洗い出し、重複コンテンツ・セッションIDやフィルタ条件を含むパラメータ付きURL・存在しないのに200を返しているページ（ソフト404）を特定する。第二にクロール統計情報レポートの確認として、Search Consoleの設定からクロール統計情報レポートを開き、合計クロールリクエスト数・平均応答時間・レスポンスコードの内訳・ホストステータスを確認する。第三にrobots.txt・404・410の整理として、価値のないページ群をrobots.txtでブロックし、恒久的に削除したページには404または410を正しく返す。第四にサイトマップの更新として、価値のあるURLだけを収録したサイトマップを最新の状態に保ち、Search Consoleに送信する。

クロール統計情報レポートで、何が見られるか

第二段階で使うクロール統計情報レポートは、Search Consoleの「設定」内からアクセスできる（ルートレベルで検証したドメインプロパティまたはURLプレフィックスプロパティが対象）。このレポートで確認できる分類は、合計クロールリクエスト数（成功・失敗を問わずサイトのURLに対して発行された要求の総数）、平均応答時間（サイトから取得したすべてのリソースの平均応答時間）、ホストステータス（可用性の問題の有無を3段階で表示）、レスポンスの内訳（200・301・302・404・5xxなどのHTTPステータスコード別）、ファイルタイプ別（HTML・画像・動画・JavaScript・CSS・PDFなど）、クロール目的別（新規発見のDiscoveryと再クロールのRefresh）、Googlebotの種類別（スマートフォン・デスクトップ・画像・動画・AdsBotなど）である。この分類ごとの推移を継続的に見ることで、どの種類のURLにクロールが偏っているかを把握できる。

ホストステータスの3段階と、robots.txtの再取得にかかる具体的な時間

ホストステータスの3段階について、公式ヘルプは次のように定義している。緑は「過去90日間に重大なクロール可用性の問題が発生していない」状態、黄色は「過去90日以内に少なくとも1件の重大な問題が発生したが、それは1週間より前」の状態、赤は「過去1週間以内に重大な問題が発生している」状態を指す。赤が出ている間は、他のどの対策よりも先に、サーバー側の可用性を確認する必要がある。

robots.txtの再取得についても、公式ヘルプはより詳細な挙動を示している。Googleはクロールの前に24時間以内に成功したrobots.txtの取得があるかを確認し、あればそれを使う。取得が失敗し続けた場合は、最初の12時間はクロールを完全停止しつつrobots.txtだけは取得を試み続け、12時間から30日の間は最後に成功した内容を使い続ける。緊急で書き換えた直後に「まだ古い設定のまま」に見えても、想定内の遅延と判断できる。

確認は1回で終わらせない

クロール統計情報レポートは直近90日間の推移を表示するが、robots.txtやサイトマップを変更した直後にすぐ数値が動くとは限らない。設定を変更した日をメモしておき、1週間後・1ヶ月後の2回に分けて同じレポートを見直すことで、変更前後の傾向の違いが分かりやすくなる。1回だけ見て「効果がなかった」と判断するのではなく、複数回の推移を比較する前提で確認する。

手順化 — ステータスコードを実際にコマンドで確認する

05章のチェックリストにある「ソフト404の確認」「リダイレクトホップ数の確認」「サーバーの平均応答時間の確認」は、ブラウザで1件ずつ開くより、コマンドラインから確認したほうが早く、記録にも残しやすい。手順は次の通りである。

① 確認したいURLを1つ用意する。② ターミナルでcurl -I -L "確認したいURL"を実行する（-Iはヘッダーのみ取得、-Lはリダイレクトを追跡するオプション）。③ 出力されるHTTP/1.1 200 OKのような行の数字を見る。200なら正常、301・302が複数回続く場合はその回数がリダイレクトホップ数になる。404・410が返ればそのページは正しく「存在しない」ことが伝わっている。④ 削除したはずのページで200が返ってきた場合、それがソフト404である。⑤ 応答時間はcurl -o /dev/null -s -w "%{time_total}\n" "確認したいURL"で秒単位が出力される。

05 明日、自分のサイトで確認できることチェックリスト

まず何を数えるか

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、対象判定（3条件のどれかに当てはまるか）、URL在庫の把握、クロール統計情報レポートの確認、robots.txt・404・410・サイトマップの整理、の4つに分かれる。

• Search Consoleの「ページのインデックス登録」レポートを開き、「検出 — 現在インデックス未登録」の件数を確認する
• 公開しているページ数に対する、上記の件数の割合を計算し、自分のサイトが対象条件に当てはまるかを判定する
• Search Consoleの設定からクロール統計情報レポートを開き、直近90日間の合計クロールリクエスト数の推移を確認する
• 同じレポートで、ホストステータスに可用性の問題が出ていないかを確認する
• 同じレポートのレスポンス内訳で、404・5xxなどエラー系のステータスコードが占める割合を確認する
• サイト内のURLを一覧化し、セッションIDやフィルタ条件を含むパラメータ付きURLが何種類あるかを数える
• 内容が重複しているページを3組選び、canonicalタグまたは301リダイレクトで正規化されているかを確認する
• 恒久的に削除したページを5件選び、正しく404または410を返しているか確認する
• ソフト404（存在しないのに200を返しているページ）が無いか、削除済みページの一部をブラウザで開いて確認する
• robots.txtを開き、価値の低いページ群（内部検索結果ページや管理画面など）がブロックされているか確認する
• サイトマップの<lastmod>が、実際の更新日時と一致しているかを3ページ分確認する
• リダイレクトのホップ数を3件のURLで確認し、3ホップを超えるチェーンがないか確認する
• サーバーの平均応答時間を確認し、クロール統計情報レポートの数値と大きく乖離していないか照らし合わせる
• 今日確認した合計クロールリクエスト数を記録し、1ヶ月後に同じ手順で再確認する予定を入れる

14項目の内訳と、かかる時間の目安

14項目は4つの観点に対応している。それぞれにどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

すべてに目を通す時間の目安は1サイトあたり50〜70分程度である（重複コンテンツやパラメータ付きURLの洗い出しは、サイトの規模によってさらに時間がかかることがある）。すべてのページを一度に見る必要はなく、まずクロール統計情報レポートで現状を把握してから、優先度の高いURL群から着手するとよい。

06 代替・他の選択肢（表で）

クロールを無駄にする4つの要因と、それぞれの対処

クロールバジェットが低品質な用途に消費される典型的な要因を、対処法とあわせて以下の表にまとめた。

noindexは、クロールの節約にはならない

ページを検索結果から外したい場合、noindexとrobots.txtのどちらを使うべきか迷いやすいが、クロールバジェットの観点では両者の効果はまったく異なる。公式ガイドは「noindexを使わないでほしい。Googleはそのページを引き続きリクエストしたうえで、後から除外することになる」と明記している。つまり、noindexはクロール自体を止めない。クロールそのものを節約したいのであれば、robots.txtでブロックする必要がある。ただしrobots.txtでブロックすると、そのページは検索結果に一切表示されなくなるわけではなく、URLだけがスニペットなしで表示され続けることがある。noindexとrobots.txtが止めている対象の違いについては、3つの設定の役割分担を整理した回で詳しく扱っている(noindex・nofollow・robots.txtは、それぞれ何を止めているのか)。また、重複コンテンツをどう統合するかという判断は、AIクローラーへの対応で「通す」「止める」を切り分けた回とも共通する視点がある(AIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける)。

ファセットナビゲーションとURLパラメータの扱い

ECサイトやメディアサイトでよく使われる、色・サイズ・価格帯・並び順などで絞り込むファセットナビゲーションは、組み合わせの数だけURLが増えやすく、クロールを消費する典型例として知られている。かつてSearch Console内には、パラメータの扱いをGoogleに申告するための専用ツールがあったが、Googleは2026年より前の時点でこの「URLパラメータ」ツールの提供を終了したと発表している。現在は、パラメータ付きURLの扱いをツールで個別に申告する手段がなく、robots.txtによるブロック、canonicalタグによる正規化、またはパラメータを含まない静的なURL構造への変更で対応することになる。セッションIDや参照元を示すパラメータについても同様で、これらを含むURLをそのままクロールさせ続けると、同じページの内容が無数のURLとして重複して扱われる状態を作り出す。

robots.txtでパラメータ付きURLをブロックする、具体的な書き方

URLパラメータツールが提供終了となった今、robots.txtでブロックする場合はDisallowディレクティブにワイルドカードを使う。並び順を指定する?sort=を含むURLをすべてブロックしたいなら、Disallow: /*?sort=のように、パス全体を表すアスタリスク（*）とパラメータ名を組み合わせて1行を追加する。複数のパラメータが組み合わさるURLでも、パラメータ名ごとに1行追加すれば、組み合わせの数に関係なくブロックできる。

URLパラメータへの3つの対処法を比較する

パラメータ付きURLへの対処は主に3つの方法に分かれる。効果と手間が異なるため、状況に応じて使い分ける必要がある。

クロールバジェットの節約だけが目的なら、robots.txtでのブロックが最も手早い。一方で、絞り込んだ結果のページ自体に検索需要がある場合は、ブロックすると需要を取りこぼすため、静的なURLへの作り直しやcanonicalタグでの正規化のほうが適している。

サイトマップと内部リンクは、どちらを先に手を入れるべきか

クロールされていないページが多いと分かったとき、「サイトマップを送り直す」と「内部リンクを整理する」のどちらから着手するか迷うことがある。この2つは同じ「Googleにページを見つけてもらう」ための手段に見えるが、公式ドキュメントでの位置づけは対等ではない。

Google Search Centralのサイトマップの解説には、「If your site's pages are properly linked, Google can usually discover most of your site.（サイトのページが適切にリンクされていれば、Googleは通常、サイトの大部分を検出できます）」と書かれている（Sitemaps overview | Google Search Central）。さらに同じページでは、サイトマップが必要ない場合の条件の1つとして「Your site is comprehensively linked internally.（サイトが内部で網羅的にリンクされている）」を挙げている。

つまり公式の説明では、内部リンクが十分であることが基本の状態として置かれていて、サイトマップはそれを補う位置にある。同じドキュメントには「However, it doesn't guarantee that all the items in your sitemap will be crawled and indexed.（ただし、サイトマップ内のすべての項目がクロールされ、インデックスに登録されることを保証するものではありません）」とも書かれている。送信したこと自体は、クロールの約束にはならない。一方で同じページには「Even so, a sitemap can improve the crawling of larger or more complex sites, or more specialized files.（それでも、サイトマップは、大規模またはより複雑なサイトや、より特殊なファイルのクロールを改善できます）」とも書かれており、規模が大きいサイトでは意味を持つとされている。

この表から言えるのは、サイトマップの送信は「一覧を渡す」作業であり、内部リンクの整理は「経路を作る」作業であるということだ。一覧は渡せば済むが、経路は作らなければ存在しない。到達しにくいページが構造的に生まれている場合、一覧だけを渡しても状況は変わりにくい。

07 自社サイトで確認したこと — ログの取り方そのものが結果を左右した記録

「クロール頻度が低い」と判断する前に、測り方を疑う

当サイトが公開しているブログでは、robots.txtの再取得間隔（キャッシュ）について、複数のサイトのアクセスログを同じ条件で並べる前に確認すべきことがあった、という記録がある(archives/117)。クロール頻度やクロールリクエスト数を自分のサイトで測定するときも同じ注意が当てはまる。ログの集計範囲やファイル名の指定を誤ると、実際より少ない件数を「クロール頻度が低い」と誤読しかねない。クロール統計情報レポートの数値と、サーバー側のアクセスログを自分で集計した数値を突き合わせる際は、両方を同じ期間・同じ条件で揃えることが前提になる。

再クロールが実際にどれだけ時間を要したかの記録

クロールバジェットの最適化は、対策をしてすぐに効果が数字として現れるものではない。当サイトのブログでは、公開済みの記事が再クロールの待ち行列に入ってから実際に反映されるまでの期間を、Google公式の目安とあわせて記録した回がある(archives/108)。クロールバジェットを最適化した後、実際にクロール頻度が改善したかどうかを判断するときは、この記録にあるように、変化を確認するまでに一定の期間を見込んでおく必要がある。

08 このテーマの、これまで

「クロールされていない」と「価値がないと判断された」は違う

当サイトでは以前、公開していた記事の8割にあたる約1,000本が、検索エンジンから見て「土俵に上がっていない」状態になっていたことに気づいた記録がある(archives/98)。この事例は本記事のテーマと直接は異なるが、大量のページが低品質・未整備な状態のまま公開され続けると、クロールの優先度が上がりにくいという点で、クロールバジェットの「クロール需要」側の考え方と重なる。この気づきをきっかけに、対象となったページを6日間で一括して見直した記録もある(archives/105)。大量のURLを整理するときほど、機械的に状態を突き合わせる仕組みを先に用意しておく必要があるという点は、本記事04章の「URL在庫の棚卸し」にもそのまま当てはまる。

クローラーは1種類ではないという前提

クロールバジェットの議論はGoogle検索のクローラーを主な対象にしているが、実際のサーバーには他にも多種多様なクローラーがアクセスしてくる。当サイトでは、インフラ層でのAIクローラーの一律ブロックが、意図しない範囲まで巻き込んでいた事例を記録している(archives/86)。クロールに関する設定を変更する際は、それがGooglebotだけに効くのか、他のクローラーにも影響するのかを切り分けて確認する必要がある。この視点は、本記事06章で触れたrobots.txtによるブロックを設計する際にも共通する。