結論：絞り込みは「便利機能」と「検索の受け皿」を分けて考える
先に結論からお伝えします。
絞り込み条件を増やすこと自体は問題ありません。求職者が条件を絞り込めることは、サイトとしての価値です。
問題になるのは、絞り込みで発生したURLを全部そのまま検索エンジンに拾わせようとしたときです。
絞り込みURLには、大きく分けて2種類あります。
- 検索の受け皿として独立した価値があるURL：その条件で探している人が一定数いて、そのページを見れば求職者の目的が完結する組み合わせ
- サイト内の操作のためだけのURL：「給与順に並べ替えた」「3つ目の条件を足して結果が2件になった」といった、その人のその瞬間の操作結果
1は検索結果に出したいページです。2は検索結果に出す必要がありません。
まずこの線引きを決めることが先で、canonicalやnoindexの話はその後です。
なぜ人材サイトで特に問題になりやすいのか
人材サイトは、掛け合わせられる条件がとにかく多い業種です。
- 勤務地（都道府県／市区町村／駅）
- 職種（大分類／中分類／小分類）
- 雇用形態
- 給与レンジ
- こだわり条件（未経験可、週2日〜、リモート可、など）
- 保有資格
- 業界
これらは、それぞれ単体では十数〜数十パターンでも、掛け合わせた瞬間に組み合わせ数が跳ね上がります。並び替えやページ送りのパラメータが加わると、理論上はほぼ無限にURLが作れる状態になります。
ここで起きやすいのが次の状態です。
- 中身がほぼ同じページが大量にできる
条件Aと条件Bの結果がほとんど同じ、というケースは珍しくありません。 - 求人0件や1件のページが量産される
条件を3つ4つ重ねれば、該当求人がない組み合わせのほうが多くなります。 - 不要なURLに過剰なクロールが発生する
検索エンジンが1サイトを巡回する量は無限ではありません。操作用URLを大量に辿らせている状態は、巡回の使われ方として効率がよいとは言えません。 - 重要な新規ページ・更新ページの発見が遅れる可能性がある
新しく公開した求人や、更新した職種・地域ページに辿り着くまでの経路が長くなります。求人のように入れ替わりが早いページでは、ここが効いてきます。 - URL管理と重複管理が複雑になる
どのURLを検索の受け皿にしているのか、どれが重複しているのかを社内で把握しきれなくなります。後から整理しようとしたときの手間は、想像以上に大きくなります。
「大量URLがあるとペナルティを受ける」という話ではありません。そうではなく、上記のような運用面・発見面の問題が、地味に積み重なっていくという話です。
なお、求人が0件になった条件ページをどう扱うかは、求人0件ページの扱いで別途整理しています。ここでは「そもそもどの組み合わせをページとして持つか」に絞ります。
「職種×勤務地ページをどこまで作るか」との違い
「職種×勤務地の求人ページはどこまで作る？」では、職種と勤務地を掛け合わせたページをどこまで用意するかを扱いました。あちらは意図して設計する固定ページの話です。
この記事で扱うのは、ユーザーの操作によって自動的に生成されてしまうURLの話です。
- 意図して設計するページ：作るかどうかを人が決める
- 絞り込みで生成されるURL：放っておくと勝手に増える
同じ「一覧ページ」でも、コントロールの仕方がまったく違います。
判断基準：どの組み合わせを受け皿にするか
indexさせる／させないを決めるときは、次の4点で見ると判断がぶれにくくなります。
1. その条件で探している人がいるか（検索需要）
実際にその言葉の組み合わせで検索されているかどうかを見ます。
2. そのページ独自の価値があるか
その条件で絞ったからこそ提供できる情報があるか。他のページを見れば済む内容しかないなら、独立したページにする理由がありません。
3. 求人件数・内容が十分にあるか
開いたときに求人が十分に並び、ユーザーの目的が完結するか。求人1件しか出ないページは、検索結果に出しても満足されにくいページです。
4. 他のURLと役割が重複していないか
「営業／東京都」と「東京都／営業」で別URLができているなら、2ページ持つ意味がありません。
ここで注意したいのは、「条件を何個まで掛け合わせてよいか」という数のルールで決めないことです。条件が2つでも需要がなく中身も薄い組み合わせはありますし、条件が3つでも実際によく検索され、ページとして成立する組み合わせもあります。数ではなく、上の4点で個別に判断してください。
ケース別の考え方
ケース1：需要が確認でき、求人も揃っている組み合わせ（職種×地域など）
検索の受け皿として作る価値があります。ただし作る以上は、求人一覧を並べるだけでなく、その職種・地域ならではの説明を入れて、ページとして成立させます。
ケース2：需要が確認できない、または求人が慢性的に少ない組み合わせ
条件の数にかかわらず、indexさせない側に置きます。逆に、「未経験可」「リモート可」のように、それ自体が検索語として使われていて求人も揃っているなら、条件が重なっていても受け皿として検討する余地があります。
ケース3：並び替え・ページ送り・表示件数
検索の受け皿にはなりません。ユーザーの操作用と割り切ります。
ケース4：フリーワード検索の結果ページ
何が入力されるか制御できないため、検索エンジンに拾わせる前提のページにはしないのが一般的な考え方です。
実装・確認項目
ここでよく混乱するのが、canonical・noindex・robots.txtの使い分けです。役割がまったく違うので、順に整理します。
canonical（正規URLの指定）
「似たページが複数あるときの代表はこのURLです」と伝える指定です。強制ではなく、検索エンジン側が参考にする情報として扱われます。
向いている場面：並び替え違い・パラメータ違いなど、中身が実質同じページ。
向いていない場面：中身が違うページ同士。「営業×東京」から「営業一覧」へcanonicalを向ける、といった使い方は、ページの中身が異なるため意図通りに扱われるとは限りません。
noindex（検索結果に出さない指示）
「クロールしてもらってよいが、検索結果には出さないでほしい」という指示です。
向いている場面：ページとしては必要だが、検索の受け皿にはしない絞り込み結果。
注意点：noindexはページを読んでもらって初めて認識されます。後述のrobots.txtでブロックしてしまうと、noindexが読まれません。
robots.txt（クロールの制御）
「このURLは見に来なくてよい」というクロール側の制御です。
向いている場面：無限にURLが生成されうるパラメータなど、そもそも辿らせる必要がない領域。
注意点：すでに検索結果に出ているURLを消す手段ではありません。クロールを止めるとnoindexも読まれないため、「消したいからrobots.txtでブロック」は逆効果になることがあります。
内部リンク
実は、indexコントロールの土台は内部リンクです。検索の受け皿にしたいページにはサイト内から辿れる導線を用意し、操作用のURLには過度な内部リンクを張らない。この整理ができていないまま、タグだけで制御しようとすると破綻しやすくなります。
XMLサイトマップ
サイトマップには「検索結果に出したいURL」だけを載せます。noindexのURLが載っている状態は、指示が矛盾しています。
公開前・公開後の確認
- 意図したURLにcanonicalが入っているか（自己参照含む）
- noindexが、出したいページにまで付いていないか
- robots.txtでブロックした範囲に、出したいページが含まれていないか
- サイトマップのURLとindex対象が一致しているか
- Search Consoleのインデックス作成レポートで、除外の内訳が想定通りか
このあたりは、システム側の実装に依存するため、制作会社や開発ベンダーに指示を出す段階で「どのURLパターンをどう扱うか」を一覧にして渡し、本番反映後に実機で確認するのが確実です。実際、筆者が担当した専門職分野の人材派遣会社の案件でも、実装指示書を作成したうえで本番環境でのQAまで行っています。指定が口頭ベースだと、テンプレート単位で一括適用されて想定外のページにnoindexが付く、といったことが起こり得ます。
よくある間違い
「canonicalを付けておけば全部解決する」
canonicalは重複対策の一手段であって、URL設計そのものを直すものではありません。中身が違うページ同士に向けても意図通りにはなりません。
「robots.txtで止めればindexの問題は片付く」
クロールを止めることと、検索結果から消すことは別です。むしろ止めたことでnoindexが伝わらなくなる場合があります。
「ユーザーに便利だから、全部の絞り込みをページにする」
ユーザーの利便性は絞り込み機能そのもので提供できます。検索の受け皿にするかどうかは別の判断です。
「とりあえず大量に作って様子を見る」
一度公開したURLを後から整理するほうが、最初に設計するより手間がかかります。
「タグの設定だけで内部リンクを見直さない」
導線が残ったままだと、制御の意図とサイトの実態がずれていきます。
まとめ
- 絞り込み機能を増やすことと、絞り込みURLを検索の受け皿にすることは別の話
- 「検索する人がいるか」「ページとして成立しているか」「役割が重複していないか」で線を引く
- canonical・noindex・robots.txtは役割が違い、どれか1つで全部は解決しない
- 内部リンクとサイトマップを、決めた方針と一致させる
- 実装は制作会社任せにせず、本番での確認まで含めて設計する
求人サイトのURL設計や求人ページそのものの見直しを検討されている場合は、お気軽にご相談ください。
関連記事
- 求人詳細ページ全体の設計：求人詳細ページが何千もある場合、SEOはどう対策すればいい？
- 職種×勤務地ページの設計：職種×勤務地の求人ページはどこまで作る？
- 求人サイトSEOの全体像：求人サイトSEO