求人ページの構造化データを確認｜給与・勤務地・期限の不一致

監修: 菊地 将（リブランディング株式会社）

採用サイトにJobPosting構造化データを実装していても、求人本文の給与・勤務地・雇用形態・掲載期限・応募導線とずれていれば、正しく運用できているとはいえません。コードが入っていることと、中身が今の求人と合っていることは別の問題だからです。JobPostingは、求人情報をGoogleへ伝えるための構造化データで、この記事ではJSON-LD形式のコードを想定します。

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

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

答えを先に示すと、監査とは、求人本文とJobPostingが同じ内容かを、求人1件ずつ照合する作業です。この記事では、その照合を項目別に進める手順と、期限到達・早期終了・非公開・同職種の再募集のときにどの情報をいつ更新するかを整理します。あわせて、修正の優先順位と、定期的に点検する項目も取り上げます。

JobPostingの監査では「存在」より「本文との一致」を確認する

先に全体を把握したい場合は、テクニカルSEOの全体像を参照してください。

JobPostingの監査で最初に確認すべきなのは、コードが入っているかどうかではありません。求人ページに表示されている情報と、JobPostingでGoogleへ伝えている情報が一致しているかを確認します。

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

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

そのため監査では、次の3つを同時に見ます。左の列が見る対象、右の列がその対象で確認することです。

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

求人本文だけ、構造化データだけを見ていても、ずれには気づけません。JobPosting監査では、募集・応募・インデックスを含むページ状態まで照合します。

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

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

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

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

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

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

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

STEP2｜給与のbaseSalaryは金額・通貨・単位を本文と照合する

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

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

たとえば求人本文が「月給30万円〜45万円」となっている場合、構造化データ側も月給30万円〜45万円として対応しているか確認します。確認する点は次の6つです。

• 本文の給与と数値が一致しているか
• 月給と年収を取り違えていないか
• 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を削除するなどの終了処理を求めています。

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

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

構造化データ上の項目にとどまらず、求職者がその求人へ実際に応募できるかも確認します。Googleの求人情報ポリシーでは、応募方法が示されていない求人は認められていません。そのため、求人詳細ページから応募完了までを実際にたどり、次を確認します。

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

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

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

求人の終了・再募集では、何をいつ更新するか

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

次の表は、状況ごとの更新内容をまとめたものです。左端で自分の状況を探し、同じ行の3列を同時に更新します。

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

再募集で迷いやすいのは、旧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、Cの順に優先度が下がります。「状態」の列が、その優先度にする理由です。

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

給与・勤務地の誤りや応募不能など、誤認につながる問題を最優先にします。

たとえば、baseSalaryが未設定である求人より、本文30万円・構造化データ40万円という求人の方が先に修正すべきです。監査の目的は項目数を増やすことではなく、応募者と検索エンジンへ同じ最新情報を伝える状態を維持することです。

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

この節では、一度の監査で終わらせないための点検項目を決めます。JobPostingは一度実装して終わりではありません。採用担当者による条件変更、給与改定、勤務地変更、ATS移行、募集終了などによって、本文と構造化データはずれていきます。

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

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

まず、現在募集中の求人件数と、JobPostingを持つ求人件数を並べて見ます。差があれば、ずれている求人を特定して、先ほどのSTEPに沿って確認します。

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

まとめ｜確認する6点と、最初にやること

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監査方法側で扱います。

最初にやることは、現在募集中の求人を1件選び、その求人IDで本文・JobPosting・応募導線を並べて見比べることです。採用担当・Web担当・開発担当が同じ求人IDを見ながら、現在その求人が本当に募集中か、求職者に見える条件とGoogleへ伝える条件が一致しているかを確認してください。

参考文献・データ元

‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト

関連記事

• › INDEX削除（インデックス削除）とは？検索結果から消える仕組みと対処法
• › Core Web Vitals改善ガイド｜LCP・INP・CLSの原因特定と優先順位付け
• › SEO内部リンクの確認方法｜孤立ページ・深度・アンカー偏りを改善
• › ページがインデックスされない原因は？Search Consoleで未登録・除外・重複URLを確認
• › JavaScript SEOの確認方法｜表示・内部リンク・登録状況
• › クロールバジェットの確認方法｜無駄なクロールと改善優先度
• › 構造化データの確認方法｜エラー・本文との不一致・重複を検証
• › 多言語ページの言語・地域指定を確認｜相互参照・正規URLをチェック
• › 絞り込み検索のSEO確認方法｜URL増加・クロール・重複を防ぐ
• › SEOリダイレクトの確認方法｜多段転送・ループ・誤転送を検出
• › robots設定のSEO確認方法｜クロール許可と登録制御の矛盾を確認
• › ページネーションのSEO確認方法｜正規URL・内部リンク・クロール
• › サイト移行後のSEO確認方法｜転送・正規URL・順位変動を確認
• › 404・soft 404のSEO確認｜リンク切れ・消失URLを修正
• › SEOリリース前チェックの作り方｜noindex・canonical・robots・リダイレクトの事故を防ぐ
• › 画像SEOの確認方法｜alt・画像URL・遅延読み込みを確認
• › サイト内検索ページのSEO確認｜noindex・クロール・重複URL
• › サイトリニューアルでSEO評価を落とさない移行方法｜URL・301・計測・公開手順
• › サービス終了ページは削除すべき？301・404/410・残す場合のSEO判断基準
• › SEOに強いURL・ディレクトリ設計｜階層・命名・変更時の注意点
• › サブディレクトリとサブドメインの違い｜SEO・運用の判断基準
• › リッチリザルトとは？種類・構造化データ・表示確認方法を解説
• › Google Search Consoleとは？登録方法と最初に見る4つの指標

関連テーマ

AIO MEO 口コミ・風評対策 採用改善 オウンドメディア集客