採用サイトの求人検索設計

採用サイトの求人検索で起こりやすい問題

求人検索では、次のような問題が起こりやすくなります。

• 求人を職種別に探せない
• 社内の部門名が分類名になっている
• 同じ仕事内容の求人が異なるカテゴリに分散している
• 職種名が抽象的で内容を判断できない
• 勤務地が求人詳細を開かないと分からない
• リモートワークの条件が分からない
• 正社員と契約社員が混在している
• 新卒・中途・アルバイト求人が同じ一覧に並んでいる
• 絞り込み条件を変更するたびに画面が初期化される
• 何件該当したか分からない
• 求人カードに情報が少なく、すべて開く必要がある
• 絞り込み条件が多すぎて候補者が迷う
• URLが変化せず、検索結果を共有できない
• 求人が終了すると404になる
• 求人が0件の場合に何も表示されない

特に問題なのは、企業側の管理単位と、候補者が仕事を探す単位が一致していないことです。

例えば、企業内では次のように求人を管理している場合があります。

• プロダクト統括本部
• ビジネス推進本部
• X事業部
• グロースユニット
• CX戦略室

これらは社内では意味が通じても、候補者には仕事内容が伝わらないことがあります。

候補者が探しているのは、次のような分類です。

• ソフトウェアエンジニア
• カスタマーサクセス
• 法人営業
• プロダクトマネージャー
• 人事
• 経理
• 東京勤務
• 大阪勤務
• フルリモート
• 未経験可
• マネージャー候補

求人検索は、社内組織図を見せる画面ではなく、候補者の探索基準を求人情報へ変換する画面として設計する必要があります。

Ahrefsで見る求人検索の検索需要

Ahrefsで、求人検索、求人一覧、職種、勤務地、リモートワークに関連するキーワードを調査しました。

※検索ボリュームはAhrefsが推定する直近12カ月の平均値です。

※KDは被リンク状況を中心に算出される相対的な指標です。「求人検索」のような広いキーワードは、大手求人媒体や検索サービスが上位を占めるため、企業採用サイトが直接上位表示を狙う対象には向きません。

広い「求人検索」より条件別の需要が大きい

「求人検索」は月間3,200回検索されていますが、検索結果は求人媒体や求人検索エンジンが中心になります。

企業の採用サイトが、「求人検索」という広いキーワードだけで流入を獲得するのは現実的ではありません。

一方で、「フルリモート 求人」は26,000回、「在宅勤務 求人」は3,700回、「リモート 求人」は1,700回検索されています。

候補者は、企業名や職種だけでなく、働き方を軸に求人を探しています。

採用サイトでは、次のような条件を求人情報として構造化することが重要です。

• 職種
• 勤務地
• リモート可否
• 雇用形態
• 経験レベル
• 事業・プロダクト
• 勤務時間
• 転勤の有無

求人一覧は指名検索後の重要な到達先になる

企業採用サイトの求人一覧は、必ずしも非指名検索だけを目的とするものではありません。

候補者は、次のような指名検索から訪問する可能性があります。

• 企業名＋求人
• 企業名＋採用
• 企業名＋中途採用
• 企業名＋エンジニア求人
• 企業名＋勤務地
• 企業名＋リモート
• 企業名＋年収

そのため、求人一覧はSEO記事ではなく、指名検索や外部メディアから来た候補者を適切な求人へ案内するランディングページとしても重要です。

求人検索を設計する前に整理すること

検索項目を決める前に、現在の求人を棚卸しします。

整理すべき情報は次のとおりです。

1. どの採用区分があるか
2. どの職種を募集しているか
3. 求人ごとの勤務地はどこか
4. どの働き方が選べるか
5. 雇用形態は何か
6. 経験レベルはどう分かれるか
7. どの事業・プロダクトに所属するか
8. 求人ごとに共通して持てる情報は何か
9. 今後、求人件数がどの程度増えるか

採用区分を分ける

新卒、中途、アルバイト、インターンなど、採用区分によって候補者が確認したい情報は異なります。

求人件数が多い場合は、採用区分ごとに入口を分けます。

すべてを一つの検索画面へ統合すると、候補者に関係のない条件が増え、使いにくくなる可能性があります。

候補者が使う職種名へ変換する

社内の職位名やチーム名を、そのまま検索カテゴリに使用しないようにします。

求人詳細では正式な部署名を表示しても構いません。

ただし、検索カテゴリは候補者が理解できる職種名を優先します。

現在の求人件数だけで設計しない

求人が10件しかない時点で細かな検索条件を増やすと、ほとんどの組み合わせが0件になります。

反対に、現在は10件でも、数年後に100件へ増える企業では、単純な一覧では探しにくくなります。

求人件数の規模に応じて設計を変えます。

必要以上に高機能な検索を実装するのではなく、求人件数と候補者の探索行動に合わせます。

求人検索の基本構造

求人検索は、次の要素で構成します。

• 検索・絞り込みエリア
• 選択中の条件
• 該当件数
• 並び替え
• 求人カード
• 条件解除
• 0件時の案内
• 関連職種・求人への導線
• タレント登録・カジュアル面談

候補者が今どの条件で探しているか、何件該当しているかを常に把握できるようにします。

主要条件は最初から表示する

使用頻度が高い条件は、検索画面上ですぐに選べるようにします。

• 職種
• 勤務地
• 働き方
• 雇用形態

経験レベル、事業、年収などは、求人件数や採用戦略に応じて「詳細条件」に配置します。

すべての条件を最初から表示すると、画面が複雑になりやすいためです。

選択中の条件をタグで表示する

選択した条件は、検索結果上部にタグとして表示します。

ソフトウェアエンジニア × 東京 × リモート可

各タグから個別に解除できるようにします。

候補者が条件を変更する際に、検索画面へ戻る必要がない設計が理想です。

該当件数を条件選択時に示す

条件を選択する前後で、何件該当するかを示します。

ソフトウェアエンジニア（12）
カスタマーサクセス（4）
人事（2）

0件になる条件を選びにくくなり、候補者が検索結果を予測できます。

職種による絞り込み設計

職種は、求人検索における最も重要な分類の一つです。

職種カテゴリの粒度をそろえる

次のような分類は、粒度がそろっていません。

• エンジニア
• カスタマーサクセス
• プロダクト企画部
• 経営管理本部
• 営業マネージャー

職種、部署、役職が混ざっています。

検索カテゴリは、同じ粒度で整理します。

職種の大分類例

• エンジニア
• プロダクト
• デザイン
• セールス
• カスタマーサクセス
• マーケティング
• コーポレート
• 事業開発
• オペレーション

大分類の下に、必要に応じて詳細職種を配置します。

エンジニアの詳細分類例

• フロントエンド
• バックエンド
• モバイル
• SRE・インフラ
• セキュリティ
• QA
• データ
• AI・機械学習
• エンジニアリングマネージャー

職種分類と求人名を一致させすぎない

求人名は採用要件に応じて細かくなります。

例えば次の求人があるとします。

• シニアバックエンドエンジニア
• バックエンドエンジニア・決済基盤
• バックエンドエンジニア・新規事業
• バックエンドエンジニア・テックリード候補

これらはすべて「バックエンドエンジニア」という検索カテゴリへ含めます。

求人名をそのまま検索カテゴリにすると、カテゴリが細分化されすぎます。

職種カテゴリから職種紹介へつなげる

求人検索だけでは、職種全体の役割やキャリアを理解できません。

職種カテゴリには、職種紹介ページへの導線を配置します。

カスタマーサクセスの仕事内容、顧客、組織、キャリアを詳しく見る

求人が複数ある職種ほど、一覧と職種ハブを分けることが重要です。

勤務地による絞り込み設計

勤務地は、候補者が応募可能性を判断する重要な条件です。

拠点名だけでなく地域から探せるようにする

全国に拠点がある企業では、候補者が拠点名を知らないことがあります。

求人件数が多い場合は、地域から都道府県・拠点へ絞り込める構造にします。

求人件数が少ない場合は、勤務地名を直接表示しても構いません。

勤務地と配属拠点を区別する

次の情報が混同されることがあります。

• 所属オフィス
• 実際に勤務する場所
• 研修を受ける場所
• 顧客先
• 出張先
• リモート勤務時の居住地

採用サイトでは、候補者が実際に働く場所を明確にします。

曖昧な表現

東京本社所属。リモートワーク可。

具体的な表現

所属拠点は東京本社ですが、原則として週3日まで自宅勤務が可能です。月2回程度、顧客先への訪問があります。居住地は首都圏を想定しています。

全国勤務と勤務地限定を分ける

総合職や店舗職では、転勤の有無も重要です。

• 全国転勤あり
• 地域限定
• 拠点限定
• 転勤なし
• 本人同意による異動
• 将来的な転勤可能性あり

勤務地検索だけでなく、転勤条件も求人カードや詳細ページで確認できるようにします。

働き方による絞り込み設計

「リモート可」と表示するだけでは、実際の働き方は分かりません。

リモートワークを段階に分ける

企業ごとに言葉の意味が異なるため、自社の定義を明示します。

「フルリモート」と表現する場合でも、次の条件を説明します。

• 居住可能地域
• 出社の有無
• 入社時研修の出社
• 全社会議
• 顧客訪問
• 通信費・機材
• 勤務場所の制限

働き方を求人単位で管理する

会社としてリモートワーク制度があっても、すべての職種で同じ条件とは限りません。

例えば、次のような違いがあります。

• エンジニアはフルリモート可能
• 営業は週2回出社
• コーポレート職は原則出社
• 店舗職は勤務地固定
• 管理職のみ定期出社が必要

会社全体の制度ページだけでなく、求人単位で働き方を表示します。

フレックス・勤務時間も検索条件になり得る

候補者によっては、勤務時間が勤務地以上に重要です。

求人件数が多い場合は、次の条件も検討します。

• フレックスタイム
• コアタイムなし
• 時短勤務
• シフト勤務
• 夜勤あり
• 土日勤務あり
• 副業可
• 週4日勤務
• 短時間正社員

ただし、条件を増やしすぎると検索が複雑になります。

採用上の差別化や候補者の応募判断へ強く影響する条件だけを採用します。

雇用形態による絞り込み設計

雇用形態が異なる求人は、候補者の目的も異なります。

• 正社員
• 契約社員
• アルバイト・パート
• 業務委託
• インターン
• 嘱託
• 派遣

新卒・中途・アルバイトを同じ一覧に掲載する場合は、雇用形態を目立つ位置に表示します。

ただし、採用フローや必要情報が大きく異なる場合は、入口を分けた方が使いやすくなります。

業務委託を「求人」として混在させるか検討する

正社員採用と業務委託募集では、契約条件や応募判断が異なります。

同じ検索画面に掲載する場合は、次の情報を明確にします。

• 契約形態
• 稼働日数
• 稼働時間
• 報酬
• 契約期間
• 出社条件
• 正社員登用の有無

情報粒度が大きく異なる場合は、別一覧に分けます。

経験レベルによる絞り込み設計

同じ職種でも、求める経験によって求人は異なります。

• 未経験可
• 第二新卒
• メンバー
• シニア
• リーダー
• マネージャー
• 部門責任者
• 専門職
• 新卒

「未経験可」の意味を明確にする

未経験には複数の種類があります。

• 業界未経験
• 職種未経験
• 業界・職種未経験
• 専門領域未経験
• マネジメント未経験

求人カードに「未経験可」とだけ表示すると、応募可能な範囲が分かりません。

具体的な表示例

SaaS業界未経験可／法人営業経験必須

セキュリティ専任未経験可／Web開発経験必須

職種・業界ともに未経験可／研修あり

（内部リンク）異業界からの採用を増やす採用サイト設計｜前職経験と募集職種のつなぎ方

役職ではなく期待役割を伝える

「シニア」「リード」「マネージャー候補」は企業によって意味が異なります。

求人カードや職種ページでは、次のような違いを説明します。

• 自分の担当業務を自立して進める
• 難易度の高い案件を担当する
• 複数メンバーを支援する
• チームの目標を担う
• 採用や評価を担う
• 部門戦略を担う

事業・プロダクトによる絞り込み設計

複数事業・複数プロダクトを持つ企業では、職種だけで求人を選びにくい場合があります。

例えば、同じカスタマーサクセスでも、担当プロダクトによって次の要素が異なります。

• 顧客
• 解決する課題
• 契約単価
• 支援方法
• 組織
• キャリア
• 必要な業界知識

そのため、必要に応じて次の分類を設けます。

• 事業
• プロダクト
• ブランド
• 顧客業界
• 顧客規模
• 新規事業・既存事業

事業名だけでなく説明を添える

候補者が社内のプロダクト名を知らない場合があります。

検索条件や求人カードでは、短い説明を加えます。

HRプロダクト
人事・労務業務を支援するクラウドサービス

FinTech事業
企業間決済と請求業務を支援するサービス

職種と事業を組み合わせることで、候補者は仕事内容を想像しやすくなります。

フリーワード検索は必要か

求人件数が少ない場合、フリーワード検索は必須ではありません。

職種、勤務地、働き方による絞り込みだけで十分なこともあります。

フリーワード検索が有効なケース

• 求人が50件以上ある
• 多数の職種名がある
• 技術名で探す候補者が多い
• 資格や専門領域で探される
• 事業・プロダクトが多い
• 店舗・拠点名で探される

検索対象には、次の情報を含めます。

• 求人タイトル
• 職種
• 部署
• 仕事内容
• 必須経験
• 技術
• 勤務地
• プロダクト
• キーワードタグ

表記ゆれに対応する

候補者が使う言葉は統一されていません。

• プロダクトマネージャー／PdM
• カスタマーサクセス／CS
• 人事／HR
• ソフトウェアエンジニア／SE
• バックエンド／サーバーサイド
• リモート／在宅勤務／テレワーク

同義語や略称でも求人を見つけられるようにします。

0件検索を分析する

フリーワード検索を設ける場合は、検索ログを確認します。

0件になったキーワードから、次の改善ができます。

• 同義語を追加する
• 求人タイトルを見直す
• 新しい検索カテゴリを追加する
• 候補者が求める職種を把握する
• 求人がない職種のタレント登録を設ける

求人カードに掲載すべき情報

求人一覧で比較できる情報が少ないと、候補者はすべての求人詳細を開く必要があります。

一方、情報を詰め込みすぎると一覧性が失われます。

求人カードの基本情報

• 求人タイトル
• 職種
• 勤務地
• 働き方
• 雇用形態
• 事業・プロダクト
• 経験レベル
• 短い仕事内容
• 年収レンジ
• 更新日
• 詳細へのリンク

企業によって優先順位は異なりますが、職種、勤務地、働き方は一覧上で確認できるようにします。

求人タイトルだけに情報を詰め込まない

次のようなタイトルは、長くなりすぎて比較しにくくなります。

【フルリモート可／新規事業／マネージャー候補】エンタープライズ向けSaaSカスタマーサクセス

タイトルは職種と担当領域を中心にし、その他の情報はタグとして表示します。

求人タイトル

エンタープライズカスタマーサクセス

タグ

新規事業
フルリモート可
マネージャー候補
正社員

社内用語を求人タイトルに使わない

次のような求人タイトルは、候補者が仕事内容を理解しにくくなります。

• Growth Partner
• Value Creator
• Success Architect
• Business Producer
• X Unit Member

独自名称を使用する場合も、一般的な職種名を併記します。

Success Architect／カスタマーサクセス

Business Producer／法人営業・事業開発

掲載日より更新日を重視する

候補者は、求人が現在も有効かを気にします。

「2023年公開」と表示されると、現在も募集しているか不安になります。

次の情報を表示します。

• 最終更新日
• 募集中
• 募集終了
• 新着
• 積極採用中

求人が長期間継続する場合も、定期的に内容を確認します。

並び替えをどう設計するか

求人件数が多い場合は、候補者が比較しやすい並び替えを設けます。

• 新着順
• 更新順
• おすすめ順
• 職種順
• 勤務地順
• 年収順

おすすめ順の基準を明確にする

企業都合で採用優先度の高い求人を上位表示する場合は、「積極採用中」などのラベルを付けます。

何の基準か分からないランキングにすると、候補者に不信感を与える可能性があります。

デフォルトは候補者の使いやすさを優先する

求人件数が少ない場合は、新着順より職種別にまとめた方が探しやすいことがあります。

例えば、次の順序です。

1. 職種カテゴリ
2. 各職種内で新着順
3. 積極採用求人をラベル表示

検索結果が0件の場合の設計

条件を選択して求人が0件になったときに、空白の画面だけを表示してはいけません。

条件を変更しやすくする

0件画面には、次の導線を置きます。

• 一部条件を解除する
• すべての条件を解除する
• 近い職種を見る
• 近い勤務地を見る
• リモート可能な求人を見る
• 求人一覧へ戻る

近い求人を提案する

例えば、次の条件で0件だったとします。

プロダクトマネージャー × 福岡 × フルリモート

近い求人として、次を表示できます。

• プロダクトマネージャー × 東京 × フルリモート
• 事業企画 × 福岡
• プロダクトマネージャー × 全国勤務可

ただし、候補者が選択した必須条件を勝手に無視しないようにします。

「条件に近い求人」と明示します。

求人がない職種を情報ごと消さない

現在募集していない職種でも、候補者からの関心が高い場合があります。

求人0件でも、次のページへ案内します。

• 職種紹介
• 社員インタビュー
• タレント登録
• 求人通知
• 採用イベント
• カジュアル面談

職種情報まで削除すると、将来の候補者との接点を失います。

タレント登録・求人通知を設ける

候補者に合う求人が現在ない場合でも、将来募集する可能性があります。

そのため、次の導線を用意します。

• タレント登録
• 求人通知
• メールマガジン
• 採用イベント
• カジュアル面談
• オープンポジション

オープンポジションを万能な受け皿にしない

オープンポジションは便利ですが、対象が曖昧だと候補者が応募しにくくなります。

次の情報を示します。

• 想定する職種
• 対象となる経験
• 選考の進め方
• すぐに紹介できる求人がない場合の扱い
• 登録と正式応募の違い

求人一覧と職種ページの役割を分ける

求人一覧は、現在募集中のポジションを探すページです。

職種ページは、求人があるかどうかに関係なく、その仕事を理解するページです。

求人一覧だけでは、候補者は職種の違いやキャリアを理解できません。

職種ページだけでは、現在どのポジションへ応募できるか分かりません。

両者を相互リンクします。

ATSと採用サイトの役割分担

求人管理システムを利用している場合、採用サイトとATSのどちらで検索を実装するかを決める必要があります。

採用サイトが担う役割

• 企業・事業の理解
• 職種の理解
• 組織・社員・キャリア
• 求人検索の入口
• 関連記事との接続
• SEO・指名検索の受け皿

ATSが担う役割

• 求人情報の管理
• 応募フォーム
• 応募者管理
• 選考ステータス
• 求人公開・終了
• 採用担当者の運用

理想は、ATSの求人データを採用サイトへ連携し、採用サイトのデザインと検索体験の中で表示する構成です。

ATSへ遷移する場合の注意点

採用サイトからATSへ移動する場合は、次の点を確認します。

• デザインが大きく変わらないか
• 選択した条件が引き継がれるか
• 戻る操作が分かりやすいか
• 別ドメインへ移動することが分かるか
• 計測が分断されないか
• 求人終了時のリンク切れがないか
• スマートフォンで使いやすいか

求人一覧だけをATSへ丸投げすると、採用サイト内の職種ページや社員記事と接続しにくくなります。

求人検索のURL設計

検索条件ごとにURLを持たせるかどうかは、SEOと運用の両面から検討します。

安定したカテゴリURLを持つ

検索需要や候補者ニーズが大きいカテゴリは、固定URLを持たせます。

/jobs/
/jobs/engineering/
/jobs/sales/
/jobs/customer-success/
/jobs/tokyo/
/jobs/osaka/
/jobs/remote/

これらのページには、求人一覧だけでなく、短い説明や関連職種情報を掲載できます。

すべての組み合わせをインデックスさせない

職種、勤務地、働き方、雇用形態を自由に組み合わせると、大量のURLが生成されます。

/jobs/?job=engineer&location=tokyo&workstyle=remote

すべてを検索エンジンへ登録すると、内容の薄い重複ページが増える可能性があります。

SEO対象にするページと、ユーザーの絞り込み専用ページを分けます。

SEO対象にしやすいページ

• エンジニア求人
• 営業求人
• 東京の求人
• 大阪の求人
• リモート求人
• 新卒採用
• 中途採用

原則として検索操作用にするページ

• 3条件以上を組み合わせた検索結果
• 0件の検索結果
• 並び替えだけが異なるURL
• 一時的な条件
• 求人数が1件もないカテゴリ

検索条件を共有・保存できるようにする

候補者が検索結果をブックマークしたり、他者へ共有したりできるように、条件をURLへ反映します。

ただし、SEO上のインデックス制御とは分けて考えます。

URLを持たせつつ、必要に応じてcanonicalやnoindexを設定します。

求人詳細ページの設計

求人一覧の使いやすさは、求人詳細の情報構造とも関係します。

求人カードで興味を持った後、次の情報を確認できるようにします。

• 募集背景
• 仕事内容
• 対象顧客・プロダクト
• 担当範囲
• チーム構成
• 必須経験
• 歓迎経験
• 求める能力
• 入社後の期待
• 給与
• 勤務地
• 働き方
• 選考
• 関連記事
• 関連求人

求人一覧で表示したタグと、求人詳細の内容が一致していることが重要です。

例えば、一覧で「フルリモート」と表示し、詳細では「月1回出社必須」と書かれている場合は、定義の見直しが必要です。

求人終了時の設計

求人終了後にページを削除すると、検索流入、被リンク、ブックマークが失われます。

募集終了ページを一定期間残す

求人終了後は、次の情報を表示します。

• 募集終了したこと
• 終了日
• 同じ職種の求人
• 関連職種
• 職種紹介
• タレント登録
• 求人一覧

過去求人を永久に残す必要はありませんが、即座に404へするより、候補者を次の情報へ案内できます。

同じ求人を再募集する場合のURLを統一する

同じ職種・役割を繰り返し募集する場合、毎回新しいURLを発行すると情報資産が分散します。

求人内容が大きく変わらない場合は、安定したURLを再利用する方法があります。

/jobs/backend-engineer/

募集停止時は「現在募集していません」と表示し、再開時に更新します。

ただし、求人管理システムの仕様や選考管理との整合性を確認します。

終了求人を一覧から除外する

検索結果には、原則として現在応募可能な求人だけを表示します。

過去求人を検索対象へ残す場合は、「募集終了」と明確に表示し、候補者が誤って応募しないようにします。

スマートフォンでの求人検索設計

求人検索はスマートフォンで利用されることも多いため、PC版の絞り込み画面をそのまま縮小してはいけません。

絞り込みは画面下部から開けるようにする

スマートフォンでは、検索条件をモーダルやドロワーで表示します。

画面下部に次のボタンを固定する方法があります。

絞り込み
24件の求人を見る

条件選択後に件数を確認してから検索結果へ戻れるようにします。

選択中の条件を省略しすぎない

画面が狭くても、現在の条件を確認できるようにします。

条件タグが多い場合は、横スクロールや折りたたみを利用します。

求人カードのタップ領域を広くする

求人タイトルだけをリンクにするのではなく、カード全体をタップ可能にします。

ただし、お気に入りや別ボタンを置く場合は、誤操作が起きないように分けます。

求人検索のアクセシビリティ

求人検索は、キーボード操作や支援技術でも利用できるようにします。

• フォーム要素にラベルを付ける
• 選択状態を色だけで表現しない
• チェックボックスやラジオボタンを適切に使う
• 結果件数の変化を伝える
• フォーカス位置を維持する
• モーダルを閉じた後に元の位置へ戻す
• 求人カードの見出し構造を整える
• エラーや0件状態を文章で伝える

見た目だけを優先して、独自実装の選択UIを増やしすぎないことが重要です。

求人検索の効果を計測する

求人一覧のPVだけでは、検索体験の良し悪しは判断できません。

確認する指標

0件検索を改善に活用する

0件検索の条件を分析すると、候補者が求めている求人が分かります。

例えば、次の検索が多い場合があります。

• デザイナー × フルリモート
• 大阪 × カスタマーサクセス
• 未経験 × エンジニア
• 週4日 × 正社員

求人がない場合でも、採用計画や働き方の見直しに活用できます。

求人検索から応募までを計測する

次の流れを追えるようにします。

求人一覧
↓
条件選択
↓
求人詳細
↓
関連記事・職種ページ
↓
応募開始
↓
応募完了

ATSへ別ドメインで遷移する場合は、クロスドメイン計測やUTMパラメータを設定します。

求人検索で優先して整備すべき機能

優先度1：職種・勤務地の絞り込み

まずは、多くの候補者が使う条件を整えます。

• 職種
• 勤務地
• 該当件数
• 条件解除
• 求人カード

優先度2：働き方・雇用形態

リモートワークや雇用形態が求人ごとに異なる場合に追加します。

優先度3：職種ハブとの接続

求人一覧から職種紹介へ進み、職種紹介から求人一覧へ戻れるようにします。

優先度4：0件時の代替導線

近い求人、タレント登録、職種紹介を表示します。

優先度5：フリーワード・条件保存

求人件数が多い企業では、フリーワード、検索条件保存、求人通知を追加します。

求人一覧ページの構成例

ファーストビュー

• ページタイトル
• 求人一覧の説明
• 公開中の求人数
• 採用区分の切り替え
• フリーワード検索

絞り込み

• 職種
• 勤務地
• 働き方
• 雇用形態
• 経験レベル
• 事業・プロダクト
• 詳細条件

検索結果上部

• 該当件数
• 選択中の条件
• 条件解除
• 並び替え
• 表示形式

求人カード

• 求人タイトル
• 職種
• 事業・プロダクト
• 勤務地
• 働き方
• 雇用形態
• 年収
• 短い説明
• 更新日

0件時

• 条件変更
• 近い求人
• 職種紹介
• タレント登録
• 求人通知

関連情報

• 職種から仕事を知る
• 社員インタビュー
• 働く環境
• 給与・評価・福利厚生
• 選考
• FAQ

（内部リンク）採用サイトで給与・評価・福利厚生をどう見せるか

求人検索の改善チェックリスト

分類

• 候補者が理解できる職種名を使っているか
• 職種、部署、役職が混在していないか
• 職種カテゴリの粒度がそろっているか
• 採用区分を適切に分けているか
• 求人件数に対して分類が細かすぎないか

絞り込み

• 職種で探せるか
• 勤務地で探せるか
• 働き方で探せるか
• 雇用形態で探せるか
• 経験レベルを判断できるか
• 選択中の条件が分かるか
• 条件を個別に解除できるか

求人カード

• 求人タイトルから仕事内容が分かるか
• 職種が分かるか
• 勤務地が分かるか
• リモート条件が分かるか
• 雇用形態が分かるか
• 年収レンジを確認できるか
• 最終更新日が分かるか

検索結果

• 該当件数が分かるか
• 0件時に代替導線があるか
• 近い求人を確認できるか
• 条件を共有・保存できるか
• スマートフォンでも操作しやすいか

職種・コンテンツ連携

• 求人一覧から職種ページへ移動できるか
• 職種ページから関連求人へ移動できるか
• 社員記事から同じ職種の求人へ進めるか
• 働き方ページから該当求人を探せるか
• 募集がなくても職種情報が残るか

運用

• ATSと採用サイトの情報が一致しているか
• 募集終了求人が一覧から除外されるか
• 終了求人から関連求人へ誘導できるか
• URLが毎回変わりすぎていないか
• 求人情報の更新責任者が決まっているか
• 0件検索を分析しているか

まとめ

採用サイトの求人一覧は、公開中の求人を並べるだけのページではありません。

Ahrefsでは、「フルリモート 求人」が月間26,000回、「在宅勤務 求人」が3,700回、「求人検索」が3,200回、「リモート 求人」が1,700回検索されています。

候補者は、職種だけでなく、勤務地や働き方を重要な条件として求人を探しています。

一方で、企業の採用サイトでは、社内組織の分類をそのまま使い、候補者が自分に合う求人を見つけにくくなっている場合があります。

そのため、求人検索では次の三つを明確にする必要があります。

1. 候補者が理解できる職種分類になっているか
2. 勤務地・働き方・雇用形態など、応募判断に必要な条件で探せるか
3. 検索結果から職種理解、求人詳細、応募へ進めるか

求人検索の目的は、検索機能を高機能にすることではありません。

候補者が自分に関係する仕事だけを見つけ、比較し、応募可能性を判断できる状態をつくることです。

採用サイトの求人一覧を、求人管理システムの公開画面から、候補者が職種、勤務地、働き方を起点に仕事を探せる意思決定画面へ変えることが、求人発見率と応募率の改善につながります。