Insights一覧へ戻る

MINAMI Insight

ECサイトの絞り込みURLがクロールを圧迫する?クロールバジェット最適化の判断手順

2026年7月19日

ECサイトの色・サイズ・価格帯などの絞り込みURLが大量に生成される場合に、残すページとクロールを抑えるページをどう判断するか。インデックス状況、内部リンク、canonical、robots.txtを混同せずに整理する実務手順を解説します。

絞り込みURL クロール対策 テクニカル

ECサイトで色、サイズ、ブランド、価格帯などの絞り込み機能を提供すると、利用者には便利でも、検索エンジン向けには似たURLが大量に生まれることがあります。ただし、絞り込みURLが存在するだけで直ちに問題になるわけではありません。重要なのは、検索需要のある一覧ページまで一律に閉じず、価値のない組み合わせだけを制御することです。

この記事では、クロールバジェット最適化を目的に、絞り込みURLを「残す・統合する・クロールを抑える」の3種類へ整理する手順を解説します。

最初に結論:URL数ではなくクロールの偏りを見る

クロールバジェットとは、検索エンジンがサイトをクロールできる量を考えるための概念です。小規模サイトでは過度に意識する必要がない場合もあります。一方、商品数が多く、複数条件の掛け合わせでURLが際限なく増えるECサイトでは、重要な商品やカテゴリの発見・再クロールが遅れる要因になり得ます。

判断すべきなのは「パラメータURLが何件あるか」だけではありません。重要ページよりも重複性の高い絞り込みURLへクロールが偏っていないかを確認します。

絞り込みURLが問題かを確認する4つの観点

1. URLの増え方を洗い出す

まず、絞り込み条件とURLの対応表を作ります。色とサイズの順序を変えるだけで別URLになるか、同じ条件へ複数のパスで到達できるか、該当商品が0件でもURLが返るかを確認してください。

特に注意したいのは、条件の並び順、セッションID、トラッキング用パラメータ、並べ替え、表示件数の違いです。内容がほぼ同じままURLだけが増える仕組みを先に特定します。

2. Googleが実際にクロールしているかを見る

理論上生成できるURLと、実際にクロールされているURLは分けて考えます。Google Search Consoleのクロール統計情報やサーバーログを使い、Googlebotのアクセス先をディレクトリやパラメータ別に集計します。

絞り込みURLへのアクセスが多い一方、商品詳細や主要カテゴリの更新がなかなか反映されないなら、制御を検討する根拠になります。逆に、不要URLがほとんどクロールされていないなら、大規模な変更を急ぐ必要はありません。

3. 検索流入と需要を確認する

「黒いスニーカー」「大きいサイズのジャケット」のように、絞り込み条件そのものに検索需要がある場合、その一覧ページは入口になり得ます。表示回数、クリック、掲載順位、関連クエリを確認し、単なる重複ページと需要を満たすランディングページを分けます。

検索需要があるページを残す場合は、固有のタイトルや見出し、説明文、安定した商品構成を用意し、通常のカテゴリとして内部リンクを設ける方が管理しやすくなります。

4. インデックス状況をサンプル確認する

Search ConsoleのURL検査やページのインデックス登録レポートで、代表的なURLを確認します。全URLを目視するのではなく、「残したい」「不要」「判断保留」の各グループからサンプルを選ぶと傾向をつかめます。

URLを3種類に分類する

残す:検索需要があり独立した価値を持つ

ユーザーがその条件で商品を探しており、十分な商品数が継続的にあり、他ページと役割を分けられるURLはインデックス対象として残します。サイトマップやカテゴリ導線にも含め、検索エンジンが安定して発見できる状態にします。

統合する:内容が同じで代表URLがある

並べ替えやパラメータ順の違いなど、内容が実質同じURLには代表URLを定めます。恒久的に一本化できるならリダイレクトを検討し、ユーザー向けには必要だが重複する場合はcanonicalを使います。

canonicalはクロールを完全に止める命令ではありません。代表URLを示すためのシグナルとして使い、内部リンクも代表URLへそろえることが大切です。

クロールを抑える:価値がなく無限に増える

検索需要がなく、組み合わせが膨大で、内容も薄いURLは、リンク生成の仕組みから見直します。通常のリンクとしてたどれる範囲を必要な条件に限定し、不要な組み合わせをサイトマップへ入れないようにします。

robots.txtはクロール制御には使えますが、URLのインデックス削除を保証するものではありません。また、robots.txtで遮断したURL上のcanonicalやnoindexは検索エンジンが確認できません。目的がクロール抑制なのか、インデックス除外なのかを分けて設計してください。

実装で混同しやすい4つの手段

  • 内部リンク制御:検索エンジンが不要な組み合わせを発見し続ける入口を減らす。
  • canonical:似たページ群の代表URLを示す。
  • noindex:ページを検索結果へ出さないよう伝える。ただしクロール自体は必要になる。
  • robots.txt:指定パターンへのクロールを制限する。インデックス制御とは役割が異なる。

一つの手段ですべてを解決しようとすると、意図しないURLが残ったり、必要なシグナルを読めなくしたりします。URL分類ごとに目的を決めて使い分けます。

変更は小さく始めて効果を測る

いきなり全パラメータを遮断せず、問題が明確な一種類から変更します。変更前に、対象パターンへのクロール数、主要カテゴリと商品ページのクロール状況、インデックス数、自然検索流入を記録します。その後も同じ指標を比較してください。

重要ページの順位も併せて追う場合は、MINAMI SEOで対象キーワードを定点観測しておくと、技術変更の前後で順位がどう動いたかを確認しやすくなります。ただし、順位変動だけで効果を断定せず、クロールとインデックスの変化も一緒に見ます。

運用チェックリスト

  • 絞り込み条件と生成URLの規則を一覧化したか
  • Googlebotが実際にアクセスするURL群を確認したか
  • 検索需要がある絞り込みページを一律に閉じていないか
  • 内部リンクとサイトマップが代表URLへそろっているか
  • canonical、noindex、robots.txtの目的を混同していないか
  • 変更前後を比較できる指標を保存したか

まとめ

ECサイトのクロールバジェット最適化では、絞り込みURLを一括で排除するのではなく、検索需要と実クロールを根拠に分類することが出発点です。価値のある一覧は育て、重複は代表URLへ統合し、無限に増える不要な組み合わせは発見経路から抑えます。まずは一つのURLパターンを対象に、変更前後のクロール状況を比較するところから始めてください。

MINAMIで順位改善を仕組み化する

記事で得た知見を、順位追跡・競合分析・改善レポートにそのままつなげられます。