求人詳細ページのSEOは、タイトルに職種名や地域名を入れて終わりではありません。1件の求人には、仕事内容、勤務地、給与、雇用形態、応募条件、募集期間など、求職者が応募を判断するための情報があります。さらに求人は公開後も内容が更新されますし、募集が終われば表示や構造化データも合わせて変えていく必要があります。
そのため求人ページは、「公開する → Googleに伝える → 求職者が見る → 応募する → 更新する → 募集を終了する」までを一つの運用として設計することが大切です。この記事では、人材紹介会社・人材派遣会社・求人メディアの求人詳細ページを想定し、JobPosting構造化データ、正式URL、募集終了時の扱い、Indexing API、応募導線までを順番に整理します。
まず区別する｜「求人ページSEO」と「求人サイトSEO」は違う
求人サイト全体のSEOでは、職種・地域一覧、絞り込みURL、求人0件ページ、内部リンクなど、サイト全体の構造を扱います。一方、この記事で扱う「求人ページSEO」は、1件の求人詳細ページが対象です。求人詳細は、Google検索や求人検索機能から直接訪れた求職者が、仕事内容や条件を確認して応募するページです。
JobPosting構造化データも、求人一覧ではなく、1件の求人を詳しく説明する求人詳細ページへ設定します。求人DB全体のURL設計や一覧ページの扱いは、求人サイトのSEO対策｜求人DB・一覧・詳細ページをどう設計するかで整理しています。
求人詳細には、まず応募判断に必要な情報を表示する
構造化データを設定する前に、求職者が求人ページを見て「自分が応募できる仕事か」を判断できる状態にします。最低限、次の情報はページ上で確認できるようにします。
- 職種名
- 仕事内容
- 勤務地
- 給与・報酬
- 雇用形態
- 勤務時間
- 応募資格・必要な経験
- 福利厚生・待遇
- 採用企業、または人材紹介・派遣の関係
- 応募方法
構造化データの中にだけ給与や勤務地があり、実際のページでは確認できない状態は避けます。
人材紹介・人材派遣では「誰の求人か」を分かるようにする
人材紹介・人材派遣では、求職者から見て会社同士の関係が分かりにくくなることがあります。たとえば、次のような点です。
- 実際の雇用主はどの会社か
- 人材紹介会社が仲介する求人なのか
- 派遣元と派遣先はどのような関係か
公開できる範囲には制約がありますが、求人ページを読んだ人が「誰が募集し、自分はどこと雇用・契約関係を持つのか」を誤解しない表示にします。
JobPostingは「求人をGoogleへ正しく伝える」ために使う
JobPostingは、求人情報をGoogleが理解しやすい形で伝えるための構造化データです。Googleは、求人詳細ページにJobPostingを設定すると、要件を満たす求人がGoogle検索の求人検索体験に表示される対象になり得ると案内しています。ただし、JobPostingを設定すれば通常のGoogle検索順位が上がる、という意味ではありません。
役割は、ページに書かれている求人内容を構造化し、Googleの求人検索機能へ正確に伝えることです。Googleの現在の仕様は、求人情報（JobPosting）の構造化データに関する公式ガイドで確認できます。
JobPostingは求人一覧ではなく「1求人1詳細ページ」へ
JobPostingは、複数求人が並ぶ一覧ページへまとめて設定するのではなく、1件の求人を詳しく説明するページへ設定します。たとえば、職種別求人一覧、地域別求人一覧、求人検索結果、条件絞り込みページではなく、次の流れの「求人詳細」が対象です。
求人一覧にも求人情報は表示されますが、JobPostingの中心は1求人の詳細ページです。
JobPostingと画面表示は、同じ求人データから作る
求人ページを長く運用すると、画面表示と構造化データの内容がずれることがあります。たとえば、次のような状態です。
- ページ本文では時給1,500円、JobPostingでは1,300円
- ページ本文では札幌勤務、JobPostingでは東京
- ページ本文では募集終了、JobPostingでは募集中
このような不一致を防ぐには、求人DBにある同じ元データから、画面表示とJobPostingの両方を生成できる設計が扱いやすくなります。JobPostingには、datePosted、description、hiringOrganization、jobLocation、title、validThroughなど、求人内容を伝えるための項目があります。すべてを構造化データ側だけで管理するのではなく、まず求職者が見るページの内容を正しく保ち、その内容とJobPostingを一致させます。
求人タイトルは、検索語を詰め込まず職種を分かりやすくする
求人ページのtitleタグやH1では、求職者が検索結果やページを見たときに、どんな仕事か判断できることを優先します。たとえば、
高時給！急募！未経験OK！駅近！一般事務スタッフ東京
のように、給与、募集状況、条件、地域をすべて職種名へ詰め込む必要はありません。基本は、次のように役割を分けます。
| 場所 | 役割 |
|---|---|
| titleタグ | 検索結果で求人内容を判断できるようにする |
| H1 | 求人の職種・仕事を明確にする |
| 本文 | 給与・勤務地・勤務時間・応募条件などを分けて示す |
検索キーワードを詰め込むことより、求人を探している人が内容を誤解しないことを優先します。
「1求人＝1つの正式URL」を決める
同じ求人が、職種一覧、地域一覧、特集ページなど複数の場所に掲載されることは普通です。ただし、そのたびに求人詳細のURLまで変わると、同じ求人を複数URLで持つことになります。たとえば、
/jobs/office/123/
/jobs/tokyo/123/
/campaign/123/がすべて同じ求人詳細を表示するような状態です。この場合は求人IDごとに正式なURLを1つ決め、できるだけ各一覧からそのURLへリンクします。複数URLが必要な場合は、canonicalでも正式URLを揃えます。
GoogleのJobPostingガイドでも、同じ求人が複数URLに存在する場合はcanonical URLを使うよう案内されています。求人詳細の正式URL、内部リンク、サイトマップ、JobPostingを同じURLへ揃えておくと、運用時の混乱を減らせます。
募集終了までを求人ページの運用に含める
求人ページは、公開した時点で完成ではありません。求人には募集期限があり、採用が決まれば予定より早く終了する場合もあります。そのため、公開するときから「募集が終わったらどうするか」を決めておきます。
validThroughで募集期限を管理する
期限のある求人では、JobPostingのvalidThroughで募集期限を伝えられます。募集が予定より早く終了した場合も、終了した求人を応募可能な状態のまま残さないようにします。
Googleは、終了した求人に対して、状況に応じて次のような対応を案内しています。
validThroughを過去の日付にする- 求人ページを削除して404または410を返す
- ページからJobPosting構造化データを削除する
どれを選ぶかは、その求人ページを再利用するか、ページとして残す価値があるかによって変わります。
終了求人を「全部残す」「全部消す」の二択にしない
求人サイトには、時間が経つほど終了求人が蓄積します。すべて同じ方法で扱うのではなく、求人の性質で分けます。
| 求人の状態 | 主な考え方 |
|---|---|
| 一回限りで再募集しない | ページを削除し、404/410とする選択肢 |
| 同じ求人を再募集する | 同じURLを使う場合は募集状態を正確に管理 |
| 長期的に残したい検索テーマ | 個別求人ではなく職種・地域ページを育てる |
たとえば「東京 事務 派遣」という検索需要を長期的に取りたいからといって、終了した個別求人を永久に残す必要はありません。長く育てたい検索テーマは職種・地域ページへ集約し、個別求人は求人としての役割が終わった後の扱いを別に考えます。
新規・更新・終了をGoogleへ伝える
求人は入れ替わりが速いため、公開した求人をGoogleが見つけるまで待つだけではなく、更新を通知できる仕組みがあります。
Indexing APIは求人ページで利用できる
GoogleのIndexing APIは、JobPostingを持つ求人ページについて、新規公開・更新・削除をGoogleへ通知できます。たとえば、新しい求人を公開した、給与や勤務地など重要な情報を更新した、求人を終了・削除した、といったタイミングです。
Indexing APIは、一般的なブログ記事を早くGoogle検索へ出すために使うAPIではありません。求人ページなど、Googleが対象として定めているページで利用します。
XMLサイトマップも維持する
Indexing APIを使う場合でも、XMLサイトマップは維持します。役割は次のように分けて考えると分かりやすくなります。
| 方法 | 主な役割 |
|---|---|
| Indexing API | 新規・更新・削除をGoogleへ早く通知する |
| XMLサイトマップ | サイト内の正規求人URLをまとめて伝える |
Googleも、求人URLではIndexing APIの利用を推奨しつつ、サイト全体をカバーするためにサイトマップの送信も推奨しています。サイトマップのlastmodには、実際に求人ページの内容が変更された時刻を設定します。
求人ページは「検索に出る」だけでなく、応募できる状態にする
求人詳細ページの目的は、Googleに求人を認識してもらうことではなく、条件が合う求職者に応募してもらうことです。順位やJobPostingだけを整えても、応募までの流れが使いにくければ成果にはつながりません。
directApplyは応募体験を見直す材料になる
JobPostingにはdirectApplyという項目があります。Googleは、不要な中間ステップがなく、短い手順で求人へ応募できる場合を「直接応募」として説明しています。なお、Googleはこの情報の使い方について現在も開発中としており、設定したからといって検索表示への効果を期待するものではありません。
重要なのは、directApplyという項目そのものより、応募までの流れです。たとえば、次のようになっているなら、求人ページへ検索流入を増やす前に改善できる余地があります。
応募までの導線を確認する
求人ページでは、たとえば次の点を確認します。
- 応募ボタンが見つけやすいか
- スマートフォンで入力しやすいか
- 必須項目が多すぎないか
- LINE・電話・フォームなど、自社で必要な応募方法が分かるか
- 会員登録と求人応募の違いが分かるか
- 応募後の流れが分かるか
求人ページSEOは、検索流入だけでなく、応募まで進めるかを含めて確認します。
求人ページ公開・運用チェックリスト
- 1求人につき正式URLが1つ決まっている
- 求人一覧ではなく、求人詳細にJobPostingを設定している
- JobPostingと画面表示の内容が一致している
- 職種名が分かりやすい
- 勤務地が正確に表示されている
- 給与・雇用形態・勤務時間が分かる
- 応募方法がある
- 募集期限や終了時の処理を決めている
- canonicalが正式URLを指している
- XMLサイトマップに正式な求人URLを載せている
- 新規・更新・削除をIndexing APIで通知できる
- 終了求人にJobPostingが残り続けない
- 関連する職種・地域ページから求人詳細へリンクされている
- スマートフォンで応募を完了できる
まとめ｜求人ページSEOは「公開→応募→終了」まで設計する
求人ページSEOでは、公開時のタイトルや構造化データだけを見るのではありません。
公開 → Googleへの通知 → 求職者の閲覧 → 応募 → 求人更新 → 募集終了 → 削除・再利用
という、求人のライフサイクル全体を設計します。その中でも、次の点は求人ページを運用するうえで特に確認したい項目です。
- JobPostingは個別の求人詳細へ設定する
- 画面表示と構造化データを一致させる
- 1求人につき正式URLを1つ決める
- 募集終了後の処理を事前に決める
- Indexing APIとXMLサイトマップを使い分ける
- 応募までの導線を確認する
求人ページが多数あるのに検索流入や応募につながっていない場合は、求人DBのURL構造、JobPosting、終了求人、内部リンク、応募導線までまとめて確認できます。