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

TL;DR — ファセットナビゲーションとは、カテゴリページにある色、サイズ、価格、ブランドなどの絞り込み機能です。買い物には便利ですが、選択するたびに新しいURLが作られる設計では、数千の商品ページから内容がほぼ同じフィルターURLが_数百万件_生まれ、検索エンジンのクロール資源を浪費します。対策はフィルターをなくすことではありません。Googleに表示する価値がある組み合わせを選び、それ以外を検索対象から外すことです。

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

ほとんどのオンラインストアでは、カテゴリページの左側などに、_色：青、サイズ：L、ブランド：Samsung、500 USD未満_といった条件で商品を絞り込むパネルがあります。個々の条件がファセットで、パネル全体をファセットナビゲーションと呼びます。「ファセット検索」や「商品フィルター」とも呼ばれます。

これは本当に便利なユーザー体験です。問題は純粋に技術的なもので、ウェブアドレスに関わります。

フィルターがSEOの問題を生む理由

フィルターを選ぶと、多くのストアは選択状態を記憶するためにページのURLを変更します。たとえば次のようになります。

example.com/sofas?color=blue
example.com/sofas?color=blue&size=large
example.com/sofas?color=blue&size=large&brand=ikea

組み合わせが違えばURLも別になります。ここで問題になるのが組み合わせ数です。商品10 000点、色20種類、サイズ15種類、さらに複数の並べ替え順があるだけで、潜在的なフィルターURLは_数百万件_になります。その大半は、別のURLとほぼ同じ少数の商品を表示します。 この主張の根拠 Faceted navigation can create effectively unbounded combinations of crawlable URLs. 対象範囲： The exact number depends on URL design, filter combinations, and crawler-discoverable links. 信頼度： 高 · 検証日： 2026-07-14 Google: Managing faceted navigation

検索エンジンはサイト内のURLを訪問（クロール）し、検索対象として保存（インデックス登録）します。ただし、1つのサイトに使える時間は無限ではありません。内容がほぼ同じフィルターページ数百万件のクロールに時間を使えば、実際の新商品はクロールされません。GoogleのGary Illyesによると、ファセットナビゲーションは報告されるクロール問題のうち最も多く、約半数を占めます。

多くの人が誤解する点

解決策はフィルターを削除することではありません。買い物客には必要です。必要なのは、どのフィルターページが重要で、どれが重要でないかを検索エンジンに明確に伝えることです。

• “blue velvet sofas” (翻訳)「青いベルベットのソファ」のように実際の検索需要があるフィルターページは、独立したランディングページとしてGoogleに残す価値があります。
• “blue sofas sorted by price, page 3” (翻訳)「価格順に並べた青いソファの3ページ目」のように検索されないページは、利用者の操作のためだけのものです。買い物客には使わせても、Googleにクロール資源を費やさせる必要はありません。

不要なURLを検索対象から外す主な手段は、robots.txt、noindex、canonicalタグの3つです。それぞれ役割が_異なります_。取り違えると状況が悪化するため、Advancedタブの判断表で目的に合う手段を選んでください。

以前のGoogle Search Consoleには、フィルターパラメータを無視するようGoogleへ伝える「URL Parameters」ツールがありましたが、Googleは2022年に廃止しました。古い解説には今も登場しますが、現在は利用できません。 この主張の根拠 Google deprecated Search Console's URL Parameters tool in 2022. 対象範囲： Sites must manage parameter crawling through their own URL and crawl-control implementation. 信頼度： 高 · 検証日： 2026-07-14 Google: URL Parameters tool deprecated

このファセットURLを処理する制御はどれか？

ファセットURL数が突然急増する

1. パターンを確認する。 インデックス登録またはクロールされたURLの標本を、実際の商品数と比較します。余分なURLをパラメータとその組み合わせごとに分類します。反復するファセットのパターンがなければ、ここで止めて別のURL発生源を調査します。
2. 発見経路を特定する。 カテゴリテンプレートをクロールし、どの操作要素がクロール可能な href を出すか内部リンクを調べます。URLがログにしか現れない場合は、外部リンクと古いサイトマップも確認します。
3. クローラーへの露出を測る。 疑わしいパラメータ別にサーバーログを分割します。Googlebotがリクエストしていなければインデックス整理を優先し、リクエストの大部分を消費していればクロール防止を優先します。
4. 需要を分類する。 検索需要のあるファセット組み合わせと、純粋なUX用状態を分けます。前者はランディングページとして維持し、この判定前に一律ブロックを適用しないでください。
5. 主な制御方法を1つ適用する。 需要のある組み合わせには実際のインデックス可能なページ、URLが不要な箇所にはフラグメントまたはリンクではない操作、クロール防止には robots.txt、インデックス削除にはクロール可能な noindex を使います。disallowと noindex は併用しません。
6. 検証して監視する。 代表URLをテストし、ログ、Crawl Stats、Page Indexingを監視します。価値あるランディングページが消えたり、正当なパラメータがブロックされたりした場合は、ルールを限定するかロールバックします。

クリーンアップを難しくするファセットナビゲーションの失敗

robots.txtでURLをブロックし、noindexを追加する

Googleはブロックされたページを取得できないため、そのnoindexディレクティブを検出できません。インデックスから削除する間はクロールを許可し、不要なURLがインデックスから消えた後にのみクロールのブロックを検討します。

同じファセットページにnoindexとcanonicalを追加する

noindexはページをインデックス登録しないよう指示し、canonicalは別URLへシグナルを統合するようGoogleに示します。矛盾する指示を重ねず、目的に合うシグナルを選びます。

canonicalタグがクロールを止めると期待する

GoogleがフィルターURLのcanonicalを確認するには、そのURLをクロールする必要があります。canonicalはシグナル統合に使い、際限なく広がるクロール空間を抑える唯一の手段にはしません。

すべてのパラメータを一律にブロックする

1つのパラメータが、無価値な組み合わせと価値あるランディングページの両方を生成することがあります。各パラメータの役割を棚卸しし、例外を明示した限定的なルールを書いてください。

ロングテールのためにすべての組み合わせをインデックス登録する

ほとんどの組み合わせには単独の検索需要も固有のコンテンツもありません。需要の裏付けがある組み合わせだけをランディングページにし、それ以外は検索対象から外します。

ファセットナビゲーションの失敗を診断する

インデックス登録URL数がカタログを大幅に上回る

考えられる原因： フィルター、並べ替え、パラメータ順の違いにより、同じ商品集合を示すクロール可能なURLが大量に作られています。修正： URLをパラメータ別にまとめ、需要の裏付けがある組み合わせだけを残し、目的に合うクロールまたはインデックス制御を適用します。Page Indexingの該当区分とログの件数が減り続けることを確認してください。

Googlebotのリクエストがサーバーを圧迫する

考えられる原因： クローラーがほぼ無限に続くファセットURL空間へ入り込んでいます。修正： サーバーログで該当するパラメータパターンを特定し、価値のない状態へのクロール可能なリンクを削除したうえで、対象を絞ったrobots.txtルールを適用します。GooglebotのリクエストがカテゴリURLと商品URLへ戻ることを確認してください。

noindexのファセットがインデックスに残る

考えられる原因： 同じURLがrobots.txtで拒否され、Googleがnoindexを確認できません。修正： Googleがnoindexを処理するまでクロールを許可します。URL Inspectionで、公開中のページを取得でき、ディレクティブが表示されることを確認してください。

GoogleがカテゴリURLではなくファセットURLを選ぶ

考えられる原因： canonical、内部リンク、サイトマップ、本文のシグナルが一致していません。修正： それらを意図するcanonical URLへ揃え、重複形式への内部リンクを削除します。URL Inspectionで、宣言したcanonicalとGoogleが選択したcanonicalを確認してください。

モデルに判断を渡さずファセットパラメータを分類する

パラメータ、URL例、商品数、推定検索需要、結果集合が基準カテゴリと異なるかどうかを含むCSVを貼り付けます。実装前に、すべての推奨事項を人が確認してください。

You are helping triage faceted-navigation URL patterns. For each CSV row, classify the pattern as one of: candidate indexable landing page, crawl-prevention candidate, deindexing candidate, canonical-to-base candidate, or needs human review.

Use these rules:
- A landing-page candidate needs verified standalone search demand and meaningfully distinct content.
- robots.txt controls crawling, not guaranteed indexing.
- noindex requires the URL to remain crawlable.
- canonical consolidates signals but does not stop crawling.
- Empty or impossible combinations should return 404.

Return a table with: parameter pattern, evidence used, recommended class, implementation precondition, representative URL to test, and risk if wrong. Do not invent keyword demand. Mark missing evidence as NEEDS DATA.

CSV:
[PASTE CSV]

アクセスログからファセットのクロール比率を測定する

このPythonスクリプトを標準的なアクセスログに対して実行します。ボットとファセットのパターンはサイトに合わせて調整してください。観測したリクエストを報告するだけで、URLをインデックス登録すべきかどうかは判断しません。

import re
import sys
from collections import Counter
from urllib.parse import urlsplit, parse_qsl

BOT = re.compile(r"Googlebot", re.I)
REQUEST = re.compile(r'"(?:GET|HEAD)\s+(\S+)\s+HTTP/[^\"]+"')
FACET_KEYS = {"color", "size", "brand", "price", "sort", "order"}

total = 0
faceted = 0
keys = Counter()

with open(sys.argv[1], encoding="utf-8", errors="replace") as log:
    for line in log:
        if not BOT.search(line):
            continue
        match = REQUEST.search(line)
        if not match:
            continue
        total += 1
        query_keys = {key for key, _ in parse_qsl(urlsplit(match.group(1)).query)}
        matched = query_keys & FACET_KEYS
        if matched:
            faceted += 1
            keys.update(matched)

print({"googlebot_requests": total, "facet_requests": faceted})
print(keys.most_common())

クローラーでパラメータ付きファセットリンクを抽出する

Screaming Frogのカスタム抽出でこのXPathを使い、クエリ文字列に指定キーのいずれかを含むリンクを収集します。

//a[contains(@href,'?') and (contains(@href,'color=') or contains(@href,'size=') or contains(@href,'brand=') or contains(@href,'sort='))]/@href

同等の正規表現は、グループ1でURL、グループ2で最初に認識されたパラメータ名を取得します。

href=["']([^"']*[?&]((?:color|size|brand|price|sort|order))=[^"']*)["']

現在のページのファセットリンクを一覧表示する

Chrome DevToolsのConsoleでこれを実行します。keysはサイトの実際のパラメータに合わせて変更してください。

const keys = new Set(["color", "size", "brand", "price", "sort", "order"]);
console.table(
  [...document.querySelectorAll("a[href]")]
    .map((a) => new URL(a.href, location.href))
    .filter((u) => [...u.searchParams.keys()].some((k) => keys.has(k)))
    .map((u) => ({
      url: u.href,
      keys: [...u.searchParams.keys()].filter((k) => keys.has(k)).join(","),
    })),
);

クロール制御の変更が有効になったことを証明する

サイト全体へ適用する前にURLの一部へ変更を展開し、同等の未変更URL群を対照として残します。クロールとインデックスの指標は変更以外の理由でも動くため、影響を切り分けるにはコホート比較が必要です。

robots.txtルールをテストする

実施するテスト： Search Consoleのrobots.txtテスト手順を使うか、公開中のファイルを取得し、許可・拒否される代表URLを確認します。期待結果： 不要なファセットURLだけが拒否され、基準カテゴリ、商品、承認済みランディングページは許可されます。失敗の解釈： パターンが広すぎる、狭すぎる、または実際のURL形式に一致していません。監視期間： ルールは即時ですが、クローラーの挙動はボットが再訪した後に変わります。ロールバック条件： 価値のあるカテゴリ、商品、承認済みファセットページのいずれかが拒否された場合。

需要に裏付けられたランディングページをテストする

実施するテスト： レスポンス、レンダリング後のHTML、canonical、内部リンク、サイトマップ登録を確認します。期待結果： 200を返し、自己参照canonicalがあり、固有のページ要素を示し、クロール可能なリンクから到達できます。失敗の解釈： ページが依然として抑制対象のファセット状態として扱われています。監視期間： 技術シグナルは即時ですが、Googleが選ぶcanonicalとインデックス状態は再クロール後に変わります。ロールバック条件： Googleが継続的に別ページへ統合する、または固有の内容と需要を維持できない場合。

ブロックせずにインデックス削除をテストする

実施するテスト： noindexを追加した後、不要な代表ファセットURLを確認します。期待結果： GoogleがURLを取得してnoindexを読み、後にインデックスから削除されます。失敗の解釈： robotsルール、レンダリング不具合、ヘッダーやテンプレートの競合がディレクティブを隠しています。監視期間： ディレクティブの配信は即時ですが、削除は再クロール後です。ロールバック条件： 承認済みランディングページにもnoindexが適用された場合。

ファセットナビゲーションの健全性指標

クロール比率、インデックス規模、ランディングページ成果は3つの独立したシグナルとして追跡し、1つのスコアにまとめないでください。本記事の制御は、クロール、インデックス登録、順位、トラフィック、AI引用の結果を保証しません。検索エンジンやAIクローラーが発見できる対象を変えるだけです。

ボットクロールに占めるファセットの割合

指標： 検証済みGooglebotリクエストのうち、インデックス非対象のファセットパターンへ向かった割合。分かること： UX専用URLへクロール資源が流れているか。取得方法： ボットを検証し、既知のファセットパラメータ別にサーバーログを分割します。基準： テンプレート別の現状値を置き、修正後に継続的に低下することを目標にします。カタログとクロール需要は異なるため普遍的な目標値はありません。頻度： 修正中は毎週、その後は毎月。

Page IndexingにおけるファセットURLのフットプリント

指標： インデックス登録済み、重複、クロール済み・未登録、soft 404に分類されたファセットURLの件数と割合。分かること： クロール制御とcanonicalがインデックス肥大を抑えているか。取得方法： Search ConsoleのPage Indexingサンプルを出力し、URLをパラメータパターン別に分類します。基準： 意図的にインデックス登録するファセットページ数と比較し、ストア自身のカタログを基準にします。頻度： インデックス変化は遅れるため毎月。

承認済みランディングページのパフォーマンス

指標: 意図的にインデックス可能な状態で維持したファセット組み合わせのクリック数、表示回数、コンバージョン。分かること: 需要に基づく例外が、クロールと保守のコストに見合う成果を得ているか。取得方法: Search Consoleとアクセス解析で対象URLだけをグループ化します。基準・現実的な範囲: 架空のサイト全体しきい値ではなく、公開前の各ページ基準値と関連する基底カテゴリを比較します。頻度: 毎月、およびカタログの重要な変更後。

TL;DR — ファセットナビゲーションは、Googleに報告される過剰クロールの第1位の要因で、Gary Illyesによればクロール問題の約50%を占めます。フィルターの組み合わせごとにURLが作られると、小規模なカタログにも重複に近いページが数百万件潜み、重複コンテンツ、インデックス肥大、クロールバジェットの浪費、PageRankの分散を招きます。まず、実需がある組み合わせはインデックス可能なランディングページにし、UX専用の組み合わせは抑制します。手段は交換可能ではありません。robots.txtはクロールを止めてもインデックス登録は止めず、noindexはインデックスから除外しますがクロールが必要で、canonicalはシグナルを統合するヒントでもクロールを止めません。URLフラグメント（#）はGoogleが無視するため、このURL問題自体を回避できます。GSCのURL Parametersツールは廃止済みで、Googleではサーバー側の制御が必要です。BingにはURL Normalizationが残っています。

仕組み：フィルターがURL空間を爆発させる方法

ファセットナビゲーションは、クローラーがたどれる形でフィルターがURLを変えた瞬間にSEO上の問題になります。ここでは3つの別々の概念が混同されがちです。UI操作（買い物客がフィルターをクリックすること）、取得可能なURL状態（クリックによってクローラーが実際にリクエストできるアドレスへ変わるか）、インデックス可能なランディングページ（そのURLをGoogleのインデックスへ載せる意図があるか）です。ファセットシステムは、このうち1つ、2つ、または3つすべてを公開できます。URLを変えないクライアント側フィルターは1つ目だけ、クエリ文字列を使うフィルターは最初の2つ、「青いベルベット製ソファ」用に選定したページは意図的に3つすべてを備えます。

代表的な実装は3種類です。

問題の全体像は算術にあります。商品10 000件 × 色20種類 × サイズ15種類 × 並び順5種類なら、潜在的なURLは15 000 000+件です。 この主張の根拠 Combinatorial filters can turn a modest catalog into millions of possible URL states. 対象範囲： The arithmetic is illustrative; Google documents the underlying infinite-space risk. 信頼度： 高 · 検証日： 2026-07-14 Google: Managing faceted navigation Gary IllyesはLinkedInで次のように説明しました。“Sometimes you might create these new fake URLs accidentally, exploding your URL space from a balmy 1000 URLs to a scorching 1 million, exciting crawlers that in turn hammer your servers unexpectedly.” (翻訳)「意図せず新しい偽URLを作り、穏やかな1 000件のURL空間を灼熱の百万件へ爆発的に増やし、興奮したクローラーがサーバーへ予期せぬ負荷をかけることがある」

GoogleはフィルターURL空間を見ただけで、無視すると決められるわけではありません。Illyesは Search Off the Record で次のように説明しました。“Once it discovers a set of URLs, it cannot make a decision about whether that URL space is good or not unless it crawled a large chunk of that URL space.” (翻訳)「URL集合を発見した後、その大部分をクロールしなければ、そのURL空間の良否を判断できない」これがクロールに関する最大の苦情になる理由です。Googleが不要なURLだと判断できる時点では、すでに多くをクロールしています。

調査例：フィルターは罠の半分にすぎなかった

Googleの2025年末のクロール総括は、実務を考えるうえで有用です。Gary Illyesは、議論されたクロール問題の約50%をファセットナビゲーション、さらに25%をアクションパラメータによるものとしました。後者も重要です。Eコマース監査でcolor、size、brandだけを数えると、add-to-cart、比較、ウィッシュリスト、並べ替え、セッション、トラッキングの操作が作るURLを見落とします。

典型的な基準値とは主張せず、例示的な件数で調査手順を示します。ある小売サイトにはインデックス可能な商品とカテゴリが18 000件ありますが、クロールでは640 000 URLが見つかりました。クロールとログのサンプルをパラメータ別にまとめると、次のようになりました。

対策は一律のDisallowではありません。クロール可能なアクションリンクを削除し、内部リンクにセッションやキャンペーンのパラメータを付けず、重複するフィルター順を正規化し、不可能な組み合わせには404を返します。需要の裏付けがある少数のフィルターは安定したランディングページとして残します。サーバーログで、クローラーのリクエストがカテゴリURLと商品URLへ移ったことを確認します。クロール出力が小さくなっただけでは成功とはいえません。

それが引き起こす4つの問題

1. 重複に近いコンテンツ。 /washing-machines/samsung/と /washing-machines/?brand=samsungが同じ商品集合を返すと、ランキングシグナルが 統合されず、2つのURLへ分散します。
2. インデックスの肥大化。 数百万件あるURLの一部だけでもインデックスに入れば、 サイト全体の品質シグナルを押し下げます。
3. クロールバジェットの浪費。 価値の低いファセットに使われたクロールは、 本当に新しい商品に回らなかったクロールです。影響は積み重なり、新しいコンテンツの 発見も遅らせます。（クロールバジェットが実際に問題になるのは大規模サイトです。 対象についてはクロールバジェットを参照してください。）
4. PageRankの希薄化。 500通りのフィルター組み合わせへリンクするカテゴリページは、 本来順位を付けたい商品へ内部オーソリティを流す代わりに、501のリンク先へ分散させます。

顧客からよく聞かれるため明確にしておくと、これはペナルティの問題ではありません。 Googleはファセットナビゲーションによる重複だけを理由に手動対策を行いません。問題はクロールとインデックスの_効率_、そしてシグナルの_分散_です。

戦略的な判断が先に来る

robots.txtやmetaタグを変更する前に、URLごとに判断します。このフィルターの組み合わせはインデックスに残す価値があるか、それともないか。

• 「ハイライズのスキニージーンズ」「防水ハイキングブーツ」「青いベルベットのソファ」のように、実際に入力される検索語へ対応するならインデックス登録する価値があります。適切なランディングページにします。
• 任意の組み合わせ、並べ替え順、誰も検索しない深い多重ファセットなら価値はありません。これらは抑制します。

境界線はキーワード調査で決めます。候補となるファセット修飾語を抽出し、検索ボリュームを 確認して基準を設定します。実務上、独立したインデックス可能なファセットページを作る おおよその目安は**月間検索数300+**です。それ未満はブロックするか、フラグメントで 表現します。ここで重要なのがロングテールです。キーワードの99,84%は月間検索数が 1 000未満ですが、検索需要全体の39,33%を占めます。 大半のファセット組み合わせには 需要がありません。しかし需要のある少数の組み合わせは本当の機会であり、その需要を 取り込むには、該当ページだけをインデックス登録可能にする必要があります。

需要だけでは不十分です。インデックス可能なランディングページへ昇格するには、検証済みの需要、固有の価値（基準カテゴリと実際に異なる内容と商品集合）、継続的な監視（クロール、インデックス、成果）の3つが必要です。昇格したページは、長期的な成果が保証されたものではなく、価値を実証し続ける実験として扱います。追跡項目はMetricsタブを参照してください。

技術的な手段 — その違い

3つの主な制御は似て見えても交換できないため、多くの実装はここで失敗します。

robots.txtのdisallow — クロールを止める、Google推奨の予防策。 商品ページとフィルターなし一覧を許可しながら、フィルターパラメータ空間を拒否する方法は、クロールバジェットに最も強く効きます。Googleの例は次のとおりです。

disallow: /*?*products=
disallow: /*?*color=
disallow: /*?*size=
allow: /*?products=all$

注意点は、robots.txt が止めるのはクロールであり、インデックス登録ではないことです。被リンクがあるブロック済みURLは、Googleが本文を読めないためスニペットなしのURLだけの結果としてインデックスへ残る場合があります。したがって、目的が「この領域へのクロール浪費を止める」ことなら適切ですが、「インデックスから削除する」ための手段ではありません。

noindex — インデックスから削除するが、クロールは必要。 Googleの文言は “Google has to crawl the page in order to find the noindex rule.” (翻訳)「Googleはnoindexルールを見つけるためにページをクロールする必要がある」です。したがって noindex が制御するのはインデックス登録であり、クロールではありません。タグを読むためにページ取得が必要なので、クロールバジェットの節約にはならず、目的がインデックス削除のときに使います。

rel="canonical" — 統合を示すヒントで、クロール抑制としては最も弱い。 フィルター済みページから未フィルターのカテゴリへ向けると重複シグナルを統合し、Googleによれば、“may, over time, decrease the crawl volume of non-canonical versions” (翻訳)「時間の経過とともに非正規版のクロール量を減らす場合がある」一方、robots.txtやフラグメントより “generally less effective in the long term” (翻訳)「長期的には一般に効果が弱い」とされます。これは命令ではなくヒントなので無視される場合があり、Googleはcanonicalタグを見るために非正規ページもクロールするため、短期的なサーバー負荷は減りません。

URLフラグメント（#）— 問題そのものを回避する。 “Google Search generally doesn’t support URL fragments in crawling and indexing,” (翻訳) 「Google検索は通常、URLフラグメントのクロールとインデックス登録をサポートしない」ため、 /sofas#color=blueのようにハッシュでフィルター状態を表せば、クロールやインデックスへの 影響はありません。検索需要のないフィルターを防ぐ最も簡潔な方法です。フィルターは クライアント側で適用され、新しいクロール可能なURLは作られません。

フィルターリンクの rel="nofollow" — 全リンクで徹底する必要があります。 フィルターリンクをGoogleがたどりにくくできますが、Googleによれば、“every anchor pointing to a specific URL must have the rel=‘nofollow’ attribute in order for it to be effective.” (翻訳)「有効にするには、特定URLを指すアンカーすべてにrel=‘nofollow’属性が必要である」とされます。サイト内のどこかに通常リンクが1つでも残ると、この方法は漏れます。また、現在の nofollow は命令ではなくヒントです。

詳しい判断表はCheat Sheetsタブを参照してください。

重要な禁止事項

気づかないうちに問題を起こすのは、次の組み合わせです。

• 同じURLに noindex と robots.txt の拒否を併用する。 典型的な失敗です。URLが拒否されるとGooglebotは取得できず、noindex タグを見られないため、ページがインデックスに残ることがあります。削除するにはクロールを許可して noindex を返します。
• 同じURLに noindex と canonical を併用する。 矛盾したシグナルです。Muellerは “noindex doesn’t tell Google that you want it combined with something else and that signals should be forwarded.” (翻訳)「noindexは、別のものと統合してシグナルを転送してほしいとGoogleに伝えるものではない」と説明しています。どちらか一方を選んでください。
• canonicalだけでクロールバジェットが減ると期待する。 canonicalはクロールを止めません。Googleはタグを確認するため非正規URLも取得し続けます。

_インデックス登録する_ファセットのURL構造ベストプラクティス

インデックス登録すると決めた少数のフィルターページについて、Googleのドキュメントは明確なルールを示しています。

1. 区切りにはカンマ、セミコロン、パイプ、角括弧ではなく、標準の&を使います。
2. フィルター順を統一します。/sofas/blue/fabricと/sofas/fabric/blueは2つではなく、1つのcanonical形式へ解決させます。
3. ?color=blue&color=blueのような値の重複は200ではなく404にします。
4. 空または不可能な組み合わせでは、/sofas/redに結果がないなら正しい404を返し、noindexを付けた200の「結果なし」ページで代用しません。
5. インデックス可能なファセットにはクエリ文字列より分かりやすいパスを使います。/sofas?color=blue&style=&sort=より/sofas/blue/が適します。

JavaScript／AJAXファセットナビ — トレードオフを伴う予防

フィルターURLへの実際の<a href>リンクを出さないクライアント側AJAXとしてフィルターを構築すれば、ブラウザー内で絞り込みが行われ、クロール可能なURLは作られません。クロールバジェットには有利ですが、Googlebotもその状態へ到達できないため、価値のあるロングテールの組み合わせもインデックス登録されません。

大規模カタログの理想はハイブリッド構成です。需要の高いフィルター組み合わせは事前レンダリングまたはサーバーレンダリングし、固有の導入文を持つ実ページとしてリンクし、インデックス登録とサイトマップ掲載の対象にします。 一時的で需要のない状態は、AJAX、フラグメント、またはベースURLへのcanonicalを伴う pushState パラメータとしてクライアント側だけに保ちます。GoogleはJavaScriptをレンダリングしますが、HTMLのクロールより遅く、処理待ちも発生します。確実にインデックス登録したいページをクライアント側レンダリングだけに依存させないでください。詳しくはJavaScript SEOを参照してください。

URL Parametersツールは廃止された

クライアントには早い段階で説明してください。Googleは2022年4月にURL Parametersツールを廃止しました。Googleの説明は “only about 1% of the parameter configurations currently specified in the URL Parameters tool were useful for crawling.” (翻訳)「URL Parametersツールに指定されたパラメータ設定のうち、クロールに有用だったものは約1%だけだった」というものです。 この主張の根拠 Google removed the URL Parameters tool after determining that very few configurations remained useful. 対象範囲： This is a historical Search Console change, not a claim that Google never crawls parameters. 信頼度： 高 · 検証日： 2026-07-14 Google: URL Parameters tool deprecated 復活の可能性についてIllyesは “In theory yes. In practice no.” (翻訳)「理論上はあり得るが、実際には行わない」と答えています。現在、Search Consoleから特定パラメータを無視させる機能はなく、robots.txt、noindex、フラグメントなどをサーバー側で管理する必要があります。

Bingは異なります。 Bing Webmaster ToolsにはURL Normalizationが残っており、除外できるパラメータを指定できます。Fabrice Canelによれば、“our crawler will not visit the URLs with extra parameters except for an occasional test.” (翻訳)「臨時テストを除き、クローラーは余分なパラメータを持つURLへアクセスしない」とされます。Bingと、そのインデックスを利用するAI検索を重視する場合は、約5分で設定する価値があります。

パラメータの一律ブロックについて

広範なrobots.txtルールには注意してください。たとえば?type=が不要なファセットと、別の場所にある正当なページネーションまたはcanonical表示の両方に使われる場合、disallow: /*?*type=は正当なURLまで拒否します。ブロック前に各パラメータの用途を監査し、有用なページまで消す包括ルールより、対象を絞ったルールとallow例外を優先します。

自分のサイトを監査する方法

• クロール： Ahrefs Site AuditやScreaming Frogで、URLの増殖、パラメータパターン、フィルターページの深さを把握します。
• site:件数と実商品数： site:example.comの結果数が実カタログを大きく上回れば、ファセットによるインデックス肥大の兆候です。
• GSC Page Indexingレポート： 「Crawled — currently not indexed」と「Duplicate without user-selected canonical」の大量発生を探します。ファセットはここに現れます。
• サーバーログ： クロール浪費の実態を示します。Googlebotの時間が商品ではなくパラメータURLへどれだけ使われているかを確認できます。

ピラー内での位置付け

ファセットナビゲーションは、Ecommerce SEOを代表する技術課題です。EコマースSEOが通常のSEOと別物なのではなく、難しくなる主因です。Eコマースのサイト構造ではフィルターがカテゴリ階層へ接続し、カテゴリページSEOではフィルターが置かれるページを扱います。さらに、クロールとcanonicalizationにも直結します。情報設計からこの問題へ入る技術SEO担当者も多いですが、実務上の中心はストア側にあります。

AI要約

上級編の要点は次のとおりです。

• 定義: カテゴリまたはアーカイブページにある色、サイズ、価格、ブランドなどのフィルターパネルです。ファセット検索、商品フィルタリングとも呼ばれます。UXには優れますが、組み合わせごとに別のクロール可能なURLを作れるためSEO上の問題になります。
• 規模の問題: 商品10 000件 × 色 × サイズ × 並び順で、重複に近いURLが数百万件になります。Gary Illyesによれば、ファセットナビゲーションはGoogleへ報告される**クロール問題の約50%**です。GoogleはまずURL空間の「大部分」をクロールしなければ無視できません。
• 4つの害: 重複に近いコンテンツ、インデックス肥大化、クロールバジェット浪費、PageRankの分散です。ペナルティの危険ではなく、効率とシグナル分散の問題です。
• 先に戦略を決める: 実際の検索需要があるフィルター組み合わせ（実務上の目安として月間約300+検索）をインデックス登録し、残りを抑制します。
• 制御方法は役割が異なる: robots.txt はクロールを止めますが、インデックス登録は止めません。ブロックされたURLがURLだけの結果として表示されることがあります。noindex はインデックスから削除しますが、認識にクロールが必要なのでクロールバジェットを節約しません。canonical は統合のヒントで、クロールを止めません。URLのフラグメント（#）はGoogleが無視するため、この問題を回避します。
• 禁止事項: noindex と robots.txt のdisallowを併用しないでください。Googleがタグを確認できません。noindex と canonical も矛盾するため、Muellerが述べるとおり一方を選びます。
• ツール: GoogleのURL Parametersツールは2022年に廃止され、サーバー側制御だけが残りました。BingにはURL Normalizationがあります。
• JS/AJAX: クライアント側フィルターはクロール浪費を防ぎますが、価値あるロングテールのファセットもインデックスできなくなります。需要の高い組み合わせは事前レンダリングします。

公式ドキュメント

ファセットナビゲーションとパラメータ処理に関する一次資料です。

Googleの公式資料

• ファセットナビゲーションURLのクロール管理 — Googleが2014年のブログ記事から2024年12月に昇格した恒久的なヘルプ文書です。
• ファセットナビゲーション（クロール基盤版） — robots.txt と & 区切りの例を含む同じ指針です。
• Crawling December: Faceted navigation（2024年） — ファセットを “by far the most common source of overcrawl issues.” (翻訳)「過剰クロール問題の中で群を抜いて多い原因」としたブログ記事です。
• ファセットナビゲーションの最善策と5つの最悪策（2014年） — 現在は後継文書がありますが、経緯を知るために役立つ元の資料です。
• URL Parametersツールの整理（2022年） — 廃止のお知らせです。
• クロールバジェットの最適化 — ファセットによるクロール浪費が問題になる背景です。

Bing／Microsoftの公式資料

• Better than canonical; URL Normalization — Googleとは異なり現在も利用できる、Bingのパラメータ処理ツールについてFabrice Canelが解説しています。

出典からの引用

GoogleとBingの公式発言を集めています。原文ページがテキストフラグメントに対応する場合、リンクから引用箇所へ直接移動できます。

Google — 問題の規模（Gary Illyes）

• “Once it discovers a set of URLs, it cannot make a decision about whether that URL space is good or not unless it crawled a large chunk of that URL space.” (翻訳)「URL集合を発見した後、その大部分をクロールしなければ、そのURL空間の良否を判断できない」 — Gary Illyes、「サーチ・オフ・ザ・レコード」（2025年末のクロール報告）。Search Engine Landの逐語的な記事による伝聞です。最終的な引用として扱う前に番組本編で確認してください。 掲載記事
• “An interesting quirk of URLs is that you can add an infinite (I call BS) number of URL parameters to the URL path, and by that essentially forming new resources.” (翻訳)「URLの興味深い特徴は、URLパスに事実上無限のパラメータを追加し、新しいリソースを作れてしまうことだ」 — Gary Illyes、LinkedIn、2024年8月。Search Engine Journalによる伝聞です。 掲載記事
• “Sometimes you might create these new fake URLs accidentally, exploding your URL space from a balmy 1000 URLs to a scorching 1 million, exciting crawlers that in turn hammer your servers unexpectedly.” (翻訳)「意図せず偽のURLを作ると、URL空間が1 000件から百万件へ膨張し、クローラーがサーバーへ予期せぬ負荷をかけることがある」 — Gary Illyes、LinkedIn、2024年8月。Search Engine Journalによる伝聞です。 掲載記事
• URL Parametersツールの復活について、“In theory yes. In practice no.” (翻訳)「理論上は可能だが、実際には行わない」 — Gary Illyes、LinkedIn、2024年。Search Engine Journalによる伝聞です。 掲載記事

Google—公式文書

• “Google has to crawl the page in order to find the noindex rule.” (翻訳)「Googleはnoindexルールを見つけるためにページをクロールする必要がある」— Google Search Centralのファセットナビゲーション文書。引用へ移動
• “Google Search generally doesn’t support URL fragments in crawling and indexing.” (翻訳)「Google検索は通常、クロールとインデックス登録でURLフラグメントをサポートしません」引用へ移動
• rel="nofollow"について: “every anchor pointing to a specific URL must have the rel=‘nofollow’ attribute in order for it to be effective.” (翻訳)「有効にするには、特定URLを指すすべてのアンカーにrel=‘nofollow’属性が必要です」引用へ移動
• 廃止済みツールについて: “only about 1% of the parameter configurations currently specified in the URL Parameters tool were useful for crawling.” (翻訳)「URL Parametersツールに指定されたパラメータ設定のうち、クロールに有用だったのは約1%だけでした」引用へ移動

Google — John Muellerの説明

• “noindex doesn’t tell Google that you want it combined with something else and that signals should be forwarded.” (翻訳)「noindexは、別のURLと統合してシグナルを転送してほしいという指示ではない」（noindex と canonical を併用すべきでない理由）— John Mueller、Google。Search Engine Journal経由の伝聞です。 解説

Bing — Fabrice Canel

• URL正規化について: “our crawler will not visit the URLs with extra parameters except for an occasional test.” (翻訳)「臨時テストを除き、クローラーは余分なパラメータを持つURLへアクセスしません。」引用へ移動
• “relying on canonical tag is not necessarily the perfect solution to fix all your duplicate content problems.” (翻訳)「重複コンテンツの問題をすべて解決するうえで、canonicalタグだけに頼ることが常に最適とは限りません」引用へ移動

ファセットナビゲーション監査チェックリスト

ファセットが生むクロール・インデックス浪費を特定して修正する手順です。

• サイトをクロールし（Ahrefs Site Audit / Screaming Frog）、実際の商品数に対するパラメータURLの増加量を測ります。
• site:yourdomain.com のインデックス件数を実際の商品数と比較します。大きな差はインデックス肥大化です。
• GSC Page Indexingで、ファセットURLの「Crawled — currently not indexed」と「Duplicate without user-selected canonical」を確認します。
• サーバーログで、Googlebotのクロールが商品ではなくパラメータURLへどれだけ向いているか確認します。
• すべてのフィルターパラメータと役割を一覧化し、ブロックルールを書く前に複数の用途を兼ねていないか確認します。
• ファセット修飾語のキーワード調査を行い、実際の需要がある組み合わせ（目安は月間約300+検索）をインデックス可能にする候補として印を付けます。
• 需要の低いファセットでは、URLごとに抑制方法を1つだけ使い、noindex と robots.txt のdisallowを併用しません。
• インデックス可能なファセットでは、フィルター順序、& 区切り、自己参照canonical、固有の導入文、サイトマップ収録が一貫しているか確認します。
• 空または成立しないフィルター組み合わせは、「結果なし」の200ページではなく 404 を返すようにします。
• Bing Webmaster ToolsのURL Normalizationを設定します。Googleとは別の機能です。

メンタルモデル

1. 戦術より先に戦略を決める — インデックス登録か抑制か。 各ファセットURLについて、実際の検索需要へ対応するならインデックス可能なランディングページにし、UX専用なら抑制します。タグを変更する_前に_この判断を行います。戦略がなければツールでは解決できません。

2. 3つの制御方法は、それぞれ異なる役割を持つ。 この違いを整理すれば、ファセットに関する混乱の大半は解消します。

• robots.txt → クロールを制御（インデックス登録ではない）
• noindex → インデックス登録を制御（クロールではなく、処理にはクロールが必要）
• canonical → シグナルを統合（ヒントであり、クロールは止めない）

3. 抑制方法の判断ルール。

• ボットにURL空間全体を避けさせ、インデックス状態を問わない場合 → robots.txtでdisallow。
• ページを_インデックスから外す_場合 → クロールを許可してnoindex（ブロックしない）。
• 需要のないフィルターでURL自体を作らない場合 → URLフラグメント（#）、または<a href>を出さないAJAX。

4. 予防は修復より優れます。 最も扱いやすいファセットナビゲーションは、不要なURLを最初から作りません。需要のない状態にはフラグメントまたはクライアント側フィルターを使い、需要に基づくものだけを実ページにします。すでにクロールされた百万件のURLを整理する作業は、最初から作らないことよりはるかに大変です。

5. ロングテールとのトレードオフ。 JavaScript/AJAXのフィルタリングは、クロール浪費とインデックス登録を同時に抑えます。不要なファセットには利点ですが、価値のあるものには欠点です。需要の裏付けがある組み合わせは事前レンダリングし、それ以外はクライアント側に残します。

ファセットナビゲーション制御 — チートシート

各制御方法の実際の役割

併用してはいけないもの

• noindexとrobots.txt disallowの併用 → Googleがnoindexを確認できず、インデックスに残る。
• noindexとcanonicalの併用 → シグナルが矛盾する（Muellerは片方を選ぶよう説明）。
• クロールバジェット対策としてcanonicalだけを使う → クロールは止まらない。

インデックス登録するファセットのURLルール

• 区切りは&のみ（カンマ、セミコロン、角括弧は使わない）。
• フィルター順を統一し、canonical形式を1つにする。
• フィルター値を重複させない。
• 空または不可能な組み合わせには200の「結果なし」ではなく404を返す。
• クエリ文字列より分かりやすいパスを使う。/sofas?color=blue&sort=より/sofas/blue/を優先する。

すぐ確認できる要点

• ファセットナビゲーションはGoogleに報告されるクロール問題の約50%（Illyes）。
• GSCのURL Parametersツールは2022年4月に廃止。Googleではサーバー側の制御が必要。
• Bingの同等機能はBing Webmaster ToolsのURL Normalizationで、現在も利用可能。
• Googleはクロールとインデックス登録でURLフラグメント（#）を無視する。
• インデックス可能なファセットページを検討する実務上の需要目安は約300+検索/月。

ファセットナビを診断・管理するツール

• Ahrefs Site Audit — パラメータURLの急増、重複に近いクラスタ、フィルターページのクロール深度を確認します。
• Screaming Frog SEO Spider — カスタム抽出を使ってクロールし、すべてのフィルターパラメータとファセットURL同士のリンク関係を整理します。
• Google Search Console — Page Indexingレポート — 「Crawled — currently not indexed」と「Duplicate without user-selected canonical」にファセット肥大化が現れます。
• GSC URL Inspection — 1つのフィルターURLがどのようにクロール、レンダリング、インデックス登録され、Googleがどのcanonicalを選んだか確認します。
• サーバーログ解析（Screaming Frog Log File Analyser、またはBigQueryへ送ったログ）— パラメータURLへ向かうクロール量を示す実測値です。
• Bing Webmaster Tools — URL Normalization — Bingで現在も利用できるパラメータ制御です。一般的な重複パラメータを事前検出して確認できます。
• キーワード調査（Ahrefs Keywords Explorer） — インデックス可能なランディングページを正当化する需要があるファセット修飾語を探します。

自分で確認する：ファセットナビゲーション

どのファセットURLをインデックス登録し、どの制御方法を使うかを判断する5問です。

変更履歴