ファセットナビゲーションのSEO設計｜絞り込みURLの爆発を止め、育てるページだけ残す【2026年版】

求人サイトの「職種×地域×雇用形態×こだわり条件」、不動産サイトの「沿線×駅×間取り×築年数」、ECの「カテゴリ×ブランド×価格帯×カラー」——ユーザーが条件を選んで結果を絞り込むUIを、SEOの世界ではファセットナビゲーションと呼びます。

このUIは、ユーザー体験としては正しい。しかし検索エンジンから見ると、1つのデータベースが無数のURLに化ける装置です。放置すればクロールは食い潰され、重複判定が積み上がり、薄いページがサイト全体の評価を押し下げます。逆に、需要のある組み合わせだけを選んで育てれば、そこがDB型サイトの最大の流入源になります。

本記事は、データベース型サイトのSEO完全ガイドの「インデックスを絞る」を、実装できる粒度まで展開したものです。判断の閾値と、開発チームに渡す要件の書き方まで踏み込みます。

結論:絞り込みURLは「全部通す」でも「全部閉じる」でもない

先に結論を書きます。ファセットURLの扱いで正解に到達しているサイトは、次のどちらでもありません。

• 全部通す:組み合わせ爆発をそのまま検索エンジンに渡すことになり、クロールと評価を浪費します
• 全部閉じる:「営業 求人 大阪 未経験」のような、実際に検索されている掛け合わせまで捨てることになります

正解は、生成しうる組み合わせを閾値で3層に振り分けることです。

そして最も重要なのは、この振り分けを担当者の感覚ではなく数値の閾値で定義し、開発側で条件分岐として実装することです。ルール化さえできれば、以後は新しい掛け合わせが増えても自動的に正しく制御されます。本記事の中心はこの閾値の決め方(4章)と、実装手段の選び分け(5章)です。

1. 何が起きているのか:組み合わせ爆発の実際

「URLが増える」という表現では、規模感が伝わりません。実際に計算します。

求人サイトの属性で計算してみる

一般的な求人サイトが持つ絞り込み条件を、控えめな数で置きます。

ここから段階的に積み上げます。

ステップ1:職種 × 地域 30 × 47 = 1,410通り

ここまでは健全です。「営業 求人 大阪」のような検索需要が明確に存在し、多くのサイトで主戦場になるゾーンです。

ステップ2:雇用形態を追加 雇用形態は「指定なし」を含めて6通り。 1,410 × 6 = 8,460通り

まだ管理可能な範囲です。

ステップ3:こだわり条件を追加 ここで一気に壊れます。こだわり条件は複数選択できるため、組み合わせ数は選択肢数ではなく部分集合の数になります。20個すべてを自由に組み合わせられるなら 2の20乗 = 1,048,576通り。

仮にUI側で「同時に3つまで」と制限をかけたとしても、

• 0個選択:1通り
• 1個選択:20通り
• 2個選択:20×19÷2 = 190通り
• 3個選択:20×19×18÷6 = 1,140通り

合計 1,351通り。

8,460 × 1,351 = 11,429,460通り

同時3つまでという制限をかけてなお、1,100万を超える絞り込みURLが理論上生成されます。

ステップ4:並び替え・表示件数・ページネーション さらに並び替え4種 × 表示件数3種 = 12倍。

11,429,460 × 12 = 137,153,520通り

これに1組み合わせあたり平均5ページのページネーションが乗ると、

137,153,520 × 5 = 685,767,600通り

約6.9億URLです。

実際に到達可能なURLはもっと少ない、が問題は消えない

もちろん、この6.9億がすべてクロールされるわけではありません。実際にGooglebotが到達するのは、サイト内のaタグから辿れるURLと、外部からリンクされているURLに限られます。

しかし多くのDB型サイトでは、絞り込みUIそのものが <a href> で実装されており(SEO的には正しい実装でもあります)、1ページ目から数十本の絞り込みリンクが張られています。そこから2階層辿るだけで、数万〜数十万のURLがクロール対象として露出します。

そして問題の本質は総数ではなく比率です。クロールされるURLの大半が絞り込みの深い階層で占められ、本当に伸ばしたい「職種×地域」1,410ページの更新が検知されない——これが実際に起きる症状です。

2. 放置すると起きる3つの害

害1:クロールの浪費

Googlebotがサイトに割く1日あたりの取得数には上限があります。仮に1日5万URLがクロールされるサイトで、露出している絞り込みURLが1,100万あったとすると、

11,429,460 ÷ 50,000 = 約228日

全体を1周するのに7ヶ月以上かかる計算です。実際にはGooglebotは全URLを均等には回らないため、この単純計算がそのまま起きるわけではありません。しかし、主戦場のページの再クロール間隔が伸びるという結果は確実に起こります。

求人・不動産のように情報の鮮度が価値そのものである業種では、これは順位に直結します。掲載が終わった求人が検索結果に残り、新着が拾われない状態になります。

害2:重複判定

絞り込み条件が細かくなるほど、結果に含まれるアイテムは重複していきます。

• /jobs/sales/osaka/ — 480件
• /jobs/sales/osaka/?experience=none — 470件
• /jobs/sales/osaka/?experience=none&holiday=weekend — 465件

3つのURLの中身は、実質的にほぼ同じです。Googleはこれらを重複と判定し、どれか1つを正規URLとして選びます。そしてその選択は、あなたが指定したURLとは限りません。

このとき何が起きるかというと、内部リンクや外部リンクで蓄積した評価が、意図しないURLに集約されます。育てたかったページが選ばれず、パラメータ付きの雑多なURLが検索結果に出る、という事態も普通に起こります。

害3:薄いページによるサイト全体の評価低下

これが3つのうち最も影響が大きく、最も見落とされます。

条件を重ねるほど結果件数は減ります。「営業 × 大阪 × 未経験可 × 土日休み × リモート可」まで絞ると、該当2件、といったページが大量に生まれます。中身は求人カード2枚とフィルタUIだけ。

こうしたページが数十万枚インデックスされている状態は、Googleから見れば「このサイトは薄いページを大量に持つサイト」です。品質の評価はページ単位だけで完結せず、サイト全体の評価にも影響します。個別ページが順位を取れないだけでなく、まともなページの順位まで引き下げられるのがこの害の厄介なところです。

3. 診断:自サイトの絞り込みURLがどうなっているかを測る

打ち手を決める前に、現状を測ります。手順は3つです。

手順1:生成されうるURLパターンを棚卸しする

まず、実装を読んで(またはフロントエンドの絞り込みUIを操作して)、どの属性がURLに反映されるかを洗い出します。書き出すのはこの5列です。

最右列の「中身が変わるか」が、後の判断をすべて決めます。ここを最初に確定させてください(詳しくは6章)。

そのうえで、1章と同じ手順で理論上の組み合わせ数を計算します。桁を出しておくと、社内で優先度を上げる材料になります。

手順2:Search Consoleの除外理由を読む

Search Consoleの「ページ」レポートで、絞り込みURLがどう扱われているかを確認します。読み方は除外理由ごとに異なります。

診断上の分岐は明快です。

• 「クロール済み - インデックス未登録」が支配的 → 中身の問題。閉じるか、厚くするかの判断が必要
• 「検出 - インデックス未登録」が支配的 → 到達の問題。ただしファセットURLについては、これは正常な状態であることが多い。育てたいページがここに入っていないかだけを確認する
• 「重複しています。ユーザーにより指定された正規URLが〜」が多い → canonicalの指定と実際の中身が噛み合っていない。5章と6章を読んでください

「ページ」レポートは各理由のサンプルURLを表示できます。URLを実際に開いて、それがどの層に属すべきページかを目視するところまでやってください。数字だけ見て施策を決めると、ほぼ確実に誤診します。

手順3:どのファセットURLが内部リンクから露出しているかを見る

Googlebotが到達できるのは、リンクで辿れるURLだけです。したがって「どこからリンクされているか」を把握すれば、露出量を直接コントロールできます。

確認方法は2つあります。

• view-source: で一覧ページの生HTMLを開き、絞り込みリンクを数える。1ページから何本の絞り込みURLが張られているかがそのまま拡散係数になります。20本張られていれば、2階層で400、3階層で8,000です
• クローラーツール(Screaming Frog等)でサイトをクロールし、URLパターン別の件数を集計する。実際に辿れるURLの総数がわかります

なお、絞り込みリンクに rel="nofollow" を付けてクロールを止める手法は、現在は信頼できません。Googleは2019年以降 nofollow をヒントとして扱うと明言しており、クロールされない保証がないからです。露出を止めたいなら、次章以降で扱う「リンク自体を出さない」が確実です。

4. 3層への振り分け設計:閾値を数値で決める

診断が終わったら、生成しうる組み合わせを3層に振り分けます。ここが本記事の核です。

判断に使う3つの変数

振り分けの判断は、次の3変数だけで機械的に決められる形にします。

1. 検索需要:その掛け合わせに対応するキーワードの実測検索volume(月間)
2. 結果件数:そのURLで表示されるアイテム数
3. 重複度:親URLの結果と、どの程度アイテムが重なるか

「感覚で判断」を排除するのが目的です。3変数はいずれもデータで取得でき、うち2つ(結果件数・重複度)はアプリケーション側で実行時に計算できます。

閾値の設計例

以下は求人サイトを想定した設計例です。数値は業種と規模で調整すべきものですが、構造をそのまま流用できます。

「閉じる」に落ちる条件を明示的に書き下すと、次のようになります。

• 結果件数が10件未満(0件を含む)
• 掛け合わせが3属性以上
• 並び替え・表示件数など、中身が変わらないパラメータが付いている(6章)
• ページネーション2ページ目以降のうち、育てる対象でないもの

なぜこの閾値なのか

掛け合わせ2属性まで:検索需要は属性が増えるほど急速に減衰します。「営業 求人 大阪」には需要がありますが、「営業 求人 大阪 未経験 土日休み リモート」で検索する人はほぼいません。そして1章の計算のとおり、URL数が爆発するのは3属性目以降です。需要が消える境界と、URLが爆発する境界がほぼ一致するため、ここで線を引くのが最も合理的です。

結果件数10件以上:件数が一桁のページは、ユーザーにとっても検索エンジンにとっても価値が薄いページになります。閾値は業種によって変わります。ECのように1アイテムの情報量が大きいなら5件、求人のようにカードが小さいなら10〜20件が現実的です。

volumeは「育てる」の条件にだけ使う:volumeがなくても、結果件数が十分あり、内部リンクの経路として機能するページは通す価値があります。閉じてしまうと、その先の詳細ページへのクロール経路まで失われるためです。

閾値をコードに落とす形にする

上記をそのまま実装仕様として書くと、次のようになります。

# ファセットURLのインデックス判定(擬似コード)

facet_count = 選択されている絞り込み属性の数
result_count = 検索結果の件数
has_display_param = sort / per_page が付与されているか
is_curated = 育成対象リスト(手動管理)に含まれるURLか

if has_display_param:
    → canonical = パラメータ除去後のURL、noindexは付けない
elif facet_count >= 3 or result_count < 10:
    → noindex, canonical = 自URL、絞り込みリンクを出力しない
elif is_curated:
    → index, canonical = 自URL、サイトマップに収録、独自コンテンツを出力
else:
    → index, canonical = 自URL、サイトマップ非収録

is_curated(育成対象リスト)だけは、キーワードの実測volumeをもとにSEO側が管理するマスタデータにします。volumeはアプリケーションが実行時に知り得ない情報なので、ここだけは外部から与える設計が現実的です。

なお、閾値の具体値は業種・サイト規模・競合状況で変わります。自社の掛け合わせごとの実測volumeを調べたうえで線を引く作業は、データベース型サイトSEOコンサルティングでも支援している領域です。

5. 実装の選択肢と使い分け

3層への振り分けが決まったら、それをどの技術で実現するかを選びます。選択肢は4つあり、それぞれ効く症状が違います。

選択肢1:canonical

同一・ほぼ同一の内容が複数URLに存在するとき、正規版を示すタグです。

重要な前提として、canonicalは指示ではなくヒントです。 Googleは他のシグナル(内部リンク、サイトマップ、リダイレクト、コンテンツの実際の類似度)と併せて正規URLを判断し、指定に従わないことが普通にあります。従わなかった場合はSearch Consoleの「重複しています。ユーザーにより指定された正規URLがGoogleにより選択されていません」として現れます。

したがって、「canonicalを出したからインデックスされない」と考えてはいけません。検索結果から確実に消したいなら、canonicalではなくnoindexです。

canonicalが素直に効くのは、中身が本当に同一のときだけです。並び替え・表示件数・トラッキングパラメータがこれに該当します。

選択肢2:noindex

検索結果に出さないことを指示するメタタグです。canonicalと違い、これは指示として扱われます。

使うときの注意が2つあります。

注意1:robots.txtでブロックしてはいけません。 ブロックされたURLはHTMLを取得されないため、noindexタグが読まれません。結果として「消したいのに消えない」状態が続きます。消したいならクロールさせて読ませる、が正しい順序です。これはDB型サイトで最も多い事故のひとつです。

注意2:canonicalとの併用は避けます。 「このページは別URLの複製である(canonical)」と「このページは登録するな(noindex)」は矛盾したシグナルで、Googleがどちらを優先するかは予測できません。noindexを付けるページのcanonicalは自URLにしてください。

選択肢3:リンク自体を出さない

最も確実で、最も過小評価されている手段です。

canonicalもnoindexも、Googlebotがそのページを取得してはじめて機能します。つまりクロールバジェットは消費されます。一方、リンクを出力しなければ、そもそもGooglebotはそのURLの存在を知りません。

実装は、絞り込みUIのリンクを条件付きでレンダリングするだけです。

• 2属性まではリンク(<a href>)として出力する
• 3属性目以降の選択肢は、<a> ではなくJavaScriptのイベントハンドラで遷移させる(または <button> にする)

ユーザーは今までどおり絞り込めますが、クローラーには経路が見えません。UXを一切損なわずにクロール量を桁で削れるため、閉じる層に対しては第一選択にすべき手段です。

選択肢4:URLの正規化

そもそも同じ条件が複数のURLで表現されてしまう状態を潰します。

• パラメータの順序を固定する(?a=1&b=2 と ?b=2&a=1 を同一URLに寄せる)
• 空パラメータを出力しない(?experience= を消す)
• デフォルト値を出力しない(?sort=new がデフォルトなら付けない)
• 大文字小文字・末尾スラッシュを統一する

地味ですが、これだけでURL総数が数分の1になるケースがあります。canonicalやnoindexを検討する前に、まずここを潰してください。

なお、Search Consoleの「パラメータ処理ツール」は廃止済みです。パラメータの制御は、上記のようにサイト側の実装で行う必要があります。

症状別の対応表

canonicalはクロール量を減らしません。 取得されたうえで「これは別URLの複製だ」と伝えるだけです。クロール量そのものを減らしたいなら、リンクを出さないか、robots.txtで遮断する(=インデックス済みでないURLに限る)しかありません。

6. 「並び替え」と「絞り込み」の決定的な違い

事故が最も多いのがここです。1章の表で「中身が変わるか」を最初に確定させたのは、この判断のためです。

中身が同じか、違うか

並び替えパラメータが付いたURLは、親URLと同じアイテム集合を、順序だけ変えて表示しています。ユーザーにとっては別の見え方でも、検索エンジンにとっては同じページです。だからcanonicalで親を指すのが正解であり、Googleもその指定に素直に従いやすい典型例です。

絞り込みは違います。「営業 × 大阪」と「営業 × 大阪 × 未経験可」は、表示されるアイテムが違います。別のページです。

混同するとどうなるか

ここを混同した事故は、2方向で起こります。

事故A:絞り込みまでcanonicalで親に寄せてしまう

「パラメータが付いたURLは全部canonicalで親を指す」という実装は、一見きれいで、実際によく書かれます。しかしこれは、検索需要のある絞り込みページを自ら捨てる実装です。

「営業 求人 大阪 未経験」で検索している人がいるのに、そのページを親の「営業 求人 大阪」に寄せてしまえば、その需要は永久に取れません。DB型サイトにおいて、これは最大の機会損失です。

事故B:並び替えまで個別ページとして扱ってしまう

逆に「パラメータ付きURLも中身が違うかもしれないから、全部canonicalは自URLで」とすると、同一内容のページが並び順の数だけインデックス候補になります。4種類の並び替えがあれば、単純に4倍です。1章の計算で12倍になったのはこの部分です。

判定は属性ごとに一度だけ行えばよい

幸い、この判定は属性の設計に対して行うもので、URLごとに判断する必要はありません。3章の手順1で作った表の「中身が変わるか」列が、そのまま実装の分岐条件になります。属性が追加されたときにこの列を埋めるルールさえ運用に組み込めば、以後の事故は防げます。

7. 育てると決めたファセットページの作り込み

「育てる」に振り分けたページは、通しただけでは順位を取れません。同じデータベースを持つ競合と、中身が同じになるからです。

DBから計算で出せる独自集計値を足す

一覧ページが弱い理由は、ほぼ例外なくデータの羅列しかないからです。かといって、数千ページ分の紹介文を手書きするのは現実的ではありません。

現実解は、その掛け合わせ固有の集計値をDBから計算して出すことです。手書きゼロで、ページごとに異なる情報が入ります。

これらはすべてDBに対する集計クエリ1本で出せます。テンプレートに一度実装すれば、育てる対象の全ページに同時に反映される——これがDB型SEOのレバレッジです。

キャッシュ設計だけ注意してください。ページ表示のたびに重い集計を走らせると応答時間が伸び、クロール数の抑制につながります。日次バッチで集計テーブルを更新するのが標準的な解です。

titleを動的に生成する

育てるファセットページのtitleは、絞り込み条件と件数を反映させます。

# 生成ルールの例(絞り込み一覧テンプレート)
件数 >= 50 : 「{地域}の{職種}求人｜{こだわり条件}の求人{件数}件｜{サイト名}」
件数 >= 10 : 「{地域}の{職種}求人｜{こだわり条件}{件数}件｜{サイト名}」
件数 <  10 : (育てる対象外。noindexへ)

件数を入れると情報量と鮮度が同時に上がりますが、テンプレート変更は全ページに波及するため、悪化した場合の被害も全ページ規模です。可能なら一部の掛け合わせで先行検証してからの展開を推奨します。

内部リンクを供給する

育てると決めたページに、リンクが1本も張られていないケースは珍しくありません。絞り込みUIから辿れるだけでは、階層が深く評価が届きません。

• 親の一覧ページに「人気の条件」リンクを設置する。育成対象リスト(4章の is_curated)をそのままリンク一覧として出力すれば、実装は1箇所で済みます
• 詳細ページから該当する絞り込み一覧へ還流させる。詳細ページは枚数が多いため、最大のリンク供給源になります
• サイトマップに収録するのは育てる層だけにする。「通すが育てない」層まで入れると、育てたいページのシグナルが埋もれます

8. 開発チームへの依頼粒度

ファセット制御は、SEO側が単独で実行できる施策がひとつもありません。すべてが実装依頼になります。そして「絞り込みページのSEOを改善してください」という粒度の依頼は、開発チームにとって着手不能です。

着手できる依頼は、対象・条件・実装・対象外・検証の5点がそろったものです。

例1:表示制御パラメータの正規化

【対象】/jobs/{職種}/{地域}/ 一覧テンプレート
【条件】クエリパラメータ sort / per_page / view のいずれかが付与されている場合
【実装】<link rel="canonical"> に、当該3パラメータを除去したURLを出力する
　　　　例: /jobs/sales/osaka/?sort=new&per_page=50
　　　　　→ canonical: /jobs/sales/osaka/
　　　　また、sort=new(デフォルト値)はURLに出力しない
【対象外】絞り込みパラメータ(tags / employment)は結果内容が変わるため本対応の対象外。
　　　　　canonicalは自URLのままとする
【検証】下記4URLでcanonicalの出力を確認
　　　　1. /jobs/sales/osaka/
　　　　2. /jobs/sales/osaka/?sort=salary
　　　　3. /jobs/sales/osaka/?tags=remote        → canonicalは自URL(変更なし)
　　　　4. /jobs/sales/osaka/?tags=remote&sort=salary → canonical: /jobs/sales/osaka/?tags=remote
　　　　ステージングで先行確認のうえリリース

例2:絞り込みURLのインデックス制御

【対象】/jobs/ 配下の全一覧テンプレート
【条件】以下のいずれかに該当する場合
　　　　(a) 絞り込み属性の選択数が3つ以上
　　　　(b) 検索結果の件数が10件未満
【実装】
　　　　1. <meta name="robots" content="noindex,follow"> を出力する
　　　　2. canonicalは自URLを出力する(親に寄せない)
　　　　3. (a)に該当する状態を生む絞り込みリンクは <a href> で出力しない。
　　　　   2属性選択済みの状態では、3つ目の選択肢を <button> + JS遷移で実装する
【対象外】
　　　　- 育成対象リスト(seo_curated_facets テーブル)に登録済みのURLは、
　　　　  上記条件に該当しても index のまま維持する
　　　　- robots.txt での Disallow は追加しない(noindexが読まれなくなるため)
【検証】
　　　　1. 3属性選択時のURLで noindex が出力されること
　　　　2. 結果9件のURLで noindex、10件のURLで index となること
　　　　3. 育成対象リスト登録URLで index が維持されること
　　　　4. 2属性選択済みページの生HTMLに、3属性目のaタグが存在しないこと
　　　　   (view-source: で確認)

「対象外」を書くことが特に重要です。 これがないと、開発側が善意で範囲を広げ、育てるべきページまで閉じられるという事故が起きます。ファセット制御は「条件分岐の境界」がすべてなので、境界の外側を明示しない依頼は危険です。

また、検証項目は生HTMLで確認できる形で書いてください。「正しく設定されていること」では、実装者もレビュアーも判定できません。

9. よくある質問(FAQ)

Q. 絞り込みページは、そもそもインデックスさせるべきですか? A. 一律の答えはなく、閾値で振り分けます(4章)。検索需要が実測で存在し、結果件数が十分なものだけを育て、3属性以上の掛け合わせや結果が少ないものは閉じる、が基本方針です。「全部閉じる」を選ぶと、DB型サイトで最も流入を生むゾーンを自ら捨てることになります。

Q. canonicalを設定したのに、Search Consoleで別のURLが正規と表示されます。 A. canonicalは指示ではなくヒントであり、Googleが従わないことは正常な挙動の範囲です。従わない場合、原因はほぼ2つです。(1) 指定先と実際の中身が違いすぎる、(2) 逆に中身がほぼ同一で、内部リンクなど他のシグナルが別URLを支持している。前者ならcanonicalの指定先を見直し、後者なら内部リンクとサイトマップを、正規にしたいURLに揃えてください。確実に検索結果から消したい場合はcanonicalではなくnoindexを使います。

Q. 絞り込みURLをrobots.txtでまとめてブロックするのは有効ですか? A. すでにインデックスされているURLに対しては逆効果です。 ブロックするとHTMLが取得されず、noindexタグが読まれないため、インデックスに残り続けます。正しい順序は、まずnoindexを出してクロールさせ、インデックスから消えたことを確認してからブロックする、です。そもそもインデックスされていないURL群のクロールを止める目的なら、robots.txtは有効な選択肢になります。

Q. 並び替えパラメータにもnoindexを付けるべきですか? A. 不要です。並び替えは中身が同じなのでcanonicalで親を指すのが正解で、noindexとの併用は矛盾したシグナルになります(6章)。並び替えでURLが増えること自体を減らしたいなら、デフォルト値をURLに出力しない、パラメータ順序を固定する、といった正規化のほうが効果的です。

Q. 絞り込みリンクをJavaScript遷移にすると、ユーザー体験は落ちませんか? A. クリックして絞り込めるという体験は変わりません。落ちるのは「そのURLを直接シェアできるか」「戻るボタンで戻れるか」で、後者は History API で解決できます。3属性目以降の深い絞り込みはシェアされる頻度も低いため、実務上の影響は限定的です。なお、2属性目までの主要な絞り込みは通常どおり <a href> で実装し、クローラーに辿らせてください。

まとめ:ファセット制御の設計手順

1. 属性ごとに「中身が変わるか」を確定させる(3章・6章) — 表示制御と絞り込みを分けるのが最初
2. 理論上の組み合わせ数を計算する(1章) — 桁を出すことが社内の優先度を動かす
3. Search Consoleの除外理由で症状を特定する(3章) — 中身の問題か、到達の問題か
4. 3層への振り分け閾値を数値で定義する(4章) — 感覚ではなく条件分岐として実装できる形に
5. 症状に応じて手段を選ぶ(5章) — canonicalはクロールを減らさない。閉じるならリンクを出さない
6. 育てる層だけを作り込む(7章) — DBから計算で出せる集計値が最も費用対効果が高い
7. 5点セットで開発に依頼する(8章) — 対象・条件・実装・対象外・検証

ファセットナビゲーションの制御は、テクニカルSEOの中でも判断ミスの代償が大きい領域です。閉じすぎれば需要を捨て、開きすぎればサイト全体の評価を落とす。そして一度実装されたルールは、以後生成される全URLに効き続けます。

自社サイトのどの掛け合わせを育て、どこで線を引くべきか——具体的な設計をご希望の方は、データベース型サイトSEOコンサルティングのページをご覧いただくか、無料相談をご利用ください。サイト全体の設計はデータベース型サイトのSEO完全ガイドで解説しています。

株式会社ハウクレイジー 代表取締役 関口拓人

早稲田大学在学中に月間数千万PVのメディアをゼロから立ち上げ、株式会社ゲームエイトの創業に参画。同社執行役員として月間3億PV規模サイトのSEO・広告事業を統括。業界No.1プログラミングスクールを運営する株式会社インフラトップのCMOを経て独立し、株式会社ハウクレイジーを設立。大規模メディアからデータベース型サイトまで、累計50サイト以上のマーケティング支援を実施。

プロフィール詳細

どの絞り込み条件を育て、どれを閉じるか。この閾値設計は自社の検索需要とページ数に依存します。現状のURL構成を見たうえで無料でご提案します。

無料で絞り込みURLの設計を相談する