求人サイトのSEOは、記事を増やすだけでは改善しません。
求人サイトには、
- 職種一覧
- 地域一覧
- 職種×地域一覧
- 条件別一覧
- 検索・絞り込み結果
- 求人詳細
- 転職・仕事ノウハウ記事
など、多種類のURLが存在します。求人件数が増えるほど、検索エンジンに見せたいページと、ユーザーの絞り込みには必要でも検索結果へ出す必要のないURLを分けることが重要になります。
さらに求人は公開・更新・終了が頻繁に起きます。一般的なサービスサイトと違い、URLを作る設計だけでなく、求人がなくなったときにどう処理するかまでSEO仕様に含めなければなりません。
本記事では、人材紹介会社・人材派遣会社・求人メディアなどの求人DB型サイトを想定し、一覧ページ、求人詳細、絞り込み、JobPosting構造化データ、Indexing API、内部リンクまで実務上の論点を整理します。
求人サイトSEOで最初に確認するのは「ページ数」ではなくURLの種類
求人サイトを診断するときは、まずサイト内にどのようなURLが生成されているかを確認します。
たとえば、同じ「事務職の求人」を扱うだけでも、
/jobs/office//jobs/tokyo/office//jobs/?occupation=office&area=tokyo/jobs/?occupation=office&area=tokyo&salary=2000/job/12345/
のようなURLが存在することがあります。
このうち、どれをSEOランディングページとして育て、どれを検索結果に出さないかが曖昧だと、似た一覧ページが競合したり、無数の絞り込みURLがクロールされたりします。
求人サイトでは、コンテンツ制作の前にURL棚卸しを行う価値があります。
最低限分類したいURL
| URLタイプ | 主な役割 | SEO上の判断 |
|---|---|---|
| 職種ページ | 職種単位の検索入口 | 需要・情報量があればindex |
| 地域ページ | 地域単位の検索入口 | 需要・求人量を見てindex |
| 職種×地域 | 具体的な求人検索入口 | 重要候補。機械量産は避ける |
| 条件別一覧 | 未経験、高時給等 | 独立意図があればindex候補 |
| 絞り込み結果 | UIとしての検索結果 | 原則、無制限indexを避ける |
| 求人詳細 | 個別求人 | index、JobPosting対象 |
| 求人0件ページ | 検索結果なし | 原則indexさせない設計を検討 |
| ノウハウ記事 | 情報収集 | 関連求人への導線が必要 |
この分類表をサイト固有のCMS仕様へ落とします。
職種・地域の一覧ページは「求人カードだけ」にしない
「東京 事務 派遣」「大阪 エンジニア 求人」のような検索では、一覧ページが検索意図に合う場合があります。
しかし、求人カードだけが並んでいる一覧では、求人が減ったときにページ内容が極端に薄くなります。また、同じ求人が複数の一覧へ掲載されるため、各一覧ページの違いも弱くなりがちです。
SEOランディングページとして残す主要一覧には、必要に応じて、
- その職種・地域でどんな求人を扱っているか
- 仕事内容や必要スキル
- 未経験可・経験者向けなどの傾向
- 勤務地や通勤の考え方
- 求人選びで確認すべき条件
- その人材会社が提供する支援
- 関連職種・関連地域へのリンク
を追加します。
ただし、全国の市区町村×全職種へ同じテンプレート文章を差し込むのは避けます。求人件数が少なく固有情報もない組み合わせは、独立URLとしての価値が低いからです。
絞り込み機能は便利だが、SEOではURL爆発を起こしやすい
求人サイトでは、給与、雇用形態、勤務時間、経験、資格、福利厚生など多くの条件で絞り込めます。
ユーザーには便利ですが、URLパラメータで全組み合わせが生成されると、検索エンジンから見るとほぼ無限のURL空間になります。
Googleも、ファセットナビゲーションは多数のURLを生成し、不要URLの過剰クロールや重要ページの発見遅延につながり得ると案内しています。
たとえば、
?area=tokyo&occupation=office&salary=2000&workstyle=remote&sort=new
のようなURLが条件順・並び順違いで何通りも存在すると、同じ求人集合に近いページが大量発生します。
SEO対象にしない絞り込みURL
検索需要がなく、ユーザー操作のためだけに必要なURLは、クロール・インデックス制御を検討します。
方法はサイト仕様によって異なりますが、
- robots.txtで特定パラメータのクロールを制御する
- noindexを利用する
- canonicalで代表URLを示す
- URLを生成しないUI設計にする
- 空結果は404等を返す設計を検討する
などがあります。
重要なのは「全部canonicalで職種トップへ寄せればよい」「全部noindexでよい」と一律に決めないことです。
検索需要のある絞り込みと、UIだけに必要な絞り込みを分けます。
canonicalは重複URLの整理に使うが、万能ではない
求人サイトでは、同じ求人・一覧へ複数URLから到達できることがあります。
Googleはcanonicalについて、重複または非常に類似したURL群の代表URLを示す強いシグナルと説明しています。
たとえばトラッキングパラメータ付きURL、並び順違い、同じ求人を表示する別URLがある場合、代表URLへのcanonicalを検討します。
ただし、内容の大きく違う職種一覧をすべて同じページへcanonicalするのは適切ではありません。
また、canonicalは「このURLを絶対にindexしない」という命令ではありません。不要なURLが大量に生成されているなら、クロール設計そのものを見直す必要があります。
サイトマップとも整合させる
canonicalをAに向けながら、サイトマップにはBを載せる、といった矛盾は避けます。
検索対象として残すページは、
- self canonical
- サイトマップ掲載
- 内部リンク
をできるだけ一致させます。
求人詳細ページは検索結果の末端ページとして設計する
GoogleのJobPostingガイドラインでは、構造化データは「1件の求人を説明する最も詳細なページ」に実装し、求人一覧・検索結果ページには付与しないよう案内されています。
つまり、求人詳細ページは単なるCMSのデータ表示先ではなく、検索から直接来る可能性のあるランディングページです。
最低限、求職者が判断できるように、
- 職種名
- 仕事内容
- 勤務地
- 雇用・契約条件
- 給与
- 勤務時間
- 応募条件
- 会社・職場情報
- 応募方法
を分かりやすく表示します。
構造化データ内にだけ情報があり、画面では確認できない状態は避けます。
同じ求人を複数URLへ載せる場合は正規URLを決める
人材サイトでは、同じ求人が職種別、地域別、キャンペーン別のURLから表示されることがあります。
GoogleのJobPostingガイドラインでも、別URLに同一求人のコピーを掲載する場合は正規URLを使用するよう案内されています。
同じ求人IDに対して複数の詳細URLが発生するCMSなら、
- 求人IDごとの正式URLを1つ決める
- 各経路からそのURLへリンクする
- 重複URLが必要ならcanonicalを統一する
という設計にします。
求人詳細のURLを「どの一覧から来たか」で変えない方が管理しやすいケースが多いです。
求人終了ページをどう扱うかは、サイトの資産性で決める
求人サイトでは、公開ページより終了ページの方が長期的には多くなります。
終了求人をすべて残すと、応募できないページが増えます。すべて削除すると、検索流入や外部リンクを持つURLまで失う可能性があります。
まず求人の種類を分けます。
一回限りの個別求人
再募集可能性が低く、固有価値も残らないなら、募集終了後に404/410で削除する選択肢があります。
再募集しやすい求人
同じ求人IDを再利用する運用なら、募集状態を正確に管理します。募集中でないのに応募可能に見せないことが重要です。
検索資産として残したいテーマ
求人そのものではなく「地域×職種」等の検索需要を取りたいなら、個別求人を永久保存するのではなく、恒常的な職種・地域ページへ価値を集約します。
Googleは終了求人について、validThroughを過去にする、JobPosting構造化データを削除する、ページ自体を404/410にする、などの方法を案内しています。
終了ページのSEOを考えるときは、求人詳細と恒常ページを混同しないことが重要です。
JobPosting構造化データは求人詳細だけへ実装する
求人詳細では、Googleの求人検索体験へ対応するためJobPosting構造化データを検討します。
ただし、構造化データを入れれば通常検索で順位が上がる、という施策ではありません。
Googleが求めているのは、求人ページ上で求職者が見られる内容と構造化データが一致し、現在応募可能な求人であることです。
求人一覧に複数求人分のJobPostingをまとめて入れるのではなく、各求人詳細へ実装します。
実装後はリッチリザルトテストやSearch Consoleでエラーを確認します。
求人の追加・更新・削除にはIndexing APIを使える
求人情報は一般的な固定ページより更新サイクルが短いため、GoogleはJobPostingを持つ求人URLについてIndexing APIの利用を案内しています。
Indexing APIでは、
- 新しい求人URLの通知
- 既存求人URLの更新通知
- 削除した求人URLの通知
ができます。
サイトマップもサイト全体の把握には有用ですが、求人URLの変更通知ではIndexing APIの方が速いクロールを促せるとしてGoogleが推奨しています。
求人CMSを開発・改修できるなら、求人の公開・更新・終了ステータスとIndexing APIを連動させると運用負荷を下げられます。
サイトマップには「検索結果」ではなく正規の求人ページを載せる
GoogleのJobPostingガイドラインでは、求人情報のサイトマップに検索結果ページ、リストページなどを含めず、各求人のcanonical URLを含めるよう案内されています。
求人サイトでは、
- 恒常的な職種・地域ページ
- インデックスさせたい情報記事
- canonicalな求人詳細
など、検索対象とするURLをサイトマップへ載せます。
lastmodも実際の更新時刻と一致させます。毎日全URLの更新日時だけ変えるような実装は避けます。
求人0件ページと少数求人ページのルールを作る
職種×地域の掛け合わせを作ると、求人が0件になるページが必ず出ます。
ユーザーがサイト内検索で一時的に0件になっただけのURLと、SEOランディングページとして育てている恒常ページは扱いを分けます。
一時的な絞り込み結果
検索結果として価値がなければindex対象から外します。Googleは有益なコンテンツのないカテゴリについてnoindexや、サイトから除外する場合には404を返す考え方も案内しています。
恒常的な職種・地域ページ
現在求人が0件でも、その地域・職種について十分な解説があり、登録すれば今後求人を案内できるなどユーザー価値があるなら、一律削除とは限りません。
ただし「求人0件＋テンプレート100文字」のページを大量に残すのは避けます。
ページネーション・無限スクロールでも求人詳細へクロール可能なリンクを作る
求人一覧が100件、1,000件になるとページネーションや無限スクロールを使います。
検索エンジンがJavaScript操作をしなければ求人詳細へたどり着けない設計は避けます。
Googleはサイト構造について、<a href>によるクロール可能なリンクでカテゴリから詳細へ到達できることを推奨しています。
ページネーションを採用する場合も、各ページに固有URLを持たせ、求人詳細へリンクできる構造を基本にします。
内部リンクは「検索ロボットのため」ではなく求職者の比較行動に合わせる
求人詳細を見た人は、同じ職種、近い勤務地、似た条件の求人を比較します。
その行動に合わせて、
- 求人詳細 → 同職種の求人
- 求人詳細 → 同地域の求人
- 職種ページ → 関連職種
- 地域ページ → 近隣エリア
- ノウハウ記事 → 該当職種・求人
をつなぎます。
検索エンジンはサイト内リンクからページ同士の関係や重要度を理解します。SEOのために無関係なリンクを大量設置するのではなく、ユーザーが次に比較したいページを優先します。
求人サイトSEOの診断で見る項目
求人サイトを改善するときは、少なくとも次を確認します。
URL・インデックス
- どの条件でURLが生成されるか
- index対象ページは何件あるか
- パラメータ違い・並び順違いが増殖していないか
- canonicalが適切か
- 0件ページや薄い一覧がindexされていないか
クロール
- 求人詳細まで通常リンクで到達できるか
- ファセットURLへクロールが集中していないか
- サイトマップに正規URLだけ載っているか
求人詳細
- 求人固有情報が十分か
- JobPostingがページ表示内容と一致しているか
- 終了求人が応募可能に見えていないか
- 公開・更新・終了時のIndexing API運用があるか
集客ページ
- 重要な職種・地域ページがあるか
- 一覧に固有説明があるか
- キーワードごとの担当ページが競合していないか
CV
- 求人詳細から応募できるか
- 登録フォームで大きく離脱していないか
- 自然検索からの応募・面談まで計測できるか
SEO診断では順位だけでなく、この構造をSearch Console、GA4、クロールデータ、CMS仕様と合わせて確認します。
求人サイトSEOでよくある失敗
求人数を増やせば自然にSEOも強くなると思う
求人件数は重要ですが、同じ情報構造の詳細URLだけ増えても、検索入口となる職種・地域ページが弱ければ十分に流入を取れません。
市区町村×職種をすべて自動生成する
検索需要も求人も固有情報もないURLまで増え、薄いページ群になります。
絞り込みURLを全部indexさせる
条件組み合わせが膨大になり、類似ページが増えます。
JobPostingを一覧ページへ入れる
Googleのガイドラインでは、最も詳細な1求人のページに実装します。
終了求人を放置する
応募できない求人にJobPostingが残る、検索結果から古い求人へ流入する、といった問題につながります。
SEO記事と求人DBが分断している
ノウハウ記事でアクセスを取っても、関連職種・求人への導線がなければ応募へつながりにくくなります。
まとめ｜求人サイトSEOは「どのページを検索資産にするか」を決める仕事
求人サイトのSEOでは、記事数や求人件数だけを見るのではなく、サイト内に生成されるURLを分類します。
- 職種・地域の主要一覧を検索入口として育てる
- 無制限の絞り込みURLはクロール・インデックスを制御する
- 求人詳細は1求人1正規URLで設計する
- JobPostingは求人詳細へ正確に実装する
- 公開・更新・終了をIndexing API等で通知する
- 終了求人の扱いをCMS運用に組み込む
- 内部リンクで一覧・詳細・記事をつなぐ
- SEO流入を応募・登録まで評価する
この設計ができてから、どの職種・地域ページを追加するか、どの記事を書くかを決めます。
ツリーズコンサルティングでは、人材会社・求人サイトのSearch Consoleだけでなく、求人CMSが作るURL、一覧・詳細の構造、求人終了時の処理まで確認し、検索流入と応募につながる改善優先順位を整理します。
求人ページが多いのに検索流入が伸びない、クロール・インデックスが複雑で整理できていない場合は、サイト構造から確認します。