ファセットナビゲーションとは？

ファセットナビゲーションは、色、価格、ブランド、サイズなどの属性フィルターで一覧を絞り込むブラウジングUIであり、eコマース、旅行、不動産、求人サイトなどで広く使われています。
フィルターの組み合わせごとに固有のURLが生成されるため、結果としてほぼ無限に近いURL空間が生まれ、重複コンテンツやインデックス肥大化、そして無駄なクロールバジェットの消費につながります。
GoogleのGary Illyes氏は、ファセットナビゲーションがGoogleに報告されるクロール問題のおよそ50%を占めると述べています。
基本的な対処法は、状況に応じてrobots.txtによるブロック、canonical、noindex、URLパラメータの健全な管理を組み合わせ、実際の検索需要に裏付けられたフィルターだけをインデックスさせることです。

概要

ファセットナビゲーションは、カテゴリ一覧ページ上のUIパターンで、訪問者が色、価格、ブランド、サイズなどの属性で商品やコンテンツを絞り込めるようにするものです。ユーザーが目的のものに素早くたどり着けるため、eコマース、旅行予約、不動産、求人掲示板など、一覧中心の大規模サービスでは事実上の標準となっています。

ユーザー体験には非常に有用ですが、SEOにとっては諸刃の剣です。フィルターが適用されるたびに新しいURLが作成され、複数のフィルターを組み合わせることでURL数は指数関数的に増加します。色が10種類、ブランドが20種類、価格帯が5段階あるだけでも、理論上の組み合わせ数はすでに数千に達します。さらに並び順やページネーションを加えると、URL空間は事実上無限になります。

SEO上の問題

重複コンテンツとシグナルの分散

フィルターを変更しても、返される商品リストはほぼ同じであることが多く、その結果、大量のURLが類似または同一のコンテンツを抱えることになります。そのため、本来1つの強いページに集約されるべきランキングシグナルが多数のURLに分散し、内部リンクを通じて受け渡されるPageRankも低価値なURLに薄まり、主要なカテゴリページの競争力が弱まります。

インデックス肥大化 and Thin Pages

ファセットの組み合わせは、検索需要がほとんどない数百万ページを生成する可能性があります。実質的にゼロに近い検索ボリュームしかない組み合わせ、たとえば「large silver Samsung freestanding washing machine + quick wash + energy rating A」のようなものがインデックス可能なURLとして公開されると、検索エンジンのインデックスは薄く価値のないページで肥大化します。

無駄になるクロール予算

クロール予算はサイト内でゼロサムです。並び順のバリエーションや空のフィルター組み合わせのクロールに使われた1回のリクエストは、新しく追加された商品や新しいコレクションページを発見するために使われない1回のリクエストです。GoogleのGary Illyesは、報告されるクロール問題の約50%はファセットナビゲーションに起因すると指摘しており、ファセットページのレンダリングには膨大な計算リソースが消費されると説明しています。

解決策

インデックス登録が不要な場合: robots.txtでブロックする

Googleは「多くの場合、フィルタされたアイテムにクローラーをアクセスさせる良い理由はない」と述べており、そのようなケースではrobots.txtでファセットURLのクロールをブロックすることを推奨しています。基本的な考え方は、フィルタのパラメータの組み合わせをブロックし、未フィルタの一覧ページ全体と個々の商品ページのみをクロール可能にすることです。

User-agent: *
Disallow: /*?*color=
Disallow: /*?*size=
Allow: /*?products=all$

ただし、robots.txtによるブロックはクロールを防ぐだけであり、インデックスからの削除を保証するものではありません。外部からの被リンクやフォローされた内部リンクが存在する場合、ブロックされたURLがインデックスに残ることがあります。逆に、noindexタグはページのHTML内にあるため、ボットはそれを読むためにページをクロールする必要があり、つまりクロール予算は結果を破棄するためだけに消費されます。これら2つの方法は役割が異なるため、状況に応じて適切なものを選ぶ必要があります。

インデックス登録が必要な場合: canonicalとURLの整備

一部のフィルターに実際の検索需要がある場合は、それらをインデックス化しつつ、以下の原則でクロール負荷を最小限に抑えます。

標準的なパラメータ区切り文字: カンマ、セミコロン、角括弧ではなく、業界標準のアンパサンド（&）を一貫して使用します。
一貫したフィルター順序: フィルターをURLパスにエンコードする場合は、重複するフィルターが発生しないよう、常に論理的な順序を同じに保ちます。
空の結果には404を返す: 結果が0件になるフィルターの組み合わせでは、一般的なエラーページにリダイレクトするのではなく、HTTP 404 を返します。
rel=canonical: フィルター別のURLを、よりシンプルな参照URLに向けて指定し、標準外URLのクロール比率を段階的に下げます。Google は、コンテンツが大きく異なる場合や、多数の内部リンクがそのバリアントに集中している場合、canonical を無視することがある点に注意してください。

選択的インデックス戦略

ファセットをインデックスするのは、次の3条件が同時に満たされる場合に限るのが妥当です。つまり、実際に検証可能な検索ボリュームを伴うクエリに対応していること、独自性のあるコンテンツを提供できること、そして空ページではなく十分な件数の結果セットを返せることです。価値の高い少数のフィルター組み合わせについては、ロングテール需要を取り込むために動的URLではなく専用の静的サブカテゴリページを作成する方法が推奨されます。

根拠

Google Search Central の「Managing crawling of faceted navigation URLs」ドキュメントでは、robots.txt によるブロックが最も効果的な予防策として示されており、インデックスが必要なケースに向けて、アンパサンド区切り、フィルター順序、404 の扱い、canonical の指針が明記されています。Ahrefs の faceted navigation ガイドでは、重複コンテンツ、インデックス膨張、PageRank の希薄化といった問題を取り上げつつ、canonical、noindex、robots.txt、静的ページ化などの多層的な対策を説明しています。両方のソースが強調しているのは、万能の単一解は存在せず、サイト規模とフィルター種別に応じてクロール制御、正規化、選択的インデックスを組み合わせる必要があるという点です。

実装チェックリスト

Google Search Consoleのインデックスカバレッジレポートを使用して、インデックスに蓄積されたファセットURLの数を診断します。検索需要のないフィルターパラメータのクロールを robots.txt でブロックします。
すでにインデックスされている低価値のファセットURLは、まず noindex でインデックスから削除し、その後にブロックを適用します。
インデックス対象にする必要があるフィルターには、参照先のカテゴリページを canonical に設定します。
URL パラメータの区切りをアンパサンド（&）に統一し、フィルター順序を修正します。
結果が0件になるフィルターの組み合わせには、HTTP 404 を返します。
検証済みの高価値フィルター組み合わせにのみ、専用の静的サブカテゴリページを作成します。
Build dedicated static subcategory pages only for high-value filter combinations with verified 検索ボリューム.
新規実装では、最初からクロール可能なURLの数を減らすために、フィルター処理をAJAXで行い、内部リンクを使わない方法を検討してください。

ファセットナビゲーション

概要