制作・引き渡し
JobPostingの募集終了・期限切れ・再募集|求人ページの扱い方
募集終了、期限切れ、再募集で、求人詳細、一覧、応募導線、JobPosting、sitemap、検索通知をどう同期するか。6状態の運用表と、200・404・410・redirect・noindex、同一URL再開の判断を整理します。

求人募集が終わったとき、応募formだけを閉じても運用は完了しません。求人詳細に「募集中」が残り、募集一覧から入れて、JobPostingも出力されたままなら、訪問者と検索エンジンには募集継続中に見えます。
反対に、終了した求人をすべて即座に404へ変えるのも正解ではありません。選考中の応募者が条件を見返す場合や、再募集時に過去の募集を参照したい場合があるためです。先に決めるべきなのはURLではなく、業務上の募集状態と有効時刻です。
この記事では、募集終了、期限切れ、再募集で更新する公開面を一つの状態表にまとめます。そのうえで、validThrough、200・404・410・redirect・noindex、sitemap、Indexing API、同一URLでの再開をどう判断するかを整理します。
結論:募集状態を決めてから、公開面を同時に更新する
募集終了の運用は、次の順序で進めます。
- 採用側の情報責任者が、募集状態、終了理由、有効時刻、再募集予定を確定する
- 運用担当者が、求人詳細、募集一覧、応募導線、
JobPostingを同じ状態へ更新する - 実際の公開状態を確認した後で、sitemapと検索エンジンへの更新通知を行う
- 表示、HTTP status、応募不可、構造化data、通知結果を証拠として残す
厚生労働省も、募集を終了・変更した場合は求人情報の掲載を速やかに終了・訂正し、情報の時点を明らかにするよう案内しています。これは個別の法務判断ではなく、求人情報を正確かつ最新に保つための運用基準として参照できます。募集情報等提供事業者・求人企業向けリーフレット
求人媒体、採用サイト、ATSのどれを正本にするかが曖昧な場合は、終了操作の前に求人媒体・採用サイト・ATSの役割分担を決めてください。
募集中・受付停止・募集終了・期限切れ・再募集を一つの状態表で管理する
状態名だけでなく、公開面ごとの期待結果と完了証拠まで決めます。次の表は一般的な運用基準です。自社の正本、承認経路、URL方針に合わせて具体化してください。
| 業務状態 | 求人詳細 | 募集一覧 | 応募導線 | JobPosting | sitemap・検索通知 | 完了証拠 |
|---|---|---|---|---|---|---|
| 募集中 | 200で最新条件と受付中を表示 | 掲載 | 実送信まで利用可能 | 現在の事実から出力 | 公開後にsitemap更新。必要時は更新通知 | 表示、応募test、JSON-LD、最終更新時刻 |
| 受付停止 | 200で「受付方法を確認中」などを表示 | 状況に応じて残す | 停止 | 有効な応募先がなければ出力しない | 実体更新後に更新通知 | 障害時刻、表示、応募不可、JSON-LD不在 |
| 募集終了 | URL方針に従い200、404、410、または同等求人へredirect | 通常一覧から外すか終了枠へ移す | 停止 | 200で残すなら削除。終了時刻を表す正確なvalidThroughがある場合も表示と応募は終了 | 200更新なら更新通知、削除なら削除通知。sitemapも実体へ合わせる | 終了承認、status、表示、応募不可、JSON-LD |
| 期限切れ | 終了状態を表示するか、削除方針を適用 | 通常一覧から外す | 停止 | 期限後も放置せず、終了状態との整合を確認 | 実体更新後に通知 | validThrough、site時刻、status、JSON-LD |
| 再募集準備 | 旧募集は終了表示。新しい内容は非公開で準備 | 掲載しない | 公開応募は停止 | 出力しない | 公開前は通知しない | 新旧差分、承認、preview、応募test |
| 再開 | 200で現在の条件と受付中を表示 | 掲載 | 実送信まで利用可能 | 現在の事実から再生成 | 公開確認後に更新通知 | 再開承認、表示、応募test、JSON-LD |
受付停止は募集終了ではありません。たとえば応募先の障害で受付できないときは、採用側が募集継続を望んでいても、機能として応募できません。障害を隠して応募可能に見せず、復旧後に同じ募集へ戻すか、採用側が終了へ切り替えるかを分けます。
また、期限切れは予定時刻が到来した状態、募集終了は採用充足や方針変更などで受付を終えた状態です。入口は異なっても、終了後に応募を受けず、募集継続中のJobPostingを残さない点は共通します。
募集終了時に応募とJobPostingを止める
Googleの求人情報ガイドラインは、期限切れの求人について、validThroughを過去にする、ページを404または410にする、あるいはページからJobPostingを削除する方法を案内しています。Google検索セントラル「求人情報の構造化データ」
ただし、構造化dataだけを止めても応募formが送信できれば、業務上は受付中です。逆に、formだけを閉じてJobPostingを残せば、検索面と実画面が食い違います。最低でも次を同じ変更単位で確認します。
- 求人詳細の受付状態と終了時刻
- 募集一覧からの見え方
- 応募button、form、ATSへの遷移、電話やmailの代替導線
- HTML内の
JobPosting有無と内容 - cacheや生成済みHTMLを含む匿名表示
応募先の障害を募集終了として扱わないための分岐は、応募フォーム・ATS・外部URLの決め方で詳しく整理しています。
validThroughを設定した募集の期限切れを確認する
validThroughは、求人が有効でなくなる日時です。schema.orgでは「その求人が有効でなくなる日付」と定義されています。schema.org JobPosting.validThrough
締切が存在する求人では、正確な日時とtimezoneを含む値を使います。締切が存在しない、または事実として確定していない場合に、検索表示のためだけの仮の日付を作るべきではありません。
期限が到来したら、次の定期処理または公開要求を待つだけにせず、表の期限切れへ遷移したことを確認します。siteの表示時刻、WordPressのtimezone、JSON-LDのtimezoneがずれると、ページは受付中なのに構造化dataだけ期限切れ、またはその逆になります。
予定より早く採用が充足した場合は、将来のvalidThroughを待ちません。採用側が終了を確定した有効時刻で応募を止め、ページ表示とJobPostingを更新します。
終了した求人詳細を200で残すか、404・410にするか
HTTP statusは募集状態そのものではなく、終了後もそのURLを人に見せる価値があるかで選びます。
| 選択 | 適する場合 | 必須の扱い | 避ける使い方 |
|---|---|---|---|
| 200で終了表示 | 選考中の応募者や再訪者に、当時の条件や終了事実を示す価値がある | 応募停止、終了表示、募集継続中のJobPosting削除、一覧方針の反映 | 受付中に見えるtitleやbuttonを残す |
| 404 | 残す価値がなく、代替となる同等求人もない | 内部link、一覧、sitemap、JobPosting、応募導線を外す | 何でも採用一覧へredirectする |
| 410 | 意図的な恒久削除をstatusで明示し、その運用を維持できる | 404と同じ周辺面の整理 | 「404より必ず早く消える」と期待して使う |
| 同等求人へredirect | 後継URLが利用者の期待を実質的に引き継ぐ | redirect先も現在の募集事実と一致させる | 職種・勤務地・条件の違う求人やhomeへ機械的に送る |
noindex付き200 | 人には履歴を残すが、検索結果には残したくない | 応募停止とJobPosting削除を別途行う | noindexだけで募集終了処理を済ませる |
選考中の応募者が求人条件を参照する運用なら、200で明確な終了表示を残す方法が扱いやすい場合があります。個人情報や機密情報を残す理由にはならず、保持期間と掲載内容は社内方針で別に決めます。
404と410は、どちらも「応募を止めた」ことを代替しません。変更前に応募を受け付けていた外部formやATSが別URLなら、その停止を別に確認します。
sitemapとIndexing APIへ実体の更新を渡す
検索エンジンへの通知は、公開状態の変更より後です。先に通知してからページを直すと、再取得の時点で古い状態が返る可能性があります。
| 実際の変更 | sitemap | Indexing APIを使う場合 |
|---|---|---|
200のまま終了表示へ更新し、JobPostingを削除 | URLを残し、意味のある更新時刻をlastmodへ反映 | 公開確認後にURL_UPDATED |
| URLを404または410へ変更 | URLをsitemapから外す | statusと周辺面の確認後にURL_DELETED |
| 同じURLで再開 | URLを掲載し、実際の更新時刻を反映 | 表示・応募・JSON-LD確認後にURL_UPDATED |
| 新しいURLで新規募集 | 新URLだけを正規URLとして掲載 | 新URLの公開確認後にURL_UPDATED |
GoogleのIndexing APIは、求人情報ページの追加・更新・削除を知らせる用途に限定されています。HTTP 200の応答は要求が受理されたことを示すもので、index状態や反映時刻の保証ではありません。sitemapも併用し、公開URL全体の把握に使います。Google Indexing APIの利用方法
完了条件は「通知を送った」ではなく、対象URLごとのstatus、終了表示、応募不可、JobPostingの有無、sitemap収録、送信応答を並べて確認できることです。
同じ求人を再募集するときに確認する
再募集では、古いページの受付を再び有効にすればよいとは限りません。GoogleのdatePostedは、雇用主が求人を最初に掲載した日です。検索上の鮮度を上げる目的だけで日付を更新せず、同じ募集の再開か、事実として新しい募集かを先に判断します。
| 判断 | 同じURLで再開する候補 | 新しい求人として作る候補 |
|---|---|---|
| 募集の同一性 | 短い計画停止で、職種、勤務地、雇用形態、条件、雇用主が同じ | 募集枠や採用計画が新しく、主要条件も変わる |
| 応募経路 | 同じ応募先を復旧し、送信test済み | 新しいform、ATS求人ID、選考経路を使う |
| 日時 | 旧募集の履歴と再開時刻を説明できる | 新しい募集の実際の初回掲載日と締切を持つ |
| URL | 履歴を維持しても訪問者を誤認させない | 新旧を分けた方が条件と証拠を明確に保てる |
どちらを選んでも、古い条件のcache、募集一覧、応募先、JSON-LDを個別に継ぎ足さず、一つの承認済み入力から再生成します。再開前のpreviewだけで終えず、匿名表示と実送信を確認してから検索エンジンへ更新を渡します。
情報の正本・更新担当・障害連絡を決める
状態同期は、担当名よりも責任の種類を分けると引き継ぎやすくなります。
| 役割 | 決めること | 完了証拠 |
|---|---|---|
| 情報責任者 | 募集状態、条件、終了理由、有効時刻、再募集の同一性 | 承認記録と差分 |
| 更新担当者 | 詳細、一覧、応募、JobPosting、cache、sitemapを更新する順序 | 対象別の実行記録 |
| 確認担当者 | 匿名表示、HTTP status、応募、JSON-LD、通知結果 | URL別check結果 |
| 障害連絡先 | 応募先障害を誰が検知し、受付停止・復旧・終了を誰へ上げるか | 障害時刻、連絡、復旧または終了判断 |
一人で運用する場合も、同じ人が四つの欄を順に埋めます。終了判断をしただけ、更新しただけ、通知しただけを完了にせず、対象ごとの証拠がそろった時点を完了とします。
一般回答はここで完了です。以下は、2GUでこの考え方を実装するときの現在の例です。
2GUでの募集終了・期限切れ・再募集
2GU 1.0.3の求人状態は、公開面では募集中と募集終了を基本にし、任意の終了日時をsiteのtimezoneで判定します。終了日時に達すると、求人詳細は終了表示のまま残り、通常の募集一覧、応募導線、JobPostingを止める設計です。公開表示を外部ライセンスAPIの応答には依存させません。
応募先の不備や障害は募集終了とは分けます。求人詳細と一覧を残し、応募導線とJobPostingを止めて「応募受付方法を確認しています」と表示するため、採用側の事実を勝手に終了へ変えません。
同じ求人の再開は、短い計画停止で内容と応募先が同じ場合に限定して検討します。条件、応募期間、応募先が変わる再募集は、旧募集を終了状態で保持し、新しい求人を複製して全項目を再確認する手順を基本とします。操作順は求人情報を公開する手順にまとめています。
WordPressで状態判定を一か所へ集約する技術例が必要な場合は、2GU製品codeとは独立したWordPress採用サイトで募集終了とJobPostingを同時に止める設計チェックも参照できます。
よくある質問
募集終了した求人ページは必ず削除しますか
必ず削除するわけではありません。選考中の応募者が条件を見返す必要があるなら、200で終了表示を残す選択があります。残す場合も応募を止め、募集継続中のJobPostingは削除します。
404と410はどちらが正解ですか
一律の正解はありません。残す価値がないURLには404、恒久削除を明示して運用できる場合は410を選べます。どちらでも内部link、一覧、sitemap、応募導線、構造化dataの整理が必要です。
noindexを付ければJobPostingを残せますか
残す理由にはなりません。noindexは検索結果への掲載方針、JobPostingは求人の事実を伝えるdataです。募集終了後に200で残す場合は、終了表示と応募停止に加えて、募集継続中のJobPostingを削除します。
validThroughを過ぎれば何もしなくてよいですか
いいえ。期限後に表示、一覧、応募、JSON-LDが期待状態へ変わったか確認します。自動判定があっても、timezone、cache、生成済みHTML、外部応募先のずれは別に検証します。
採用が早く決まったらvalidThroughまで待ちますか
待ちません。採用側が終了を確定した有効時刻で応募を止め、ページ表示とJobPostingを更新します。
募集終了をIndexing APIで通知すればすぐ検索結果から消えますか
保証されません。通知は再取得を依頼する手段であり、実際のindex状態や反映時刻を確定するものではありません。ページの実体、sitemap、送信応答を別々に確認します。
同じURLで再募集できますか
短い計画停止で内容と応募先が同じなら候補になります。新しい採用計画、主要条件、応募先、期間へ変わるなら、新しい求人として分けた方が事実と証拠を保ちやすくなります。
datePostedを再募集日に更新してよいですか
新しい求人として実際に初めて掲載する日なら、その事実を使います。同じ募集を検索上新しく見せるためだけに更新しません。まず同じ募集の再開か、新しい募集かを採用側が判断します。