求人ページのSEO対策|Googleしごと検索・JobPosting構造化データまで

求人ページのSEOは、タイトルに「求人」「地域」「職種」を入れるだけでは不十分です。

求人詳細には、一般的なWebページと違って、

  • 募集開始日
  • 募集終了日
  • 勤務地
  • 雇用形態
  • 給与
  • 応募条件
  • 採用企業
  • 応募方法

といった構造化された情報があります。

Googleは求人詳細ページ向けにJobPosting構造化データを用意しており、要件を満たす求人はGoogle検索上の求人検索体験へ表示される対象になります。

さらに求人は入れ替わりが速いため、公開時だけでなく、更新・終了・削除までSEO運用に含める必要があります。

この記事では、人材紹介会社、人材派遣会社、求人メディアの求人詳細ページを想定し、Google公式情報を基準に実装・運用のポイントを整理します。

まず区別する|「求人ページSEO」と「求人サイトSEO」は違う

求人サイト全体のSEOでは、

  • 職種・地域一覧
  • 絞り込みURL
  • ページネーション
  • 求人0件ページ
  • 内部リンク
  • クロール・インデックス

などを扱います。

一方、求人ページSEOは個別の1求人が対象です。

求人詳細は、検索から直接着地し、仕事内容を確認して応募するページです。

GoogleのJobPostingガイドラインでも、構造化データは求人一覧や検索結果ではなく、1件の求人を説明する最も具体的なページに付けるよう案内されています。

この役割を混ぜないことが出発点です。

求人詳細ページに最低限必要な情報

求人詳細は、構造化データ以前に、求職者が応募判断できる内容を画面上で確認できることが重要です。

最低限、

  • 職種名
  • 仕事内容
  • 勤務地
  • 給与・報酬
  • 雇用形態
  • 勤務時間
  • 応募資格・経験
  • 福利厚生・待遇
  • 採用企業または派遣・紹介の関係
  • 応募方法

を明確にします。

構造化データに値が入っていても、ページ本文から確認できない状態は避けます。

人材紹介・人材派遣なら「誰の求人か」を曖昧にしない

求職者にとって、

  • 実際の雇用主は誰か
  • 人材紹介会社が仲介するのか
  • 派遣元・派遣先の関係はどうなっているか

は重要です。

求人票の表示だけで誤解が生じないようにします。

Indeed等の外部求人サービスでも、採用企業以外の掲載元について雇用主・人材紹介企業の表示ルールが定められており、求人情報の透明性は重要な論点です。

JobPosting構造化データは何のために使うか

JobPostingは、求人情報を検索エンジンが機械的に理解しやすい形で伝える構造化データです。

Googleは、求人ページにJobPostingを追加することでGoogle検索の求人検索体験に表示される資格を得られると説明しています。

ただし、構造化データを入れれば通常検索順位が上がる、という意味ではありません。

SEO上の役割は、求人内容を正しく構造化し、Googleの求人検索機能へ対応できる状態を作ることです。

JobPostingは求人一覧ではなく「1求人1詳細ページ」へ

Googleは、JobPostingを1件の求人を説明する最も詳細なページへ付けるよう案内しています。

したがって、

  • 10件の求人カードが並ぶ職種一覧
  • 求人検索結果
  • 条件絞り込みページ

に複数求人分のJobPostingをまとめる設計は避けます。

基本は、

職種・地域一覧 → 求人詳細 → 応募

という構造で、JobPostingは求人詳細へ付与します。

主要プロパティは画面表示と一致させる

GoogleがサポートするJobPostingには、datePosteddescriptionhiringOrganizationjobLocationtitlevalidThroughなどがあります。

実装時に重要なのは、構造化データと本文を別々に管理しないことです。

たとえば、

  • 本文の給与は時給1,500円、schemaは1,300円
  • 本文は札幌勤務、schemaは東京
  • 本文は募集終了、schemaは募集中

といった不一致が起きると、運用の信頼性が崩れます。

求人DBの同じ元データから、画面表示と構造化データを生成できる設計が理想です。

validThroughは「募集終了」を管理する重要項目

期限のある求人では、validThroughが重要です。

Googleは、募集期限がある求人についてvalidThroughを指定し、求人が期限前に埋まった場合は求人情報を削除するよう案内しています。

募集終了後にJobPostingが残り続けると、期限切れ求人の構造化データ違反としてSearch Consoleで問題が出る場合があります。

終了時の選択肢

Google公式では、終了求人に対して、

  • validThroughを過去にする
  • ページを404/410で削除する
  • JobPosting構造化データを削除する

といった対応が案内されています。

どれを使うかは、求人ページの再利用価値やCMS運用で決めます。

終了求人を全部残す・全部消す、の二択にしない

求人サイトでは、終了求人が長期的に大量に蓄積します。

一律運用は問題になりやすいため、求人の性質を分けます。

単発で再利用しない求人

募集終了後に検索価値・ユーザー価値が残らないなら、404/410で削除する方が分かりやすい場合があります。

再募集する求人

同じ求人ID・URLを再利用するなら、募集状態を正確に管理します。

募集していない期間は応募可能に見せないことが重要です。

長期的に残したい検索テーマ

「東京 事務 派遣」などの検索需要を残したいのであれば、個別求人を永久保存するのではなく、恒常的な職種・地域ページを検索資産として育てます。

求人詳細の寿命と、SEOランディングページの寿命を分けるという考え方です。

Indexing APIは求人ページで使える

GoogleのIndexing APIは、JobPostingがある求人ページについて、URLの更新・削除をGoogleへ通知できます。

Googleは求人情報のように有効期間が短いコンテンツでは、Indexing APIを利用して更新を個別にプッシュできると案内しています。

通知対象

  • 新規求人を公開した
  • 求人内容を重要更新した
  • 求人を終了・削除した

といったタイミングです。

ただしIndexing APIは、一般的なブログ記事の高速インデックス依頼に使うAPIではありません。

Google公式では、JobPostingまたはBroadcastEventが埋め込まれたVideoObjectページに用途が限定されています。

Indexing APIだけでなくXMLサイトマップも維持する

GoogleはJobPostingについてIndexing APIを推奨していますが、サイト全体のカバレッジのためサイトマップの送信も推奨しています。

運用としては、

  • XMLサイトマップ:サイト全体の求人URL一覧
  • Indexing API:新規・更新・削除の迅速な通知

という役割分担ができます。

サイトマップのlastmodも、実際にページ内容が変わった日時を正しく出します。

canonicalは「同じ求人の正式URL」を決めるために使う

同じ求人が複数URLで表示されるCMSがあります。

たとえば、

  • 職種一覧から開いたURL
  • 地域一覧から開いたURL
  • キャンペーン経由URL

で求人詳細URLが変わる設計です。

Googleは同一求人のコピーが別URLにある場合、正規URLを使用するようJobPostingガイドラインで案内しています。

求人IDごとに正式URLを1つ決め、

  • self canonical
  • サイトマップ
  • 内部リンク
  • JobPosting対象URL

を揃えます。

「directApply」は応募体験を見直すきっかけになる

JobPostingにはdirectApplyというプロパティがあります。

Googleは、不要な中間ステップがなく短い応募プロセスで完了できる場合をdirect applyとして説明しています。

このプロパティ自体の検索表示への影響を過大評価する必要はありませんが、求人ページのCV改善では重要な示唆があります。

求職者が、

  1. 求人詳細を見る
  2. 応募ボタンを押す
  3. 別サイトへ移動
  4. ログインする
  5. もう一度求人を探す
  6. 長いフォームを入力する

という状態なら、検索流入を増やす前に応募導線を改善する余地があります。

求人ページSEOはCVRまで見る

求人ページでは、

  • 応募ボタンの位置
  • スマホ入力
  • 必須項目数
  • LINE・電話・フォームの選択肢
  • 登録と求人応募の違い
  • 応募後の流れ

も確認します。

順位と構造化データだけ整えても、応募できなければ成果にはなりません。

求人タイトルは検索語詰め込みではなく職務を正確に表す

求人ページのtitleタグやH1では、職種・勤務地など検索者が判断する情報を分かりやすくします。

一方で、

「高時給!急募!未経験OK!駅近!一般事務スタッフ東京」

のようにすべてを職種名へ詰め込む設計は避けます。

外部求人媒体では職種名のルールもあり、Indeedもシンプルで正確な職種名を求めています。

自社サイトでも、

  • ページタイトル:検索結果で内容を理解できる
  • H1:求人の職種が明確
  • 本文:給与・勤務地・条件を分けて提示

という構造にします。

求人ページ公開前チェックリスト

  • 1求人につき正式URLが1つある
  • 求人一覧ではなく詳細ページにJobPostingを実装している
  • 構造化データと画面表示が一致している
  • 職種名が明確
  • 勤務地が正確
  • 給与・雇用形態・勤務時間が分かる
  • 応募方法が存在する
  • validThroughまたは終了運用を決めている
  • canonicalが正式URLを指している
  • サイトマップへ正式URLを載せている
  • 新規・更新・削除をIndexing APIで通知できる
  • 終了求人にJobPostingが残り続けない
  • 関連職種・地域ページから内部リンクされている
  • スマートフォンで応募完了できる

まとめ|求人ページSEOは「公開→応募→終了」まで設計する

求人ページSEOで重要なのは、公開時のタイトルや構造化データだけではありません。

公開 → Googleへの通知 → 求職者の閲覧 → 応募 → 求人更新 → 募集終了 → 削除・再利用

という求人のライフサイクル全体を設計します。

特に、

  • JobPostingは個別求人詳細へ
  • 表示内容と構造化データを一致
  • validThrough・終了求人を正しく管理
  • Indexing APIとサイトマップを併用
  • canonicalで正式URLを統一
  • 応募導線までCVとして確認

が人材・求人サイト固有の重要論点です。

求人ページが多数あるのに検索流入や応募につながっていない場合は、求人DBのURL構造、JobPosting、終了求人、内部リンク、応募導線まで一緒に確認できます。

関連記事