Domain 25 / 225

クロール予算は大規模サイトで Googlebot が回せる URL 数の上限

クロール予算の要点

クロール予算は Googlebot がサイトに割くクロール時間の上限で、サーバー応答速度（容量）と Google の関心度（需要）で決まる。1 万ページ以下のサイトは気にしなくていい。大規模サイトはファセットナビ / セッション ID / カレンダー無限 URL でクロール予算を消費するので robots.txt 除外で守る

なぜこれを学ぶか

クロール予算は大規模サイト（10 万ページ以上 / EC / 大型メディア）でインデックス漏れを起こす最大要因。無限に増えるパラメータ URL や低品質ページに Googlebot のリソースを取られて、本来クロールしてほしい新規記事や重要商品ページが発見されない事故が起きる。

EC・ニュースメディア・SaaS でリプレイス・リニューアル時に必須の設計知識。

学ばないと起きること

よくある事故	被害
ファセットナビゲーションを robots.txt で除外せず放置	数百万 URL を Googlebot が巡回、新規重要ページが発見されない
セッション ID を URL に入れる	同じページが無数の URL として扱われ、クロール予算が消費される
無限カレンダー（未来日 URL 自動生成）を放置	Googlebot がループ、サイト全体のクロール頻度が下がる
サーバー応答が遅い（5 秒超）	Google が「速度を落とす」と判断、クロール頻度が大幅減
5xx エラーを返し続ける	12 時間で全クロール停止、30 日後に「サイトが応答しない」扱いに
重複コンテンツを放置	クロール予算がコピーページに分散、独自コンテンツのインデックスが遅延

学ぶメリット

大規模サイトの SEO 設計でクロール予算を意識した URL 設計ができる
Search Console のクロール統計から問題を切り分けられる
ファセットナビ / セッション ID / カレンダーの SEO 上のリスクを商談で即答できる
「1 万ページ以下なら気にしなくていい」を即答できれば判断力を示せる

サーバー応答時間が速い → 容量大
5xx エラーや 429 が多い → 容量小（Google が自動で減らす）
帯域幅 / インフラ性能

需要（Crawl Demand）

Google がそのサイトをどれだけクロールしたいか。

インデックス済み URL の数
ページの人気度（被リンク・流入）
更新頻度
新規 URL の発見数

サイト規模別の必要性

サイト規模	クロール予算を気にすべきか
1 万ページ以下	気にしなくていい（公式立場）
1-10 万ページ	多少注意、頻繁な URL 変更があるなら対策
10 万ページ以上	必須、URL 設計とクロール制御を組む
EC / メディア / SNS（数百万ページ）	設計の中心トピック

Search Console クロール統計の読み方

「設定 > クロール統計」で確認できる主要指標:

指標	意味
クロールリクエスト数	1 日あたり Googlebot が送ったリクエスト数
平均応答時間	サーバーが返すまでの時間
ホストの状態	サーバーが正常かどうか
クロール目的	検出 / リフレッシュの内訳
HTTP ステータス別内訳	200 / 3xx / 4xx / 5xx の割合
ファイルタイプ別内訳	HTML / CSS / JS / 画像の比率

5xx の割合が高い、クロール頻度が急増 / 急減した、を発見するのに使う。

/products?color=red
/products?color=red&size=M
/products?color=red&size=M&brand=nike
/products?color=red&size=M&brand=nike&price=10000-20000
...

対処: robots.txt で Disallow: /products?*sort=* のようにパラメータ URL を除外。

セッション ID URL

/page?sessionid=abc123
/page?sessionid=def456
...（同じページが無数の URL）

対処: クッキーに移行、または canonical でパラメータなし URL を正規指定。

無限カレンダー

/calendar?d=1&m=1&y=2050
/calendar?d=2&m=1&y=2050
...（未来日も無限生成）

対処: 未来日リンクに rel="nofollow" を付ける、または robots.txt で除外。

ソート・並べ替えパラメータ

/products?sort=price-asc
/products?sort=price-desc
/products?sort=name-asc
/products?sort=newest

コンテンツは同じなのに URL だけ違う。canonical で正規 URL に集約 + robots.txt 除外。

急にクロール頻度が下がった時

考えられる原因:

サーバー応答が遅くなった（CDN 障害 / DB 過負荷）
5xx エラーが急増
robots.txt で大量 URL を Disallow した
サイトの更新頻度が下がった
直近のコアアップデートで需要が減った

Search Console のクロール統計で平均応答時間と HTTP ステータス別内訳を確認。

クロール頻度を意図的に下げたい場合

サーバー過負荷時の緊急対応:

方法	効果
5xx / 429 を返す	Google が自動でクロール頻度を下げる（短期 1-2 日のみ推奨）
Search Console クロール頻度の設定	廃止された機能、現在は使えない
特別申請（GoogleBot Report）	例外的にクロール頻度減少を申請可能

5xx を 1-2 日以上返し続けると、URL がインデックスから消える可能性があるので長期は NG。

よくある誤解

よくある誤解	実際のところ	出典
すべてのサイトでクロール予算を最適化すべき	1 万ページ以下のサイトは気にしなくていい（公式立場）	大規模サイトのクロール予算管理
クロール頻度が高い = SEO に良い	必ずしも違う。低品質 URL のクロールが多いと逆効果	同上
クロール予算を増やす設定がある	ない。Google の自動判定で決まる	同上
robots.txt で Disallow したページはクロール予算を使わない	その通り。クロール予算保護の主要手段	同上
canonical を打てばクロール予算が節約できる	canonical は重複統合用、クロール予算節約効果は限定的	同上
サーバーが速ければクロール頻度が無限に上がる	上がる傾向はあるが、Google の需要側でも上限がある	同上
Search Console「クロール頻度の設定」で減らせる	廃止された機能、現在は使えない	クロール頻度の削減
5xx を返せばずっとクロール頻度を抑えられる	1-2 日以上返すと URL がインデックスから消える	同上

実務での適用

大規模 EC サイトの URL 設計

メイン商品 URL は canonical（パラメータなし）
ファセット組み合わせは robots.txt で Disallow: /products?*color=*&size=*
セッション ID はクッキーに移行
検索結果ページ（/search?q=...）は noindex + Disallow
ソート・並べ替えは canonical で集約

Search Console の定期チェック

毎週または毎月チェックすべき項目:

クロール統計の平均応答時間（500ms 以内目標）
5xx エラーの割合（1% 以下が理想）
クロール頻度の急変動
ホストの状態（緑であること）

サイトマップで重要 URL を Google に伝える

クロール予算を本来クロールしてほしい URL に集中させるため:

重要 URL のみサイトマップに含める
削除した URL や noindex URL は含めない
lastmod を正確に保つ

トラブル別の対処

症状	確認すべきこと
新規ページがなかなかインデックスされない	クロール予算が低品質 URL に消費されていないか、ファセットナビの除外
Search Console「クロール統計」で平均応答時間が長い	サーバー / DB / CDN のパフォーマンス調査
クロール頻度が急減した	5xx 多発、robots.txt 変更、サイト全体評価の変化
Googlebot のリクエスト数が異常に多い	ファセットナビ / カレンダー / セッション ID の組み合わせ爆発

公式ソース

自己テスト

Q1. クロール予算を構成する 2 要素は？

容量（Crawl Capacity = サイトのクロール耐性）と需要（Crawl Demand = Google のクロールしたい度合い）の組み合わせ

Q2. 1,000 ページ規模のサイトもクロール予算を最適化すべきか？

公式立場では 1 万ページ以下は気にしなくていい。10 万ページ以上の大規模サイトで初めて重要になる

Q3. ファセットナビゲーションがクロール予算を消費する理由は？

フィルタ組み合わせで URL が組み合わせ爆発し、Googlebot が無数の URL を巡回して本来重要な URL に到達できなくなる

Q4. クロール頻度を急に下げたい場合の方法は？

5xx / 429 を返すと Google が自動でクロール頻度を下げる。ただし 1-2 日以上続けると URL がインデックスから消える可能性があるので長期は NG

Q5. canonical を打てばクロール予算が節約できるか？

限定的。canonical は重複統合用で、Google は重複 URL もクロールしてから判定するため、節約効果は robots.txt の Disallow ほど強くない

Q6. セッション ID を URL に入れるとクロール予算にどう影響するか？

同じページが無数の URL として扱われ、クロール予算が消費される。クッキーに移行するのが正しい対処

Q7. Search Console「クロール頻度の設定」で頻度を変更できるか？

できない。この機能は廃止された。Google の自動判定で決まる

Q8. クロール予算を本来クロールしてほしい URL に集中させる方法は？

重要 URL のみサイトマップに含める / 不要 URL を robots.txt で Disallow / canonical で重複統合 / 内部リンクを重要ページに集中

これらの内容を採点付きで挑戦したい場合は、本ドメインのプロ試験で 5 問形式で確認できる。