ECサイトのクロールバジェットとは？大規模サイトでの改善方法
目次
クロールバジェットとは、検索エンジンが一つのサイトをどの程度クロールでき、クロールしたいと考えるかをまとめた概念です。商品数が少なく更新も穏やかなサイトでは、優先課題にならないことが多く、サイトマップとインデックス状況の確認で十分な場合があります。
商品やパラメータURLが非常に多く、更新が速いECサイトでは、不要URLへのクロールが重要商品への発見・更新を遅らせることがあります。回数を増やす施策ではなく、URL在庫とサーバー応答を整えることが中心です。
クロールバジェットを気にすべきサイト
Googleの公式案内では、非常に大規模なサイト、1万URL以上で日々大きく内容が変わるサイト、「検出・インデックス未登録」が多いサイトなどが主な対象です。これらの数は厳密な境界ではなく目安です。
新商品が公開当日にクロールされ、重要ページの更新も反映されているなら、クロールバジェットの調整より、商品内容やカテゴリ設計を優先します。
クロール能力とクロール需要
検索エンジンはサーバーを過負荷にしない範囲で取得量を調整します。5xxや429、応答遅延が増えると、クロールを一時的に減らすことがあります。
一方で、人気、更新頻度、内容の価値などから、どのURLをどれだけ再取得したいかも判断されます。サーバーを速くするだけでも、URLを減らすだけでも完結しません。
URL在庫を把握する
商品、カテゴリ、記事、検索結果、絞り込み、並び替え、トラッキング、エラーなど、ページ種別ごとのURL数を推定します。サイト内リンク、XMLサイトマップ、Search Console、サーバーログを組み合わせます。
公開商品数に対してクロール可能URLが何倍もある場合、どの機能が増加源かを調べます。パラメータの種類と組み合わせを数えると、影響範囲が見えます。
重複URLを減らす
セッションID、計測パラメータ、並び替え、同じフィルタ条件の表記違いなど、同じ内容を返すURLを内部リンクから外します。可能ならURL生成自体を止め、正規形式へ統一します。
canonicalは重複整理の手掛かりですが、検索エンジンが重複と判断するにはURLを取得することがあります。不要なURLを無制限に生成し、canonicalだけで対処する設計は避けます。
絞り込みとサイト内検索を管理する
色、サイズ、価格、ブランドなどを自由に組み合わせると、商品数以上のURLが作られます。検索需要があり管理できる条件だけを固定の着地ページとして整え、それ以外は内部リンクやURL生成を制限します。
自由入力のサイト内検索結果を検索対象へ広く公開すると、ほぼ無限のURLが生まれます。利用者向け機能と検索着地ページを分けます。
サイトマップを最新にする
XMLサイトマップには、200で表示される正規URLを含めます。商品、カテゴリ、記事を分けると、ページ種別ごとの検出と登録状況を追いやすくなります。
lastmodは実際の重要な更新と一致させます。全URLを毎日更新扱いにすると、本当に変わった商品を区別しにくくなります。
HTTPキャッシュを活用する
内容が変わっていないページでは、ETagやLast-Modifiedを使い、条件付きリクエストへ304を返すことでサーバー資源を節約できます。商品データの更新とキャッシュ判定を一致させることが前提です。
CDNやページキャッシュも応答安定に役立ちますが、価格や在庫が古くならないようにします。動的部分と静的部分を分ける設計を検討します。
5xxと429を減らす
セール、在庫一括更新、商品フィード生成の時間帯にエラーが増えていないかを確認します。Googlebotのリクエストだけを原因とせず、データベースやAPIのボトルネックを調べます。
不要URLを減らすと同時に、重要ページへ安定して200を返せる容量を確保します。障害時のステータスと復旧監視も用意します。
サーバーログを分析する
ログからGooglebotのアクセスURL、ステータス、応答時間、日時を集計します。ボットの識別はUser-Agentだけに頼らず、必要に応じて公式の検証方法を使います。
重要商品、新商品、パラメータURL、404など種別ごとに分けると、クロールの偏りが見えます。月ごとの件数だけではなく、公開から初回クロールまでの時間も確認します。
よくある間違い
- 小規模サイトでも最優先にする
- クロール回数が増えれば順位も上がると考える
- 不要URLを生成し続けcanonicalだけに頼る
- 全URLのlastmodを毎日更新する
- サーバーエラーと応答時間を見ない
確認項目
- クロールバジェット対策が必要な規模か
- ページ種別ごとのURL数を把握したか
- パラメータとサイト内検索URLを管理しているか
- サイトマップが正規URLと正確なlastmodを持つか
- 5xx、429、応答時間を監視しているか
- ログで重要ページへのクロールを確認したか
クロール効率の改善計画を作る
ログとURL一覧から、重要、重複、操作用、エラー、廃止へ分類します。重要URLには安定した内部リンクとサイトマップを用意し、重複・操作用URLは発生源とリンク生成を見直します。
施策ごとに、対象URL数、想定する削減、開発負荷、利用者機能への影響を整理します。利用者が必要な絞り込みを単に削除するのではなく、画面機能を保ったまま検索対象URLを制御する方法を検討します。
robots.txtだけで解決しない
不要URLをrobots.txtで塞ぐと、クロールは抑えられますが、すでに知られたURLの内容やcanonicalを確認できません。外部リンクやサイト内リンクが残る限り、URLの存在自体は知られ続けます。
まず内部リンクを正規URLへ統一し、URL生成を抑え、重複は転送やcanonicalで整理します。その上で、取得する必要がない無限空間などへrobots.txtを使います。
商品更新の優先度を高める
新商品や価格・在庫が頻繁に変わる商品を、更新の少ないアーカイブと同じ扱いにしません。サイトマップのlastmod、主要カテゴリの新着リンク、安定した応答を通じて更新を伝えます。
全商品を毎日更新したように見せるのではなく、本当に変わったURLを正確に示します。クロールを要求する小技より、変更情報の信頼性が重要です。
改善結果を評価する
不要パラメータへのクロール割合、重要URLの最終クロール日、新商品公開から初回クロールまで、5xxと応答時間を比較します。総クロール数が減っても、重要URLへの到達が改善していれば目的に合います。
インデックスや検索流入も確認しますが、クロール効率だけで順位上昇を保証しません。商品内容、内部リンク、需要、競合と合わせて評価します。
ECサイトでの調査例
公開商品が10万件なのにログ上のURL種類が数百万ある場合、クエリパラメータを分類します。色、サイズ、並び順、表示件数、セッション、計測のうち、どの組み合わせが大半を占めるかを確認します。
並び順と表示件数が同じ商品集合を返すだけなら、内部リンクを基本カテゴリへ統一し、操作状態を検索対象から分けます。需要のある「黒・防水」などは固定ページとして整え、任意の組み合わせとは別管理にします。
改善後は、総クロール数ではなく、正規商品への割合、新商品の初回クロール、パラメータURLの減少、サーバー応答を比較します。利用者の絞り込み機能が保たれているかも操作テストします。
改善を段階的に進める
大量URLを一度にブロックすると、必要な商品やカテゴリまで発見経路を失う可能性があります。一つのパラメータ群やカテゴリで先行し、クロール、インデックス、利用者の操作を確認します。
問題がなければルールを広げます。対象URL、実施日、期待する変化、戻し方を記録し、robots.txt、noindex、canonicalを同時に大きく変えて原因を追えなくしないようにします。
まとめ
クロールバジェットは、主に大規模・高頻度更新サイトで重要になる考え方です。ECサイトでは、無限に増える操作用URLを整理し、重要ページへ安定した応答と発見経路を用意します。
まず対策が必要な規模かを判断し、URL在庫、サイトマップ、サーバーログ、エラーを確認してください。クロールを増やすのではなく、価値あるURLへ使われやすい構造を作ることが改善です。
