クロールバジェット最適化の実務｜大規模サイトでクロールを「増やす」より「配り直す」【2026年版】

「クロールバジェットを増やしたい」という相談をよく受けます。しかし実務では、この問いの立て方自体がほぼ間違いです。

クロールバジェットは、サイト側の操作で総量を増やせるものではありません。増やすためのボタンは存在せず、Googleに申請する窓口もありません。事業側が握れるのは総量ではなく配分です。いま無価値なURLに流れている7割のクロールを、主戦場のテンプレートに回す。これが実務としてのクロールバジェット最適化のすべてです。

本記事は、データベース型サイトのSEO完全ガイドの4章「クロールを通す」を、実際に開発チケットへ落とせる粒度まで掘り下げたものです。数万〜数百万ページ規模のデータベース型サイト(求人・不動産・EC・ポータル)を運用する事業会社のSEO担当・開発責任者に向けて、診断手順・浪費の止め方・効果測定を順に解説します。

1. まず判定:あなたのサイトはクロールバジェットを気にすべきか

最初に、読者の大半をここで正しく帰します。クロールバジェットは、ほとんどのサイトにとって考える必要のない概念です。

Googleは公式に、クロールバジェットの管理が必要になるサイトの条件を示しています。要約すると、次のいずれかに該当する規模です。

数千ページ規模のサイトで「クロールバジェットが足りないのでは」という議論が始まっていたら、それは症状の取り違えです。その規模でインデックスされないのは、ほぼ例外なくコンテンツ側の問題です。

この切り分けを飛ばして「クロールバジェット対策」に着手するのが、大規模サイトSEOで最も頻繁に起きる誤診です。クロール済みなのにインデックスされていないURLは、Googlebotが既に到達し、中身を見たうえで「登録する価値がない」と判断した状態です。ここにクロールをさらに流しても、結果は変わりません。

2. クロールバジェットの正確な定義

用語の理解が曖昧なまま施策を決めると、必ず的を外します。クロールバジェットは単一の数値ではなく、2つの独立した要素の掛け合わせで決まります。

要素1:クロール能力の上限(サーバー側の事情)

Googleは、サイトに負荷をかけずにクロールできる範囲を自動で見積もっています。判断材料は主にサーバーの応答です。

• 応答が速く、エラーが少ない → Googlebotは接続数を増やし、クロール量が上がる
• 応答が遅い、5xxエラーや429が返る → Googlebotは即座に接続を絞る

つまりこちらは、サイトの技術的な健全性がそのまま上限になるという性質です。CDNの導入、DBクエリの改善、キャッシュの適用といったインフラ側の改善が、そのままクロール量の上限を押し上げます。

重要なのは、この上限はGoogleが親切心で決めているのではなく、サイトを落とさないための安全装置だという点です。応答時間が悪化すればクロールは減り、改善すれば戻る。ここに交渉の余地はありません。

要素2:クロールの必要性(サイト側の需要)

上限に余裕があっても、Googleがクロールしたいと思わなければクロールは発生しません。必要性を決めるのは主に次の3点です。

• URLの人気度:被リンク、内部リンク、実際のトラフィック。人気のあるURLはより頻繁に再クロールされる
• 鮮度:更新されるURLは繰り返し取得される。逆に何年も変わらないURLの再訪頻度は落ちる
• 在庫の質:サイト全体に低品質・重複URLが多いと、Googleはそのサイトのクロールに割く価値を下げる

ここが実務上いちばん重要な示唆を含んでいます。無価値なURLを大量に生成していること自体が、サイト全体のクロール必要性を下げるからです。ファセットの組み合わせ爆発で10万URLを増やしたサイトが、増やす前より主要ページのクロール頻度が落ちる、という現象はここに起因します。

だから「増やす」ではなく「配り直す」

2つの要素を踏まえると、事業側が取れる打ち手は次の3種類に整理できます。

最後の行が本記事の出発点です。存在しない手段を探すのをやめ、配分の設計に工数を寄せる。これが実務としての最適化です。

3. 診断:自サイトのクロールを測る

推測で施策を決めないために、まず現状のクロールを数値で把握します。見る場所は2つです。

Search Console「クロールの統計情報」の読み方

設定 > クロールの統計情報(サイト全体のプロパティで確認)。ここで見るべきは合計数ではなく、内訳の異常です。

このレポートの限界も理解しておく必要があります。サイト全体の集計しか出ず、「どのテンプレートに何%配分されているか」は分かりません。 大規模サイトの診断で本当に必要なのはその内訳なので、次のログ分析が必要になります。

サーバーログでGooglebotのテンプレート別配分を出す

DB型サイトのクロール診断で、最も情報量が多い作業です。手順は4段階です。

手順1:ログを確保する

アクセスログを最低2週間分、できれば1ヶ月分。CDNを挟んでいる場合、オリジンのログにはCDNキャッシュヒット分が現れないため、CDN側のログを取る必要があります。ここは開発チームへの依頼事項になります。

手順2:Googlebotを正しく抽出する

User-Agentの文字列だけで判定すると、Googlebotを騙る第三者のクローラーが混入します。正確を期すなら、IPの逆引き→正引きで googlebot.com / google.com に解決されることを確認します。まず概況を掴む段階なら、User-Agentでの抽出でも実務上は足ります。

# Googlebotのアクセスのみ抽出(概況把握用)
grep -i "googlebot" access.log > gbot.log
wc -l gbot.log

手順3:テンプレート別に集計する

ここが本題です。URLパターンをテンプレートに正規化して数えます。

# 例: 求人サイトのURL設計を想定したテンプレート別クロール数
awk '{print $7}' gbot.log \
  | sed -E 's#^/jobs/[^/]+/[^/]+/[0-9]+.*#[求人詳細]#;
            s#^/jobs/[^/]+/[^/]+/?(\?.*)?$#[職種x地域一覧]#;
            s#^/jobs/[^/]+/?$#[職種一覧]#;
            s#^/area/.*#[地域一覧]#;
            s#^/search\?.*#[サイト内検索]#;
            s#^/company/.*#[企業ページ]#' \
  | sort | uniq -c | sort -rn | head -30

手順4:配分表を作り、価値と突き合わせる

集計結果を、テンプレートごとの流入実績と並べます。この表が診断のアウトプットです。

見るべきは「クロール配分」と「流入貢献」の乖離です。流入の大半を生むテンプレートのクロール配分が1割を切っていたら、それが是正すべき状態です。

4. 浪費の典型7パターンと止め方

ログを見ると、浪費は決まったパターンで現れます。頻出順に7つ挙げます。

パターン1:並び替え・表示件数のパラメータURL

?sort=new ?view=list ?per_page=50 のような、中身が実質同じで表示だけが変わるURL。組み合わせで数倍〜数十倍のURLが生成され、クロールを食い潰します。

止め方は2段階です。中身が同じならcanonicalでパラメータなしのURLを指す。そのうえで、クロール自体を止めたいなら robots.txt でパラメータを遮断します。

# robots.txt の例(並び替え・表示切替のみ遮断)
User-agent: *
Disallow: /*?sort=
Disallow: /*?view=
Disallow: /*?per_page=

絞り込み条件のパラメータ(勤務地・年収・こだわり条件など)を同じ扱いにしてはいけません。 これらは中身が変わるため、遮断すると需要のあるページごと失います。開発チームへの依頼では「対象パラメータ」と「対象外パラメータ」を必ず名指しで書き分けます。

パターン2:ページネーションの深部

?page=250 のような深い階層は、内容が薄く、検索需要もほぼありません。しかし一覧テンプレートが機械的にリンクを出していると、Googlebotは律儀に辿ります。

止め方は、ページネーションの上限を設けることです。「並び替えを変えれば別の求人が上位に来る」設計なら、200ページ目以降を辿らせる意味はありません。実装としては、一定ページ以降のリンクを出力しない、または絞り込みへの誘導に置き換えます。

パターン3:サイト内検索結果ページ

/search?q=... は、ユーザーの入力次第で無限にURLが生成されます。外部からリンクされたり、内部の「人気の検索キーワード」モジュールから露出したりすると、クロールが際限なく流れ込みます。

止め方は robots.txt での遮断が基本です。検索結果ページを検索エンジンに登録する必要は、通常ありません。

パターン4:カレンダー等の無限生成

イベントカレンダーの「次の月」リンクは、押し続ける限り無限にURLを生み続けます(2087年12月のイベント一覧まで辿られる)。宿泊施設の空室検索や、日付指定の絞り込みも同じ構造です。

止め方は、未来・過去の到達可能な範囲を実装で制限すること。「データが存在する期間だけリンクを出力する」というルールにします。

パターン5:リダイレクトチェーン

A → B → C → D のような多段リダイレクトは、1ページの取得に複数回のリクエストを消費します。サイトリニューアルを何度か経験したサイトでは、これが数万URL単位で残っていることがあります。

止め方は、中間を飛ばして最終URLへ1回で送ること。同時に、内部リンクとサイトマップが旧URLを指していないかを必ず確認します。リダイレクトを直しても、内部リンクが旧URLのままなら浪費は続きます。

パターン6:404・ソフト404の大量発生

404自体はサイトの評価を下げるものではありませんが、大量に発生していればクロールは確実に消費されます。特に問題なのはソフト404 ——「該当する求人はありません」というページを200で返している状態です。Googleから見れば実質的な空ページであり、クロールもインデックス判定も無駄に消費します。

止め方は、結果0件のページを200で返さないこと。恒久的に存在しないなら404、条件を変えれば結果が出るなら、0件でも意味のある内容(近隣エリアの求人、条件を緩めた候補)を返す設計にします。

パターン7:重複コンテンツ

同一内容が複数URLで到達可能な状態です。DB型サイトでは次が典型です。

• http と https、www あり/なし が両方生きている
• 末尾スラッシュの有無で両方200を返す
• 大文字小文字の違いを吸収していない
• 同じ商品が複数のカテゴリパスから到達できる(/a/item/1 と /b/item/1)

止め方は、正規URLを1つに定め、それ以外は301で寄せること。パス構造由来の重複は、canonicalで正規版を指します。

5. 配り直す:4つの施策

浪費を止めたら、空いた分を主戦場に回します。施策は4つです。

施策1:robots.txt での遮断判断

最も即効性がありますが、最も事故が多い施策でもあります。判断基準を明確にしておきます。

もう1点、robots.txtは既存のインデックスを消す手段ではありません。遮断されたURLは、外部リンクなどから存在が知られていれば、内容不明のままインデックスに残ることがあります。目的が「クロールさせない」なのか「検索結果から消す」なのかを、施策を決める前に言語化してください。

施策2:内部リンクで優先度を伝える

Googleがクロールの必要性を判断する材料のひとつが内部リンクです。サイト内でリンクが集まっているURLほど、重要だと解釈されます。

大規模サイトで効くのは次の3点です。

• 詳細ページから主戦場の一覧ページへ還流させる。詳細ページは枚数が最も多いため、最大のリンク供給源になります。求人詳細から「同じ職種×同じ地域の一覧」へ確実にリンクする
• クリック階層を浅くする。トップから4クリック以上必要なページは、クロール頻度が落ちやすい。主戦場のテンプレートは3クリック以内に収める
• 無価値なURLへのリンクを出力しない。robots.txtで遮断する以前に、そもそもリンクを出さないのが最も確実です

なお、内部リンクに rel="nofollow" を付けてクロールを節約しようとするのは有効ではありません。nofollowはあくまでヒントであり、そのURLが他の場所からリンクされていればクロールされます。リンクを出さないことと、nofollowを付けることは別物です。

施策3:サイトマップのテンプレート分割とlastmod

サイトマップは、クロールの優先度を伝える手段であると同時に、診断の解像度を上げる装置です。

• 1ファイルあたり50,000URL・50MB(非圧縮)が上限。テンプレート単位で分割し、サイトマップインデックスでまとめる
• 分割すると、Search Consoleの「サイトマップ」からテンプレート別のインデックス率が読めるようになる。これが以後の効果測定の基盤になります
• lastmod を正確に出力する。実際の内容更新日時を入れること。全URLを毎日更新扱いにするような運用をすると、シグナルとして信用されなくなります

<!-- サイトマップインデックスの構成例 -->
sitemap-index.xml
 ├ sitemap-area-jobs-1.xml   (職種×地域一覧: 主戦場)
 ├ sitemap-category.xml      (職種・地域一覧)
 ├ sitemap-jobs-1.xml 〜 -6.xml (求人詳細: 30万URL)
 └ sitemap-company.xml       (企業ページ)

施策4:サーバー応答速度の改善

クロール能力の上限を直接押し上げる、唯一の施策です。優先度は「浪費を止める」より低いことが多いものの、Search Consoleの平均応答時間が継続的に1秒を大きく超えているなら、着手する価値があります。

効果が大きい順に、DBクエリの改善(一覧ページの件数カウントが重いケースが多い)、一覧ページのキャッシュ、CDNの適用。加えて、更新のないURLに対して条件付きリクエストで304を返せるようにすると、Googlebot側の取得コストが下がります。

なお、ここで改善すべきはサーバーの応答時間であって、Core Web Vitals(ユーザー体験の指標)ではありません。両者は別の話です。 LCPを改善してもクロール量は増えません。

6. やっても効果が薄いこと

工数を吸われがちな、効果の乏しい打ち手を明示します。

クロール頻度の手動変更を探す

Search Consoleにあったクロール頻度の制限ツールは廃止されており、現在は存在しません。Googlebotは応答状況を見て自動で調整するため、手動で上げる手段はありません。「設定でクロール頻度を上げる」という選択肢は、そもそも存在しないと理解してください。

逆に、サーバー負荷でクロールを一時的に下げたい場合は、503または429を返すのが正しい方法です。ただしこれを長期間続けるとインデックスから削除され始めるため、恒久策にはできません。

URL検査の「インデックス登録をリクエスト」に頼る

個別URLの登録リクエストは、1件ずつしか実行できず、1日の上限もあります。数万〜数百万ページのサイトで、これを運用の中心に据えるのは現実的ではありません。新規テンプレートの初回検証など、数件を確認する用途に限定すべきです。

廃止済みのツールを探す

Search ConsoleのURLパラメータ処理ツールも廃止済みです。パラメータの扱いは、サイト側の実装(canonical・noindex・リンクの出し分け・robots.txt)で制御するしかありません。設定画面を探す時間を、実装要件を書く時間に回してください。

単発の「クロール改善」だけを外注する

クロールは手段であり、目的ではありません。クロールが増えても、インデックスされる中身がなければ流入は増えません。クロール施策は、テンプレートの中身の改善とセットで初めて成果になります(親記事の6章で扱っています)。

7. 効果測定:何を、どの期間で見るか

クロール施策の効果は3段階で、それぞれ現れる時期が違います。ここを取り違えると、効いている施策を途中で止めてしまいます。

数値は一般的な目安であり、サイト規模とクロール頻度によって大きく変動します。重要なのは順序で、1が動かないまま3を待つのは無意味です。2週間経ってもクロール配分が動いていないなら、施策が実装されていないか、リンク経路が残っている可能性を疑ってください。

測定の前提として、リリース日と変更内容の記録を必ず残します。テンプレート改修は影響範囲が広いため、記録がないと後から効果を切り分けられません。リリース日を縦線で入れたグラフを標準の運用にすることを強く推奨します。

8. よくある質問(FAQ)

Q. クロールバジェットを増やす方法はありますか? A. 総量を直接増やす手段はありません。サーバー応答速度を改善してクロール能力の上限を上げること、無価値なURLを減らしてサイト全体のクロール必要性を上げることが間接的な打ち手になります。実務上の効果が大きいのは、総量を増やす試みではなく、既存の配分を主戦場のテンプレートに移すことです。

Q. ページ数は数千規模ですが、対策すべきですか? A. 通常は不要です。その規模でインデックスされないなら、原因はクロールではなくコンテンツ側です。Search Consoleの「ページ」レポートで除外理由を確認し、「クロール済み - インデックス未登録」が多いなら、テンプレートの中身を厚くするか、そもそも生成をやめる判断に進んでください。

Q. インデックスさせたくないページは、robots.txtで遮断すればよいですか? A. いいえ。robots.txtで遮断するとGoogleはページを取得できず、noindexタグを読めないため、かえってインデックスに残り続けます。消したいならクロールさせてnoindexを読ませ、検索結果から消えたことを確認してから、必要に応じてrobots.txtで遮断してください。順序が逆になると事故になります。

Q. サーバーログの分析は、どのくらいの頻度でやるべきですか? A. 初回の診断で1ヶ月分を精査し、その後は月次で同じ集計を回して推移を見る形が現実的です。毎日見る性質のデータではありません。重要なのは、テンプレート別の配分比率を同じ集計ロジックで継続的に取ること(=前月と比較できること)です。集計スクリプトを1本用意して定点化してください。

Q. 開発チームにどう依頼すればよいですか? A. 「クロールバジェットを改善してください」では着手できません。対象・条件・実装・対象外・検証の5点を書いた要件に翻訳します。特に「対象外」の明記が重要で、これがないと開発側が善意で範囲を広げ、育てるべき絞り込みページまで遮断されるという事故が起きます。

【対象】/jobs/ 配下すべてのテンプレート
【条件】クエリパラメータ sort / view / per_page が付与されたURL
【実装】robots.txt に Disallow: /*?sort= /*?view= /*?per_page= を追加
　　　　あわせて、当該パラメータ付きURLへの内部リンク出力を停止する
【対象外】絞り込みパラメータ(area / salary / experience)は内容が変わるため遮断しない
【検証】Search Consoleのrobots.txtレポートで新しいrobots.txtが取得されていることを確認し、
　　　　URL検査で上記6パターンのURLがブロック判定になるかを1件ずつ検証。
　　　　リリース後2週間、クロールの統計情報でクロール数の急減がないことを確認

まとめ:クロールバジェット最適化の手順

1. 規模で判定する(1章) — 数千ページ規模なら対象外。除外理由で切り分ける
2. 定義を正しく持つ(2章) — 能力の上限(サーバー側)と必要性(サイト側)の2要素
3. 配分を測る(3章) — GSCで全体、ログでテンプレート別。アウトプットは配分表1枚
4. 浪費を止める(4章) — パラメータ・深いページネーション・サイト内検索・無限生成・リダイレクト・ソフト404・重複
5. 配り直す(5章) — robots.txtの判断、内部リンク、サイトマップ分割とlastmod、応答速度
6. 存在しない手段を探さない(6章) — クロール頻度設定も、パラメータ処理ツールも廃止済み
7. 3段階で測る(7章) — 配分 → インデックス → 流入。時間差を織り込む

クロールバジェットは、増やす対象ではなく配り直す対象です。そしてその配分は、URLをどう生成し、どこにリンクを出すかという設計の結果でしかありません。つまりクロール最適化の本体は、テクニカルSEOのチェックリスト消化ではなく、サイトの生成設計そのものを見直す作業です。

自社サイトのクロールがどのテンプレートに配分され、どこで浪費されているか——ログとSearch Consoleを使った具体的な診断をご希望の方は、データベース型サイトSEOコンサルティングのページをご覧いただくか、無料相談をご利用ください。月間数億PV規模のDB型サイトを運用してきた知見をもとに、開発要件に落とせる粒度でご提案します。

より広い文脈——クロールの先にあるインデックス制御やテンプレート設計まで含めた全体像は、データベース型サイトのSEO完全ガイドで解説しています。

株式会社ハウクレイジー 代表取締役 関口拓人

早稲田大学在学中に月間数千万PVのメディアをゼロから立ち上げ、株式会社ゲームエイトの創業に参画。同社執行役員として月間3億PV規模サイトのSEO・広告事業を統括。業界No.1プログラミングスクールを運営する株式会社インフラトップのCMOを経て独立し、株式会社ハウクレイジーを設立。大規模メディアからデータベース型サイトまで、累計50サイト以上のマーケティング支援を実施。

プロフィール詳細

どのURL群がクロールを食い潰しているのかは、Search Consoleとサーバーログを突き合わせないと特定できません。診断から配り直しの設計まで無料でご相談いただけます。

無料でクロール配分の診断を依頼する