WordPressでGoogleしごと検索に対応する方法

WordPressの求人詳細にJSON-LDを置くだけでは、Googleしごと検索への対応は終わりません。求人一覧へJobPostingをまとめて出すと、求人の単位を誤ります。画面にない給与や勤務地を構造化データだけへ足せば、求人の実体とも食い違います。

必要なのは、対象にできる求人を選び、1求人1URLで公開することです。求職者が読む内容とJobPostingは同じ情報から作ります。最後に、公開前のコードと公開後のURLを分けて確認します。公式要件を満たしても、Googleしごと検索への掲載、表示時期、順位は保証されません。

最初に、JobPostingを出してよい求人か確かめる

JobPostingを用意する前に、そのページが現在受け付けている実在の求人かを確認します。イベント告知、採用情報のまとめ、社員紹介、募集を終えた求人へ、型だけを付けるものではありません。

公開候補は、少なくとも次の条件を満たす必要があります。

• 1件の募集中の職種を説明している
• 職務、条件、勤務地など、応募判断に必要な説明がある
• ログインせず求人詳細を読める
• 応募を始める方法が分かる
• 表示内容と構造化データに同じ正式情報を使える
• 期限切れや受付停止ではない

応募受付先が未決定なら、構造化データから先に作りません。WordPress採用サイトの応募先はどこに置くかで、正式な受付先と障害時の担当を決めてから戻ります。

Googleは、求人情報の構造化データを追加すると専用表示の対象になり得ると案内しています。一方、構造化データを使ったコンテンツが検索結果に必ず表示されるわけではありません。対象条件と掲載結果を分けて扱ってください。

Google検索セントラルの求人情報ガイドラインを確認する

求人一覧ではなく、1求人1URLの詳細へ出力する

複数の求人カードが並ぶ一覧ページは、求人を探す入口です。JobPostingを出す場所は、1件の求人を詳しく説明する専用ページです。一覧へ全求人分のJSON-LDをまとめず、各詳細URLで該当する1件だけを出します。

WordPressでは、求人を独立した投稿として管理できます。詳細URL、公開状態、募集状態、更新履歴を求人ごとに分けられます。ただし、カスタム投稿タイプにすれば自動的に正しくなるわけではありません。保存先と項目の分け方は、WordPress採用サイトのデータ設計で先に決めます。

URLを決めたら、同じ求人の重複ページ、正規URL、一覧から詳細へのリンクも確認します。1求人1URLは順位を上げる保証ではありません。求人の表示、更新、終了を一つの対象として検証するための単位です。

可視本文とJobPostingを一つの対応表でつなぐ

構造化データ専用の入力欄を増やす前に、求職者が読む表示項目とJobPostingのプロパティを対応付けます。情報の正本と確認方法も同じ表で決めます。次の表を案件用に複製し、値ではなく担当と確認結果を埋めます。

求職者に見せる項目	JobPosting	区分	情報の正本	公開前の確認
職種名	title	必須	承認済み求人名	会社名、勤務地、給与等を混ぜず、画面と一致
仕事内容、資格、勤務条件	description	必須	求人本文・条件	詳細な説明が画面で読め、titleの複製ではない
募集企業名	hiringOrganization.name	必須	企業の正式情報	支店所在地を会社名へ混ぜない
就業場所	jobLocation	必須または条件分岐	承認済み勤務地	実際の就業場所と国コードを表示・構造化データで一致
初回掲載日	datePosted	必須	初回公開記録	更新日で無条件に上書きしない
雇用形態	employmentType	推奨	雇用条件	Googleが案内する値へ、推測せず対応付ける
基本賃金	baseSalary	推奨	募集企業が提示した賃金	画面にも同額と単位を表示し、推定額を使わない
応募期限	validThrough	期限がある場合は必須	承認済み終了日時	日時、タイムゾーン、画面の締切を一致
完全リモートと応募可能地域	jobLocationType、applicantLocationRequirements	条件付き	勤務形態・地域	完全リモートだけTELECOMMUTE。地域も画面に表示
直接応募	directApply	推奨	実際の応募手順	短い手順で応募開始できると確認した場合だけtrue
求人識別子	identifier	推奨	採用側の求人ID	再利用しない安定した値か確認

JobPostingはSchema.orgの型です。Googleが検索機能で必須・推奨とするプロパティは別に確認します。Schema.orgにある語をすべて出す必要はありません。未確認の値を補わず、正式情報がないプロパティは担当へ戻します。

WordPressでは、対象判定とJSON出力を分ける

実装は、求人データを読む処理と、募集中かを判定する処理に分けます。JobPosting配列の組み立てと、単一詳細への出力も分離します。次は責任の分け方を示す骨格で、そのまま貼って動く完成コードではありません。project_get_approved_job()は説明用の仮名で、案件固有の承認済み求人データ取得関数へ置き換えます。

add_action(
	'wp_head',
	static function (): void {
		if ( is_admin() || is_preview() || is_feed() || is_trackback() || ! is_singular( 'job' ) ) {
			return;
		}

		$post_id = get_queried_object_id();
		if ( $post_id <= 0 || (int) get_the_ID() !== $post_id ) {
			return;
		}

		$job = project_get_approved_job( $post_id );
		if ( ! $job || ! $job['is_open'] || ! $job['can_apply'] ) {
			return;
		}

		$data = array(
			'@context'           => 'https://schema.org',
			'@type'              => 'JobPosting',
			'title'              => $job['title'],
			'description'        => $job['description_html'],
			'datePosted'         => $job['date_posted'],
			'hiringOrganization' => $job['hiring_organization'],
			'jobLocation'        => $job['job_location'],
			'url'                => get_permalink(),
		);

		$json = wp_json_encode(
			$data,
			JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES
			| JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT
		);
		if ( false !== $json ) {
			echo '<script type="application/ld+json">' . $json . '</script>';
		}
	},
	30
);

単一投稿を判定するWordPress関数で出力先を絞っても、求人の中身や受付状態までは確認できません。JSONを生成する関数を使っても、値の承認、必須プロパティ、表示との一致は別の責任です。値が不足する場合に空のJobPostingを出さず、公開前の確認へ戻せる設計にします。

WordPressの単一投稿を判定する関数とJSONを生成する関数の仕様も、対象版で確認してください。

公開前は、コードだけでなく応募まで確認する

リッチリザルト テストへ貼り付けてエラーがないことは、公開前確認の一部です。次の順で、表示と構造化データを同じ求人について確認します。

1. 求人詳細の職種名、説明、企業、勤務地、給与、期限、応募方法を正式情報と照合する
2. HTMLソースのJobPostingが1件で、一覧や別の投稿には出ていないことを確認する
3. 対応表の必須・条件付きプロパティとJSONの値を照合する
4. JSON-LDにある値が、同じページで求職者にも見えることを確認する
5. 応募ボタンから意図した応募開始地点へ進めることを確認する
6. リッチリザルト テストでコードを検証し、指摘を必須、推奨、内容不一致に分ける
7. 募集終了、応募不能、必須情報不足のテスト用データではJobPostingが出ないことを確認する

複数勤務地、完全リモート、給与範囲は構造が変わります。通常の出社求人1件だけで済ませず、採用する条件ごとの代表データを用意します。

公開後は、匿名URLをもう一度見る

公開後は、管理者のプレビューではなくログアウトした環境で対象URLを開きます。まず、HTTP 200、ログイン不要、robots.txtやnoindexによる意図しない遮断がないことを確かめます。自己参照の正規URL、可視本文、応募先、JobPosting 1件も確認します。そのURLをリッチリザルト テストへ入力し、取得内容が公開画面と同じかを見ます。

求人媒体、採用サイト、ATSを併用する場合は、更新担当へ結果を返します。担当は求人媒体・採用サイト・ATSの役割分担で決めます。WordPressだけ直して、別の情報正本や応募先に古い条件を残さないためです。

Search Consoleは、公開後の認識や構造化データの問題を確認する手段です。登録要求の受理、リッチリザルト テストの合格、エラー0のいずれも、掲載、順位、再クロール時刻を保証しません。

募集終了を初期実装の続きとして残す

正常公開を確認した時点で、終了日時、手動終了、応募先障害の担当を引き渡します。公開できたJobPostingを、求人が終わった後も残し続けてはいけません。

期限切れ、募集終了、再募集では、求人詳細、一覧、応募、構造化データ、検索通知を同期します。具体的な手順はJobPostingの募集終了・期限切れ・再募集で確認してください。ここでは終了方法を重ねず、公開前後の記録へ終了担当と確認時期を追加して完了します。

2GUでは、適格な単一募集だけへ出力する

2GU 1.0.3は、可視募集詳細とJobPostingを同じ保存情報から生成します。公開中で応募可能な単一募集詳細に限り、必要な情報がそろった場合だけ1件を出力します。募集終了、期限切れ、応募不能、必須情報不足では、不完全なJobPostingを出しません。

完全リモート、複数勤務地、給与範囲、終了日時、直接応募も、確認済みの入力に応じて出力します。2GUを使っても、Googleしごと検索への掲載、順位、クロール時期、応募増加は保証されません。導入条件は2GUの対応環境で確認してください。

自作実装、既存のプラグインやテーマ、制作キットを比べる場合は、先に一般要件を対応表へ記入します。その結果を持って、2GUの商品範囲と対象外を確認する。