「新しい記事を公開してもなかなかインデックスされない」「サイトの規模が大きくなるにつれ、SEOの効率が悪くなっている気がする」——このような悩みを抱えているサイト運営者は少なくありません。
その原因の一つとして考えられるのが、クロールバジェットの浪費です。Googleのクローラーがサイトをクロールできる量には限りがあり、不要なページに多くのリソースを使ってしまうと、本当に重要なページのクロールが遅れてしまいます。
この記事では、クロールバジェットの基本概念から、浪費を防ぐための具体的な対策、大規模サイトでの最適化戦略まで、実践的なノウハウを徹底的に解説します。検索エンジンの仕組みを理解した上で、効率的なクロール環境を構築しましょう。
クロールバジェットとは？基本の理解
クロールバジェットの定義
クロールバジェット（Crawl Budget）とは、Googlebot（クローラー）が特定のサイトに対して、一定期間内にクロールできるページ数・リソース量の上限のことです。
Googleは世界中の無数のウェブサイトをクロールする必要があるため、各サイトに割り当てられるクロールリソースには限りがあります。この限られたリソースを「クロールバジェット」と呼びます。
クロールバジェットを構成する2つの要素
Googleの公式ドキュメントによると、クロールバジェットは以下の2つの要素で決まります。
1. クロールレート上限（Crawl Rate Limit）
サーバーに負荷をかけすぎないように設定される、クロールの速度制限です。
- サーバーの応答速度が速い → クロールレートが上がる
- サーバーの応答速度が遅い → クロールレートが下がる
- サーバーエラー（5xx）が多い → クロールレートが大幅に下がる
2. クロール需要（Crawl Demand）
Googleがそのサイトをどれだけクロールしたいかという需要です。
- 人気度：インターネット上で人気のあるURLはより頻繁にクロール
- 鮮度：コンテンツが古くならないよう、定期的にクロール
- サイト全体の変更：大規模な変更があるとクロール需要が増加
クロールバジェットが重要になるサイト
Googleは公式に「ほとんどのサイトでは、クロールバジェットを気にする必要はない」と述べています。では、どのようなサイトでクロールバジェットが重要になるのでしょうか。
クロールバジェットを意識すべきサイト
| サイトの種類 | ページ数の目安 | 理由 |
|---|---|---|
| 大規模サイト | 1万ページ以上 | 全ページをクロールするのに時間がかかる |
| ECサイト | 数千〜数万商品 | 商品ページ、カテゴリページ、フィルター結果が大量に生成 |
| ニュースサイト | 更新頻度が高い | 新しいコンテンツを素早くインデックスする必要がある |
| 動的生成サイト | パラメータで無限生成 | URLパラメータで大量のページが生成される |
| 多言語サイト | 言語数×ページ数 | 同一コンテンツの言語版が大量に存在 |
クロールバジェットをあまり気にしなくてよいサイト
- ページ数が数百〜数千程度の小〜中規模サイト
- 更新頻度が低い静的サイト
- パラメータやフィルターによるページ生成がないサイト
クロールバジェットの浪費とは
クロールバジェットの浪費とは、SEOにとって価値のない（または低い）ページのクロールにリソースが使われ、重要なページのクロールが遅れる・されない状態のことです。
浪費の具体例
- 検索結果ページやフィルター結果など、無限に生成されるページ
- パラメータ違いで同一コンテンツが複数存在
- インデックスすべきでない管理画面、テストページ
- 低品質で価値のないページ
- 404エラーページの大量クロール
- 無限カレンダー、セッションID付きURL
クロールとインデックスの関係
検索エンジンの仕組みで解説しているように、ページが検索結果に表示されるまでには「クロール → インデックス → ランキング」というステップがあります。
クロールされなければインデックスされないため、クロールバジェットの最適化はインデックス登録の前提条件となります。
クロールバジェットの現状を把握する
Googleサーチコンソールでの確認方法
Googleサーチコンソールを使って、クロールの状況を確認しましょう。
クロールの統計情報の確認
- サーチコンソールにログイン
- 左メニュー「設定」→「クロールの統計情報」を選択
- 過去90日間のクロール状況が表示される
確認すべき指標
| 指標 | 内容 | 注目ポイント |
|---|---|---|
| クロールリクエストの合計 | 期間内のクロールリクエスト総数 | 急激な増減がないか |
| 合計ダウンロードサイズ | クロールしたデータ量 | ページサイズの最適化状況 |
| 平均応答時間 | サーバーの応答速度 | 遅い場合は改善が必要 |
| ホスト ステータス | クロールの可用性 | エラーが発生していないか |
クロールリクエストの内訳
「クロールリクエストの内訳」セクションでは、以下を確認できます。
- レスポンス別：200（成功）、301/302（リダイレクト）、404（見つからない）、5xx（サーバーエラー）の割合
- ファイルタイプ別：HTML、画像、CSS、JavaScript等の割合
- 目的別：更新、検出の割合
- Googlebotの種類別：スマートフォン用、PC用の割合
問題の兆候
- 404エラーの割合が高い → 不要なURLへのクロールが多い
- リダイレクトの割合が高い → リダイレクトチェーンの問題
- 5xxエラーがある → サーバーの問題
- 平均応答時間が長い（1秒以上）→ サーバー性能の問題
インデックスカバレッジレポートでの確認
インデックスカバレッジレポート（現在は「ページ」レポート）でも、クロール関連の問題を確認できます。
確認手順
- サーチコンソールで「ページ」レポートを開く
- 「インデックスに登録されなかった理由」を確認
クロール関連の主なステータス
| ステータス | 意味 | 対処 |
|---|---|---|
| クロール済み – インデックス未登録 | クロールされたがインデックスされなかった | コンテンツ品質の改善 |
| 検出 – インデックス未登録 | 検出されたがクロールされていない | クロールバジェット不足の可能性 |
| クロールエラー | クロール時にエラーが発生 | サーバー・URL問題の修正 |
| robots.txtによりブロック | robots.txtでブロックされている | 意図的かどうか確認 |
サーバーログの分析
より詳細な分析には、サーバーのアクセスログを確認します。
確認すべき項目
- Googlebotのアクセス頻度・パターン
- どのURLが頻繁にクロールされているか
- クロールされていないURLはあるか
- クロール時のHTTPステータスコード
ログ分析ツール
- Screaming Frogのログファイル分析機能
- Botify、DeepCrawlなどの専門ツール
- ELK Stack（Elasticsearch、Logstash、Kibana）での自作分析
クロールバジェット浪費の主な原因
原因1：無限に生成されるURL
動的パラメータによって、無限または非常に多くのURLが生成されるケースです。
具体例
- サイト内検索結果：/search?q=〇〇
- フィルター・ソート結果：/products?color=red&size=L&sort=price
- カレンダー：/calendar?year=2025&month=12 → 無限に過去・未来に遷移可能
- セッションID：/page?sessionid=abc123
- ページネーション：/blog?page=1, /blog?page=2, … /blog?page=1000
原因2：重複コンテンツ
重複コンテンツが大量に存在すると、同じコンテンツを何度もクロールすることになります。
具体例
- wwwあり/なし：example.com と www.example.com
- http/https：http://example.com と https://example.com
- 末尾スラッシュ：/page と /page/
- 大文字/小文字：/Page と /page
- パラメータ順序：?a=1&b=2 と ?b=2&a=1
- トラッキングパラメータ：?utm_source=google&utm_medium=cpc
原因3：低品質・価値のないページ
インデックスすべきでない低品質なページがクロールされているケースです。
具体例
- タグページ、アーカイブページ（コンテンツが薄い）
- コメントページ、リプライページ
- 印刷用ページ、PDF版ページ
- テストページ、開発中ページ
- 管理画面、ログインページ
- エラーページ（404、500）
原因4：ソフト404エラー
存在しないページが200（成功）ステータスを返す「ソフト404」は、Googlebotを混乱させ、クロールバジェットを浪費します。
ソフト404の例
- 「ページが見つかりません」と表示されるが、HTTPステータスは200
- 空のコンテンツだが、ステータスは200
- 検索結果ゼロのページ
原因5：ファセットナビゲーション
ECサイトなどで使われるファセットナビゲーション（絞り込み検索）は、大量のURL組み合わせを生成します。
例：アパレルECの場合
- カテゴリ：メンズ、レディース、キッズ（3種類）
- カラー：10色
- サイズ：5サイズ
- 価格帯：5段階
- ソート：5種類
組み合わせ：3 × 10 × 5 × 5 × 5 = 3,750パターン × 基本商品カテゴリ数
原因6：リダイレクトチェーン
リダイレクトが連鎖（チェーン）していると、1つのページをクロールするのに複数のリクエストが必要になります。
例
A → B → C → D（目的のページ）
→ 1ページのクロールに4リクエストが必要
原因7：大きすぎるページサイズ
ページサイズが大きいと、クロールに時間がかかり、クロールバジェットを圧迫します。
問題となるケース
- 巨大な画像ファイル
- 最適化されていないJavaScript/CSS
- 不要なコードの肥大化
原因8：サーバーの応答速度が遅い
サーバーダウンや応答速度の低下は、クロールレートを下げる原因になります。
影響
- 応答が遅い → クロールレート上限が下がる → 結果的にクロールバジェット減少
- サーバーエラーが頻発 → クロールが抑制される
クロールバジェット浪費を防ぐ具体的な対策
対策1：robots.txtでクロールをブロック
robots.txtを使って、クロールすべきでないURLパターンをブロックします。
基本構文
User-agent: *
Disallow: /search
Disallow: /admin/
Disallow: /*?sessionid=
Disallow: /*?sort=
Disallow: /*?filter=ブロックすべきURLの例
| URL種類 | robots.txt設定 |
|---|---|
| サイト内検索結果 | Disallow: /search |
| 管理画面 | Disallow: /admin/ |
| ログイン関連 | Disallow: /login |
| カート・決済 | Disallow: /cart |
| セッションID付き | Disallow: /*?sessionid= |
| ソートパラメータ | Disallow: /*?sort= |
| 印刷用ページ | Disallow: /*?print= |
注意点
- robots.txtでブロックしても、外部リンクがあるとURLだけがインデックスされることがある
- 完全にインデックスさせたくない場合はnoindexと併用
- 変更後はサーチコンソールのrobots.txtテスターで検証
対策2：noindexタグの活用
noindexタグは、クロールは許可するがインデックスはさせない設定です。
使い分け
| 目的 | robots.txt | noindex |
|---|---|---|
| クロールさせない（バジェット節約） | ○ | × |
| インデックスさせない | △ | ○ |
| 両方 | ○ | ○（併用） |
noindexが適切なケース
- タグページ、アーカイブページ
- サンクスページ、完了ページ
- 重複コンテンツページ（canonicalと併用も検討）
- 一時的なキャンペーンページ
実装例
<meta name="robots" content="noindex, follow">「noindex, follow」は、インデックスはさせないが、ページ内のリンクは辿ることを許可する設定です。
対策3：canonicalタグで正規URLを指定
canonicalタグを使って、重複コンテンツの正規版を明示します。
実装例
<!-- パラメータ付きURLから、パラメータなしURLを正規版として指定 -->
<link rel="canonical" href="https://example.com/products/item-001/">canonicalが有効なケース
- ソート順の違い（?sort=price, ?sort=name）
- トラッキングパラメータ付きURL
- 同一商品の色違いページ（場合による）
- 印刷用ページ
注意点
- canonicalはヒントであり、Googleが必ず従うわけではない
- 明らかに別コンテンツにcanonicalを設定しない
- 相対URLではなく絶対URLを使用
対策4：URLパラメータの処理
パラメータ付きURLの処理を適切に行うことで、クロールの効率化が可能です。
パラメータの種類と対処法
| パラメータの種類 | 例 | 推奨対処 |
|---|---|---|
| ソート順 | ?sort=price | canonical、robots.txt |
| フィルター | ?color=red | canonical、noindex |
| ページネーション | ?page=2 | rel=”prev/next”（非推奨）、noindex |
| トラッキング | ?utm_source=google | canonical |
| セッション | ?sessionid=abc | robots.txt、URLから除去 |
URLパラメータツール（廃止済み）
以前はサーチコンソールに「URLパラメータツール」がありましたが、現在は廃止されています。代わりに、robots.txt、canonical、noindexを組み合わせて対処します。
対策5：ページネーションの最適化
ページネーションのSEO対策はクロールバジェットにも影響します。
対策オプション
- 無限スクロール + 静的ページ：ユーザーには無限スクロール、Googlebotには静的ページを提供
- 「もっと見る」ボタン：ページネーションではなく、同一ページで追加読み込み
- 2ページ目以降をnoindex：1ページ目のみインデックス
- View All ページ：全件表示ページを作成し、canonicalを設定
ベストプラクティス
- 1ページ目は必ずインデックス対象
- 2ページ目以降は状況に応じてnoindexまたはcanonical
- ページ番号が極端に多い場合は、カテゴリ分割を検討
対策6：サイト構造の最適化
サイト構造設計を改善し、クローラーが効率的に巡回できるようにします。
最適化のポイント
- フラットな構造：重要なページはトップから2〜3クリック以内
- 明確な階層構造：カテゴリ → サブカテゴリ → 詳細ページ
- 内部リンクの充実：関連ページ同士をリンク
- 孤立ページの解消：どこからもリンクされていないページをなくす
クローラビリティを高める方法も参考にしてください。
対策7：XMLサイトマップの最適化
XMLサイトマップを適切に設定することで、Googleに重要なページを明示できます。
最適化のポイント
- インデックスさせたいページのみ含める：noindexページ、robots.txtでブロックしているページは含めない
- lastmodを正確に設定：実際の更新日を反映
- サイトマップを分割：大規模サイトでは種類別（商品、ブログ、カテゴリ等）に分割
- サイトマップインデックス：複数サイトマップをまとめるインデックスファイルを作成
サイトマップの例
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/products/item-001/</loc>
<lastmod>2025-01-10</lastmod>
</url>
</urlset>対策8：404エラーの適切な処理
存在しないURLが大量にクロールされている場合は、対処が必要です。
対処法
- 正しい404ステータスを返す：ソフト404を解消
- リダイレクト：削除したページは類似ページに301リダイレクト
- 外部リンクの修正依頼：可能であれば、誤ったURLへのリンクを修正してもらう
- robots.txtでブロック：特定パターンの不要URLをブロック
対策9：リダイレクトチェーンの解消
リダイレクトチェーン（A→B→C）を、直接リダイレクト（A→C）に修正します。
確認方法
- Screaming Frogでサイトをクロール
- 「Redirect Chains」レポートを確認
- チェーンになっているリダイレクトを特定
修正方法
- .htaccessまたはリダイレクトプラグインで、直接最終URLにリダイレクト
- 中間のリダイレクトを削除
対策10：サーバー応答速度の改善
ページ表示速度を改善することで、クロールレート上限が向上します。
改善施策
サイト種類別のクロールバジェット最適化戦略
ECサイトの場合
ECサイトのSEO対策において、クロールバジェットは特に重要な課題です。
ECサイト特有の問題
- ファセットナビゲーション：色、サイズ、価格帯などの組み合わせで大量のURL生成
- 商品バリエーション：同一商品の色違い、サイズ違いページ
- 在庫切れページ：販売終了商品のページが残存
- ソート・フィルター：並び替え、絞り込みのパラメータ
対策の優先順位
- ファセットナビゲーションの制御
- 主要なフィルター組み合わせのみインデックス対象
- それ以外はrobots.txtでブロックまたはnoindex
- JavaScriptでフィルターを実装し、URLを変更しない方法も検討
- 商品バリエーションの統合
- 色違い・サイズ違いは1つの商品ページに統合
- または、代表バリエーションにcanonicalを集約
- 在庫切れ商品の処理
- 一時的な在庫切れ：ページを維持、在庫切れ表示
- 完全な販売終了：類似商品へリダイレクトまたは404
- ソートパラメータの処理
- すべてのソート結果からデフォルトソートにcanonical
- または、robots.txtでソートパラメータをブロック
ECサイト向けrobots.txt例
User-agent: *
# ファセットナビゲーション
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*?price=
Disallow: /*?brand=
# ソート・表示件数
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?per_page=
# カート・決済
Disallow: /cart
Disallow: /checkout
Disallow: /my-account
# 検索
Disallow: /search
# 複合パラメータ（&を含むURL）
Disallow: /*?*&*
Sitemap: https://example.com/sitemap.xmlニュースサイト・メディアサイトの場合
ニュースサイトでは、新しい記事を素早くインデックスさせることが特に重要です。
特有の問題
- 記事の大量生成：毎日多数の記事が公開される
- アーカイブページ：日付別、カテゴリ別、著者別など多数存在
- タグページ：タグの組み合わせで大量生成
- コメントページ：記事へのコメントがページ化
対策
- アーカイブページの制御
- 日付アーカイブはnoindexに
- 著者ページは重要な著者のみインデックス
- タグページの整理
- 記事数が少ないタグはnoindex
- 類似タグの統合
- XMLサイトマップの活用
- News Sitemapの導入
- 新着記事を優先的にクロールさせる
- ページネーションの処理
- 一覧ページの2ページ目以降はnoindex
多言語サイトの場合
多言語サイトのSEO対策では、言語版ごとにページが増えるため、クロールバジェットへの配慮が必要です。
特有の問題
- ページ数の倍増：10言語対応なら単純計算で10倍のページ数
- 未翻訳ページ：一部言語でコンテンツがない場合
- 重複コンテンツ：自動翻訳による低品質な翻訳ページ
対策
- hreflangタグの正確な実装
- hreflangタグで言語版の関係を明示
- Googleが効率的に各言語版をクロール
- 未翻訳ページの処理
- 翻訳版がない言語へのリンクを非表示
- または、デフォルト言語にリダイレクト
- 言語別XMLサイトマップ
- 言語ごとにサイトマップを分割
- 各言語のコンテンツ状況を把握しやすくする
大規模コーポレートサイトの場合
大企業のコーポレートサイトでは、部門ごとのコンテンツが蓄積し、肥大化しがちです。
特有の問題
- 古いコンテンツの蓄積：過去のプレスリリース、イベント情報
- 部門別サイト：各部門が独自にコンテンツを追加
- PDFファイルの大量存在：資料、レポートのPDF
対策
- 古いコンテンツの整理
- 価値のないページは削除またはnoindex
- リライトで最新化できるものは更新
- PDFの最適化
- 重要なPDFは専用HTMLページを作成
- 不要なPDFはrobots.txtでブロック
- サブドメイン/サブディレクトリの整理
- 不要になったサブドメインの整理
- サイト構造の見直し
高度なクロールバジェット最適化テクニック
動的レンダリングの活用
JavaScriptサイトの場合、動的レンダリング（Dynamic Rendering）を活用することで、クローラーの負荷を軽減できます。
仕組み
- ユーザーからのリクエスト → 通常のJavaScript版を返す
- Googlebotからのリクエスト → 事前にレンダリングした静的HTML版を返す
メリット
- Googlebotがレンダリングする必要がなくなり、クロール効率が向上
- JavaScriptレンダリングの問題を回避
注意点
- クローキングにならないよう、コンテンツは同一にする
- Googleは将来的にSSRを推奨としており、動的レンダリングは暫定的な解決策
クロール優先度の制御
重要なページを優先的にクロールさせるためのテクニックです。
内部リンク構造による制御
- 重要なページへのリンクを増やす：トップページ、グローバルナビ、サイドバーからリンク
- 不要なページへのリンクを減らす：フッターの肥大化を避ける
- リンクの位置：ページ上部のリンクが優先されやすい
XMLサイトマップでの優先度
XMLサイトマップの<priority>タグは、Googleによると「あまり考慮されない」とされていますが、lastmodは重要です。
- lastmodを正確に：更新されたページは新しい日付を設定
- 頻繁に更新されるページ：サイトマップも頻繁に更新
クロール頻度のモニタリングと分析
定期的にクロール状況をモニタリングし、問題を早期に発見します。
モニタリング項目
| 項目 | 確認頻度 | ツール |
|---|---|---|
| クロールの統計情報 | 週次 | サーチコンソール |
| インデックス状況 | 週次 | サーチコンソール |
| サーバーログ | 月次 | ログ分析ツール |
| クロールエラー | 週次 | サーチコンソール |
異常の兆候
- クロール数の急激な減少
- 404エラーの増加
- 新しいページのインデックスが遅い
- 重要なページがインデックスされない
A/Bテストとクロールバジェット
A/Bテストを行う際、クロールバジェットへの影響を考慮する必要があります。
注意点
- テストバリエーションをGooglebotに見せると、重複コンテンツと判断される可能性
- URLを変えるA/Bテストは、ページ数が増加しクロールバジェットを消費
推奨アプローチ
- サーバーサイドでのA/Bテスト
- Googlebotには常にオリジナル版を表示
- canonicalタグでオリジナルを指定
WordPressサイトでのクロールバジェット最適化
WordPressで発生しやすい問題
WordPressのSEO設定において、クロールバジェット関連の問題が発生しやすいポイントです。
よくある問題
- タグ・カテゴリアーカイブ：大量のタグページが生成
- 日付アーカイブ：年/月/日ごとのアーカイブページ
- 著者アーカイブ：著者ごとの記事一覧
- 添付ファイルページ：画像ごとにページが生成
- ページネーション：/page/2/, /page/3/…の大量生成
- 検索結果：/?s=〇〇の無限パターン
SEOプラグインでの対策
Yoast SEOの場合
Yoast SEOで以下の設定を行います。
- 「検索での見え方」→「タクソノミー」
- タグアーカイブを「検索結果に表示しない」（noindex）に設定
- 「検索での見え方」→「アーカイブ」
- 日付アーカイブを「無効化」または「noindex」
- 著者アーカイブを「無効化」（単一著者の場合）
- 「検索での見え方」→「メディア」
- 添付ファイルページを「添付ファイルURLを添付先にリダイレクト」に設定
All in One SEOの場合
All in One SEOでも同様の設定が可能です。
Rank Mathの場合
Rank Mathでは、より細かい制御が可能です。
functions.phpでの制御
プラグインを使わずに、functions.phpでも制御できます。
// 検索結果をnoindexに
function add_noindex_to_search() {
if (is_search()) {
echo '<meta name="robots" content="noindex, follow">';
}
}
add_action('wp_head', 'add_noindex_to_search');
// 日付アーカイブを無効化
function disable_date_archives() {
if (is_date()) {
wp_redirect(home_url('/'));
exit();
}
}
add_action('template_redirect', 'disable_date_archives');robots.txtの設定
WordPressのrobots.txt例：
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=
Disallow: /tag/*/page/
Disallow: /category/*/page/
Sitemap: https://example.com/sitemap_index.xmlクロールバジェット最適化のチェックリスト
初期診断チェックリスト
現状把握
- □ サーチコンソールで「クロールの統計情報」を確認
- □ 「ページ」レポートでインデックス状況を確認
- □ site:検索でインデックス数を確認
- □ 実際のページ数とインデックス数を比較
問題の特定
- □ 404エラーの割合を確認
- □ リダイレクトの割合を確認
- □ 「検出 – インデックス未登録」のページを確認
- □ 重複コンテンツの有無を確認
- □ パラメータ付きURLの状況を確認
対策実施チェックリスト
robots.txt
- □ 不要なディレクトリをブロック
- □ 検索結果ページをブロック
- □ パラメータ付きURLをブロック
- □ robots.txtテスターで検証
noindex設定
- □ タグ・アーカイブページをnoindex
- □ 薄いコンテンツのページをnoindex
- □ 重複ページをnoindex（またはcanonical）
canonical設定
- □ パラメータ違いページにcanonical
- □ 正規URLへの統一
- □ 自己参照canonicalの確認
XMLサイトマップ
- □ インデックス対象ページのみ含める
- □ noindexページを除外
- □ lastmodを正確に設定
- □ サーチコンソールで送信
サイト構造
- □ リダイレクトチェーンを解消
- □ 404エラーの処理
- □ 内部リンク構造の最適化
定期メンテナンスチェックリスト
週次
- □ サーチコンソールでクロールエラーを確認
- □ 新規ページのインデックス状況を確認
月次
- □ クロールの統計情報の推移を確認
- □ インデックス数の推移を確認
- □ 新たな重複コンテンツがないか確認
四半期
- □ Screaming Frogで全体診断
- □ robots.txtの内容見直し
- □ XMLサイトマップの内容確認
- □ 不要になったコンテンツの整理
よくある質問（FAQ）
Q1: クロールバジェットは具体的に何ページですか？
A: Googleはクロールバジェットの具体的な数値を公開していません。サイトの規模、品質、更新頻度、サーバー性能などによって動的に決まります。サーチコンソールの「クロールの統計情報」で、実際のクロール数を確認できます。
Q2: 小規模サイトでもクロールバジェットを気にすべきですか？
A: 数百〜数千ページ程度の小〜中規模サイトでは、通常クロールバジェットを気にする必要はありません。ただし、パラメータで大量のURLが生成される場合や、重複コンテンツが多い場合は対策が必要です。
Q3: robots.txtでブロックするのとnoindexを設定するのは何が違いますか？
A: robots.txtはクロール自体をブロックするため、クロールバジェットを節約できます。noindexはクロールは許可するがインデックスはさせない設定です。外部からリンクされているページは、robots.txtでブロックしてもURLだけがインデックスされることがあるため、確実にインデックスさせたくない場合はnoindexを使用します。
Q4: クロールバジェットを増やすことはできますか？
A: 直接的に「増やす」ことはできませんが、以下の施策でクロールレート上限を高めることができます。①サーバーの応答速度を改善、②サーバーエラーを解消、③サイト全体の品質を向上、④被リンクを増やし人気度を上げる。
Q5: XMLサイトマップのpriority（優先度）は効果がありますか？
A: Googleは公式に「priorityはあまり考慮しない」と述べています。lastmod（最終更新日）の方が重要です。priorityを設定するより、不要なページをサイトマップから除外することに注力しましょう。
Q6: 「検出 – インデックス未登録」が多いのはクロールバジェットの問題ですか？
A: 必ずしもそうとは限りません。「検出 – インデックス未登録」は、URLは検出されたがまだクロールされていない状態を示します。原因として、①クロールバジェット不足、②ページの優先度が低い、③サイト構造の問題（内部リンクがない）、などが考えられます。重要なページがこの状態にある場合は、内部リンクの強化やXMLサイトマップへの追加を検討してください。
Q7: サイトリニューアル時にクロールバジェットで注意すべきことは？
A: サイトリニューアル時のSEO対策を参照してください。特に、①旧URLから新URLへの301リダイレクト設定、②リダイレクトチェーンを避ける、③XMLサイトマップの更新、④不要になったページの整理、が重要です。
Q8: JavaScriptサイトはクロールバジェットに影響しますか？
A: はい、影響します。JavaScriptサイトのSEO対策で解説していますが、Googlebotは2段階（クロール→レンダリング）でJavaScriptを処理するため、通常のHTMLサイトより多くのリソースを消費します。SSR（サーバーサイドレンダリング）の導入を検討してください。
まとめ：クロールバジェットの最適化でSEO効率を最大化
クロールバジェットの最適化は、特に大規模サイトにおいてSEOの成功に直結する重要な施策です。本記事で解説した内容をまとめると、以下のポイントが重要です。
クロールバジェット最適化の基本原則
- まず現状を把握する
- サーチコンソールでクロールの統計情報を確認
- 問題の有無を客観的に判断
- 不要なクロールを排除する
- robots.txtで不要URLをブロック
- noindexでインデックス不要ページを指定
- canonicalで重複を統合
- 重要なページを優先させる
- 内部リンク構造の最適化
- XMLサイトマップの整備
- サイト構造の改善
- サーバー性能を向上させる
- 継続的にモニタリングする
- 定期的なクロール状況の確認
- 問題発生時の早期対応
今日から始められるアクション
- 現状確認：サーチコンソールの「クロールの統計情報」を確認し、問題がないかチェック
- robots.txt確認：現在のrobots.txtの内容を確認し、不要なURLがブロックされているか確認
- インデックス状況確認：「ページ」レポートで「検出 – インデックス未登録」のページを確認
- サイトマップ確認：XMLサイトマップにnoindexページが含まれていないか確認
- 優先度の高い問題から対処：404エラー、リダイレクトチェーン、重複コンテンツの順に対処
クロールバジェットの最適化は、テクニカルSEOの重要な要素です。インデックス登録の問題や、インデックスから消えた記事の復活と併せて対策することで、サイト全体のSEO効率を最大化できます。
クロールバジェットの問題でお困りの方や、大規模サイトのテクニカルSEO診断をご希望の方は、ぜひOMNIWEBにご相談ください。サイトの規模や特性に応じた最適なクロール戦略をご提案いたします。
