検索ブランド相談室 | 検索と評判の専門メディア
無料相談

JobPosting構造化データの監査方法｜求人情報・給与・勤務地・期限の不一致を確認

部署：マーケティング担当者部署：人事・採用担当者レベル：実践SEO採用サイト、採用マーケティング、Webサイト改善 公開日 2026.08.30
求人ページと確認シートを照合し、JobPosting構造化データの不一致を監査している担当者の手元

採用サイトにJobPosting構造化データを実装していても、求人本文と給与・勤務地・雇用形態・掲載期限・応募導線がずれていれば、正しく運用できているとはいえません。

構造化データ全般の監査は「構造化データのSEO監査方法｜実装後のエラー・内容不一致・重複を検証する手順」で扱います。本記事の役割は、JobPosting固有の本文整合と、募集開始から終了・再募集までの求人ライフサイクル監査です。

そのため、サイト横断のschema棚卸し、一般的なnoindex・robots.txt診断、ツール操作そのものは補助確認までに縮小します。主に確認するのは、baseSalary、jobLocation / jobLocationType、employmentType、validThrough、directApplyと実際の応募導線です。

この記事では、求人URLごとに本文とJobPostingを突き合わせ、期限到達・早期終了・非公開・同職種の再募集まで、どの情報をいつ更新するかを整理します。

JobPosting構造化データの監査では「存在」より「本文との一致」を確認する

JobPosting構造化データの監査で最初に確認すべきなのは、コードが入っているかどうかではありません。

テクニカルSEOの全体像を先に確認したい場合は、テクニカルSEOの全体像を参照してください。本記事では、その中でもJobPosting固有項目と求人ライフサイクルの監査に絞って実務手順を整理します。

求人ページに表示されている情報と、JobPostingでGoogleへ伝えている情報が一致しているかを確認することが重要です。

Googleは、構造化データがページの実際の内容を正しく表していることを求めています。たとえば、構造化データに給与を設定しているにもかかわらず、ページ本文では給与を確認できない状態はガイドライン上の問題になります。

また、JobPostingは求人一覧ページではなく、原則として1件の求人を詳しく説明するページに実装します。構造化データも、求職者が同じページ上で読める求人内容を表す必要があります。

そのため監査では、次の3つを同時に見ます。

確認対象 確認すること
求人本文 応募者に実際に表示されている募集条件
JobPosting Googleへ送っている職種・給与・勤務地・期限など
ページ状態 インデックス可否、応募可否、募集終了状態

求人本文、JobPosting構造化データ、ページ状態の3つを求人単位で照合する監査の全体構造

JobPosting監査では、求人本文だけでも構造化データだけでもなく、募集・応募・インデックスを含むページ状態まで同時に照合します。

リッチリザルトテストで「有効」と判定されても、構造化データの内容が実際のページと異なれば問題は残ります。Googleも、テストで技術的に有効であることと、検索結果での表示を保証することは別だと説明しています。

監査単位は「1求人1URL」と募集状態でそろえる

JobPosting監査では、サイト全体のURL棚卸しを作り直す必要はありません。採用管理側の求人IDを起点に、現在の募集状態と公開中の求人URLが1対1で追える状態を作ります。

最低限、次の6項目があれば監査できます。

  • 求人ID
  • 求人URL
  • 募集中／停止中／終了
  • 給与
  • 勤務地・勤務形態
  • 応募先URLまたは応募方法

ここで確認したいのは「URLが何件あるか」ではなく、人事側では終了しているのに、Web上では募集中として読める求人が残っていないかです。

Googleは、JobPostingを求人一覧ではなく、原則として1件の求人を詳しく説明するページへ付与するよう求めています。監査表も1求人1行にそろえ、本文・構造化データ・応募可否・募集状態を同じ行で確認します。

STEP1｜JobPostingの必須項目を求人本文と照合する

GoogleがJobPostingで必須としている主要項目は、datePosted、description、hiringOrganization、jobLocation、titleです。

完全リモート求人などでは勤務地の扱いが異なるため、勤務形態に応じて確認します。

監査では、単に項目が存在するかではなく、次のように求人本文と横並びで確認します。

項目 求人本文で確認 構造化データで確認 主な不一致
title 職種名 title 本文は営業職、JSON-LDは営業マネージャー
description 仕事内容・応募条件 description 古い仕事内容が残っている
datePosted 初回掲載日 datePosted 更新日を毎回初回掲載日に置き換えている
hiringOrganization 採用企業 hiringOrganization グループ会社名との混同
jobLocation 実際の勤務地 jobLocation 本社住所を勤務地として設定

titleには職種名だけを入れる

titleは求人ページのキャッチコピーではなく、原則として職務の名称です。

Googleは、求人コード、住所、日付、給与、会社名をtitleへ混在させないことを推奨しています。過剰な記号や装飾も避けます。

たとえば、

「年収600万円以上！東京勤務・株式会社○○のWebエンジニア募集」

ではなく、

「Webエンジニア」

のように職種そのものを設定します。

descriptionは求人本文と内容が一致しているかを見る

descriptionには、仕事内容、資格、スキル、勤務時間、学歴や経験など、求人の詳細を記述できます。

採用担当者が本文だけ変更し、JSON-LDのdescriptionが以前のまま残っていないかを確認してください。

職種、給与、勤務地、雇用形態について求人本文とJobPosting構造化データを横並びで照合する例

JobPostingはプロパティが存在するかだけでなく、求人本文の職種・給与・勤務地・雇用形態と実際の値が一致しているか確認します。

STEP2｜給与のbaseSalaryを監査する

給与は、JobPosting監査で不一致が生じやすい項目です。

GoogleのbaseSalaryは、雇用主が提示している実際の基本給を表します。給与レンジの場合はminValueとmaxValueを使用し、単位にはHOUR、DAY、WEEK、MONTH、YEARなどを指定します。

たとえば求人本文が、

「月給30万円〜45万円」

となっている場合、構造化データ側も月給30万円〜45万円として対応しているか確認します。

監査ポイントは次の通りです。

  • 本文の給与と数値が一致しているか
  • 月給と年収を取り違えていないか
  • minValueとmaxValueが逆転していないか
  • currencyがJPYになっているか
  • unitTextが給与表示の単位と一致しているか
  • 以前の給与改定前の数字が残っていないか

特に重要なのは、構造化データにだけ給与を記載しないことです。

Googleは、マークアップされた情報を求人ページ上でも確認できる必要があると説明しています。

STEP3｜勤務地とリモート勤務の指定を監査する

jobLocationには「求人を掲載した会社の所在地」ではなく、実際に従業員が勤務する場所を設定します。

住所を設定する場合は、addressCountryも必要です。複数勤務地がある場合はjobLocationを複数設定できます。

次のような不一致を確認してください。

  • 東京勤務なのに本社の大阪住所が設定されている
  • 複数拠点募集なのに1拠点しか設定されていない
  • 求人本文ではフルリモートなのに物理勤務地だけが設定されている
  • ハイブリッド勤務なのに完全リモートとして指定されている

完全リモート求人では、jobLocationTypeにTELECOMMUTEを設定します。

ただし、GoogleはTELECOMMUTEを業務時間中、常にリモートワークする求人に使用するよう定めています。一部在宅や「相談によりリモート可」の求人に安易に設定しないことが重要です。

応募者が所在できる地域に条件がある場合は、applicantLocationRequirementsも確認します。

STEP4｜雇用形態のemploymentTypeを確認する

求人本文の雇用形態とemploymentTypeが一致しているか確認します。

Googleが示す主な値には、次があります。

値 内容
FULL_TIME フルタイム
PART_TIME パートタイム
CONTRACTOR 契約形態
TEMPORARY 一時的な雇用
INTERN インターン
VOLUNTEER ボランティア
PER_DIEM 日雇い
OTHER その他

複数の雇用形態を設定することもできます。

CMSやATSで「正社員」「契約社員」などの日本語入力からJSON-LDを自動生成している場合は、変換ルールが正しいかも確認してください。

STEP5｜validThroughは「期限の有無」と実際の募集状態を照合する

validThroughは、求人情報に有効期限がある場合に必須となるプロパティです。期限がない、または期限が分からない求人へ、機械的に将来日を入れる項目ではありません。

監査では、構造化データの日付だけでなく、採用管理上の募集状態と照合します。

確認項目 監査内容
明確な応募期限がある validThroughがその期限と一致しているか
期限がない 不要なvalidThroughを自動付与していないか
期限前に採用充足した 将来日のvalidThroughを残したまま応募可能にしていないか
期限を過ぎた 求人が募集中のように見え続けていないか
再募集した 旧募集の期限・応募先・求人識別情報が残っていないか

Googleは、期限切れ求人をサイトから削除することを理想とし、ページを残す場合でもvalidThroughを過去にする、またはJobPostingを削除するなどの終了処理を求めています。

JobPostingのvalidThrough確認から募集終了後の構造化データ削除や404・410までを整理した処理フロー

ここで重要なのは、validThroughを過去にしただけで運用完了と考えないことです。応募ボタン、応募フォーム、求人本文の「募集中」表記まで含めて、同じ募集状態になっているかを確認します。

STEP6｜応募URL・directApply・実際の応募導線を監査する

JobPosting監査では、構造化データ上の項目だけでなく、求職者がその求人へ実際に応募できるかを確認します。

Googleの求人情報ポリシーでは、応募方法が示されていない求人は認められていません。監査では求人詳細ページから応募完了までを実際にたどり、次を確認します。

  • 応募ボタンが表示され、現在の募集職種に紐づいているか
  • 応募先URLが404やエラーになっていないか
  • 別職種・別勤務地の応募フォームへ飛ばないか
  • 求人内容を読む前にログインが必須になっていないか
  • 募集終了求人から応募を送信できてしまわないか
  • ATS変更後も旧フォームURLが残っていないか

directApplyを設定している場合は、値がtrueであることだけではなく、Googleが示す「直接応募」の状態になっているかを確認します。不要な中間ページや何度ものログイン・再入力が必要なら、directApply: trueと実際の体験が一致していません。

また、構造化データに応募先URLの専用必須プロパティがあると誤解しないことも重要です。監査の中心は、JobPostingが載る求人ページから、応募方法または応募先がユーザーに明確に確認できることです。

求人終了・再募集時のJobPosting更新ルール

JobPostingは、公開時よりも終了時と再募集時に不整合が起きやすい構造化データです。募集状態が変わったら、本文・JobPosting・応募導線・URLの扱いを同時に更新します。

状況 求人本文・応募導線 JobPosting URLの扱い
応募期限に到達 募集終了を明示し、応募を停止 validThroughの期限経過を確認。必要に応じてJobPostingを削除 ページを残すか、不要なら404/410
期限前に採用充足 その時点で応募を停止 将来日の期限を待たず、JobPosting削除またはページ終了 ページを残すなら「募集中」に見せない
求人ページを削除 応募不可 JobPostingも消える 404または410を返す
職種紹介としてページを残す 募集終了を明示し、応募導線を外す JobPostingを削除 既存URLを情報ページとして残せる
同じ募集案件を一時停止後に再開 最新条件と応募導線へ戻す validThrough等を現在の募集状態へ更新 同一募集案件なら既存URLを再利用する運用も可能
同職種を新しい募集案件として再募集 新しい募集期間・条件・応募先を明示 新しい求人識別子、datePosted、期限等で別募集として管理 新URLを作り、旧URLは終了状態を維持する運用が明確

Googleが明示しているのは、「実際に募集中の職種だけを再開すること」と、datePostedは雇用主が求人を最初に投稿した日付であることです。Google公式ドキュメントは「同職種なら必ず新URL」「必ず旧URLを再利用」とまでは定めていません。

そのため新旧URLは、同じ募集案件の再開なのか、新しい募集案件なのかで社内ルールを決めます。新しい採用枠として求人ID・募集期間・条件が切り替わるなら、新URLと新しい求人識別子で分けた方が、旧求人の期限・応募先・datePostedを誤って引き継ぎにくくなります。これはGoogleの必須ルールではなく、監査しやすくするための運用設計です。

終了・再募集のどちらでも、変更後はIndexing APIなどでGoogleへ更新を通知し、古い募集状態が残っていないか確認します。

補助確認｜現在の求人状態をGoogleが取得できるか

JobPosting固有フィールドと募集ライフサイクルの照合が終わった後に、Googleが現在の求人ページを取得できるかだけを補助確認します。

  • 募集中の求人がGoogleから取得できるか
  • 終了して削除した求人が404／410になっているか
  • レンダリング後にも最新のJobPostingが出ているか
  • リッチリザルトテストでJobPostingが検出されるか
  • Search Consoleに期限切れ求人や応募不能などの問題が出ていないか

サイト全体のnoindex、robots.txt、canonical、インデックス未登録理由の分類や、構造化データ全般のツール検証は本記事の主題ではありません。構造化データ全般は「構造化データのSEO監査方法｜実装後のエラー・内容不一致・重複を検証する手順」へ分け、ここでは今の求人状態がGoogleにも同じように見えているかだけを確認します。

JobPosting監査の優先順位は「応募できない・誤情報」から決める

すべてのエラーを同じ優先度で扱う必要はありません。

実務では、応募者への影響が大きいものから修正します。

優先度 状態 例
A：即修正 応募者を誤認させる 募集終了、給与違い、勤務地違い、応募不能
B：早期修正 Googleへの情報が不完全 雇用形態違い、リモート指定違い、必須項目不足
C：改善 情報量を高められる 推奨項目不足、説明不足

JobPosting監査で発見した問題を応募者への影響に応じてA即修正、B早期修正、C改善に分類した優先順位図

修正順位はエラーの数ではなく、応募者への影響で決めます。給与・勤務地の誤りや応募不能など、誤認につながる問題を最優先にします。

たとえば、baseSalaryが未設定である求人より、本文30万円・構造化データ40万円という求人の方が先に修正すべきです。

監査の目的は、項目数を増やすことではありません。

応募者と検索エンジンへ、同じ最新情報を伝える状態を維持することです。

定期監査では「公開求人件数」と「有効なJobPosting件数」を照合する

JobPostingは一度実装して終わりではありません。

採用担当者による条件変更、給与改定、勤務地変更、ATS移行、募集終了などによって、本文と構造化データはずれていきます。

月次や求人更新時に、少なくとも次を確認すると管理しやすくなります。

  • 現在募集中の求人件数
  • JobPostingを持つ求人件数
  • Search Console上の有効項目数
  • 構造化データエラー件数
  • 期限切れ求人件数
  • 本文と給与が一致しない求人件数
  • 本文と勤務地が一致しない求人件数
  • 応募できない求人件数

特に複数職種・複数勤務地を運用する採用サイトでは、求人単位の監査表を持つことで、採用担当・Web担当・開発担当の責任範囲を明確にできます。

まとめ

JobPosting構造化データの監査では、構造化データ全般のエラー確認を繰り返すのではなく、求人本文とJobPosting固有フィールド、募集ライフサイクルを求人単位で一致させることが重要です。

優先して確認するのは、次の6点です。

  1. baseSalaryの金額・通貨・支給単位
  2. jobLocation、jobLocationType、リモート可否
  3. employmentType
  4. validThroughと実際の募集期限
  5. directApplyと応募導線
  6. 募集終了・再募集時の本文、JobPosting、旧URL／新URLの状態

特に、期限切れ求人が応募できるまま残る、本文と給与・勤務地が違う、旧募集の応募先や期限を新しい募集へ引き継ぐ、といった状態は優先して修正します。

一般的なschema棚卸し、重複JSON-LD、noindex・robots.txt、Search Consoleの横断監査は、構造化データのSEO監査方法側で扱います。本記事では、採用担当・Web担当・開発担当が同じ求人IDを見ながら、現在その求人が本当に募集中か、求職者に見える条件とGoogleへ伝える条件が一致しているかを確認してください。

参考文献・データ元

  • 「求人情報（JobPosting）の構造化データ」／Google Search Central
    参照日：2026年8月30日
    対象：JobPostingの必須・推奨プロパティ、勤務地、給与、validThrough、directApply、期限切れ求人、募集の再開、datePosted、技術ガイドライン
    URL: https://developers.google.com/search/docs/appearance/structured-data/job-posting?hl=ja

  • 「General Structured Data Guidelines」／Google Search Central
    参照日：2026年8月30日
    対象：ページ本文と構造化データの一致、アクセス可能性、リッチリザルト表示の考え方
    URL: https://developers.google.com/search/docs/appearance/structured-data/sd-policies

  • 「Indexing API クイックスタート」／Google Search Central
    参照日：2026年8月30日
    対象：JobPostingページの追加・更新・削除通知
    URL: https://developers.google.com/search/apis/indexing-api/v3/quickstart?hl=ja

  • 「Block Search indexing with noindex」／Google Search Central
    最終更新：2025年12月10日 UTC
    対象：求人ページのインデックス可否確認
    URL: https://developers.google.com/search/docs/crawling-indexing/block-indexing

  • 「Rich Results Test」／Google Search Console
    参照日：2026年8月30日
    対象：JobPosting構造化データの技術検証
    URL: https://search.google.com/test/rich-results

無料相談はこちら