商品数万規模の クロールバジェットと索引漏れ管理
商品が数万点あるモールで、新商品の索引が遅い。Search Consoleを見ると「検出 - インデックス未登録」が万単位で残っている。数万点規模のカタログを持つショップからは、クロールバジェットの管理についての相談が届きます。
クローラーには、一定期間に処理できるURL数の上限があります。この規模のサイトでは、その上限が索引漏れの直接の原因になります。数千点までなら気にしなくてよかった要素が、数万点を超えると結果を左右します。
答えは、4つの作業をセットで運用することです。サイトマップは、検索エンジンに渡すページのURL一覧です。サイトマップの分割とlastmodの精度、低価値URLの遮断、内部リンクによる優先順位の伝達、そしてボットログでの観測。どれか1つでは効きません。この記事では、その回し方を整理します。
結論: 4つをセットで運用する
作業 | 目的 | 単独で行った場合の限界 |
|---|---|---|
サイトマップの分割とlastmod | 「何を、いつ更新したか」を正確に伝える | 低価値URLが大量にあると、クローラーはサイトマップより発見したリンクを優先することがある |
低価値URLの遮断 | 絞り込み・並び替え・重複URLに予算を使わせない | 遮断しても、内部リンクが指していれば発見は続く |
内部リンクの優先順位 | 重要なページに多くのリンクを集め、深い階層を浅くする | サイトマップとlastmodが不正確なら、更新の検知が遅れる |
ボットログの観測 | 実際にどのURLが取得されているかを見る | 観測だけでは改善しない。上の3つの効果検証に使う |
重要な考え方: クロールバジェットは「クローラーがそのサイトに使う時間と回数」です。サイトの規模と応答速度、そしてクローラーが見つけるURLの数で決まります。索引漏れを減らす最短の方法は、「見なくていいURL」を減らし、「見てほしいURL」を明確にすることです。まず、見なくていいURLがどれだけあるかを数えてください。
索引漏れが起きる経路
数万点規模のモールで索引漏れが起きる典型的な経路を、順に追います。
絞り込み・並び替え・ページ送りで、商品数の数十倍のURLが生まれます。
クローラーはこれらを発見し、取得します(canonicalやnoindexは取得後に読まれます)。
予算の大半が、低価値URLの取得に使われてしまいます。
新商品・更新商品の発見が遅れ、「検出 - インデックス未登録」が増えます。
掲載終了した商品のURLがそのまま残り、エラーや薄いページとしてさらに予算を使います。
Search Consoleで「クロール済み - インデックス未登録」のURLを見てください。「検出 - インデックス未登録」のURLも、種類別に確認します。この経路のどこで詰まっているかが分かります。絞り込みURLばかりなら、遮断が先です。
サイトマップの運用: 分割とlastmod
項目 | 推奨 | 理由 |
|---|---|---|
分割単位 | 商品・カテゴリ・コンテンツで分け、1ファイル5万URL以下 | 種類別に索引状況を追える |
インデックスファイル | サイトマップインデックスで束ねる | 送信先を1つにできる |
lastmod | 実際に内容が変わった日時のみ更新 | 全URLを毎日更新するとlastmodが信用されなくなる |
掲載終了商品 | サイトマップから外し、404または410を返す | 存在しないURLへの取得を減らす |
掲載する対象 | canonicalが自分自身を指す、index可能なURLのみ | 重複URLを載せると予算を無駄にする |
lastmodの精度が、特に重要です。商品の在庫数が変わるたびにlastmodを更新すると、クローラーは「常に更新されている」と受け取り、更新の信号として使わなくなります。価格・説明・仕様が変わったときだけ更新する設計にします。lastmodが何をきっかけに更新されているかを、確認してください。
低価値URLの遮断: 種類別の処理
URLの種類 | 例 | 処理 |
|---|---|---|
並び替え | ?sort=price | robots.txtでクロールを禁止、またはcanonicalを親に向ける |
絞り込み(需要なし) | ?color=red&size=M | robots.txtで禁止 |
絞り込み(需要あり) | 「メンズ 防水 ジャケット」など検索される組み合わせ | 説明文を持つ正式なカテゴリページに昇格し、indexにする |
ページ送り | ?page=2 | index可能のまま、canonicalは各ページ自身 |
セッション・トラッキング | ?utm=, ?sid= | robots.txtで禁止 |
掲載終了商品 | 旧URL | 404/410。後継商品があればリダイレクト |
robots.txtは、クローラーに入ってよい場所を伝えるファイルです。ここでクロールを禁止したURLは、canonicalもnoindexも読まれません。すでに索引されているURLを外したいなら、順序が大事です。まずnoindexで索引から消し、消えた後にrobots.txtで止めます。遮断したいURLが索引済みかどうかを、先に確認してください。
内部リンクで優先順位を伝える
クローラーは、リンクが多く集まるページと、トップから近いページを優先します。数万点規模では、次の3点を確認してください。
主力商品・主力カテゴリが、トップから3クリック以内にあるかを見ます。
カテゴリページのページ送りが深くなりすぎていないかを見ます(1カテゴリに数百ページ続くなら、サブカテゴリに分けます)。
商品ページから関連商品・親カテゴリへのリンクが、テンプレートで一貫して出ているかを確認します。
ボットログで、効果を確かめる
上の3つを実施した効果は、ボットログでしか検証できません。最低限、次を週次で見ます。
指標 | 見るべき変化 |
|---|---|
取得URLのうち、低価値URLの割合 | 減っているか |
取得URLのうち、商品ページの割合 | 増えているか |
新商品が公開から取得されるまでの日数 | 短くなっているか |
4xx・5xxの応答数 | 減っているか |
Googlebot以外(GPTBot、PerplexityBot等)の取得対象 | 商品ページに到達しているか |
最後の項目は、AI検索での商品推薦に直結します。AI側のボットが低価値URLで予算を使い切り、商品ページに到達していないケースは珍しくありません。GPTBotが商品ページに到達しているかを、ログで確認してください。
数万点規模の運用は、手作業では続かない
ここまでの作業は、一度やれば終わりではありません。商品は毎日追加・終了します。絞り込み条件は増え、テンプレートは変わります。サイトマップの精度、遮断ルールの妥当性、内部リンクの状態、ボットの取得傾向を、継続的に見直すことになります。
Search OSは、この継続部分を運用として担います。既存のモールの構造は変えません。検索エンジンとAIクローラー向けのサイトマップ・canonical・メタデータ・構造化データを、別の層として提供します。Googlebot・GPTBot・PerplexityBotがどのURLをどれだけ取得しているか。これをボットログで継続的に観測します。索引漏れの原因となっているURL群と、優先して修正すべき箇所を整理します。数百万ページ規模でも、クローラーが「見てほしいページ」に到達する状態を保つことが目的です。見直しを続ける仕組みを、人手以外で持てるかどうかが分かれ目になります。
よくある質問
クロールバジェットは申請して増やせますか
増やせません。サイトの応答速度を上げ、無駄なURLを減らすことで対応します。同じ予算で処理できる重要URLの数を増やす、という考え方です。
絞り込みURLをすべてnoindexにすれば解決しますか
noindexは索引から外しますが、取得は続きます。予算を減らすには、robots.txtでの遮断が要ります。ただし、検索需要のある組み合わせは正式なページに昇格させます。
AI検索のボットもクロールバジェットの影響を受けますか
受けます。GPTBotなどは、サイトの構造と応答速度に応じて取得範囲を決めます。低価値URLが多いサイトでは、商品ページに到達する前に取得を終えることがあります。
あわせて読みたい
参考資料
Google Search Central: Managing crawl budget for large sites
Google Search Central: Managing large sitemaps
Google Search Central: Faceted navigation best practices
Google Search Central: Page Indexing report