Googleしごと検索に求人を出すには？人材会社が確認するべき設定

by

この記事の使い方

「うちの求人をGoogleしごと検索に出したいのですが、何をすればいいですか」というご相談に対して、担当者の方が社内や制作会社と話を進めるためのチェックリストとしてまとめました。

しくみの詳しい解説は別記事で扱っています。ここでは確認すべき項目に絞ります。

前提：2つの誤解を先に外しておく

作業に入る前に、ここだけは共有しておきたい点が2つあります。

① 条件を満たせば必ず掲載される、というものではない

必要な設定を行うことは、掲載の可能性を作るための条件です。掲載そのものが保証されるわけではありません。Google側の判断や仕様変更によって、表示されないこともあります。社内で「設定すれば載る」という前提で説明すると、あとで齟齬が生じます。

② 構造化データを入れれば検索順位が上がるわけではない

JobPostingは「このページは求人情報である」とGoogleに伝えるためのものです。通常の検索結果での順位を上げるためのタグではありません。この2つは別の話として扱ってください。

チェックリスト1：ページ側の前提条件

構造化データを入れる前に、ページそのものが条件を満たしているかを確認します。ここが崩れていると、マークアップを入れても機能しません。

  • 求人1件につき、1つのURLがある
    一覧ページの中に複数の求人が並んでいるだけの状態では対象になりません。求人ごとの詳細ページが必要です。
  • そのページがログインなしで見られる
    会員登録や応募者ログインが必要なページは、クロールできないため対象になりません。
  • 検索エンジンがクロールできる
    robots.txtでブロックされていないか、noindexが入っていないかを確認します。
  • JavaScriptで生成される情報が読み取れる状態か
    求人情報が動的に描画されている場合、レンダリング後の内容を確認する必要があります。
  • サイトマップを使って求人URLの公開・更新を知らせる運用になっているか
    サイトマップの送信は掲載の必須条件ではありませんが、求人URLの公開・更新をGoogleに知らせる手段として使う場合は、求人詳細URLを適切に含め、lastmod を実際の更新日時に合わせます。実際の更新と無関係な日時が入っていると、手がかりとして機能しません。
  • 求人ページの更新頻度が高いことを前提にした運用になっているか
    求人は入れ替わりが早いため、公開・終了のタイミングでマークアップやサイトマップが追随する仕組みが必要です。

チェックリスト2：JobPosting構造化データの項目

求人詳細ページに、JobPostingの構造化データを実装します。主な項目は次の通りです。

必須に近い項目

  • title：職種名。「急募！」「未経験歓迎」などの装飾語ではなく、職種そのものを入れる
  • description：仕事内容の説明。HTMLで書式を保持できる
  • datePosted：掲載開始日
  • hiringOrganization：その求人ポジションを提供する組織
  • jobLocation：物理的な勤務地がある求人では、住所の粒度を確認したうえで指定します。完全リモートなど物理的な勤務地を持たない求人では、jobLocationTypeやapplicantLocationRequirements等の要件を確認してください

条件によって入れる項目

  • validThrough：募集終了日・有効期限がある求人では指定します。逆に、期限を設けていない求人や、終了日が決まっていない求人に、埋め合わせの日付を入れる必要はありません。無理に入れると、まだ募集中の求人が期限切れとして扱われる原因になります
  • employmentType：雇用形態（FULL_TIME、PART_TIME、CONTRACTOR など、決められた値を使う）
  • baseSalary：自社が実際の雇用主として求人を掲載する場合は、実際に提示している基本給を指定します。金額・通貨・単位（時給／月給／年収）をセットで入れます
  • jobLocationType：完全リモート勤務の場合
  • applicantLocationRequirements：リモート勤務で対象地域が限られる場合
  • identifier：社内の求人管理番号など

人材会社で特に確認が必要な点

hiringOrganization の考え方

原則は、その求人ポジションを提供する組織を指定します。

そのうえで、第三者の求人サイトや人材会社が、雇用主名を明らかにしない匿名求人を掲載する場合には、confidential を使えるケースがあります。適用できる条件はGoogleのドキュメントに記載があるため、自社の掲載形態が該当するかを事前に確認してください。

いずれの場合も前提になるのは、ページ上の表示内容と構造化データが一致していることです。ページでは雇用主名を出していないのに構造化データには実名が入っている、あるいはその逆、という状態は避けます。

baseSalary の注意点

baseSalary は、その求人ページ上で実際に提示している求人条件と一致させる項目です。

  • 自社が実際の雇用主として求人を掲載する場合は、実際に提示している基本給を使用します
  • 第三者の求人サイトや人材会社が他社の求人を掲載する場合は、相場や独自の推計から算出した給与を、掲載者の判断で baseSalary に入れないでください

実際の求人条件として提示している金額がない場合は、無理に入れないでください。

チェックリスト3：ページの中身とマークアップの一致

構造化データは、ページに書かれている内容と一致していることが前提です。

  • マークアップの職種名と、ページのH1・本文の職種名が一致している
  • マークアップの給与と、募集要項に書かれた給与が一致している
  • マークアップの勤務地と、ページ内の勤務地が一致している
  • ページには表示していない情報を、マークアップにだけ入れていない
  • 募集要項が「別途ご相談」ばかりになっていないか（マークアップできる情報が実質ない状態になります）

ページに書いていないことをマークアップに入れる、あるいはページと違う内容を入れることは、ガイドライン違反にあたります。

チェックリスト4：title と description（通常のSEO側）

構造化データとは別に、検索結果に表示される要素も整えます。

  • title に職種と勤務地が入っているか
  • 求人ごとに title が違うか（テンプレートで全部同じになっていないか）
  • meta description が、その求人の内容を表しているか
  • 求人が大量にある場合の title 生成ルールが決まっているか

求人詳細ページが数千件規模になる場合の考え方は、別記事で詳しく扱っています。

チェックリスト5：募集終了時の対応

ここが一番運用で崩れやすいところです。

募集が終わった求人をそのまま放置すると、検索結果に出続けたり、応募できない求人に人が来たりします。

整理すると、判断は3つの層に分かれます。混ぜて考えると混乱するので、順に確認してください。

① JobPosting構造化データ

  • 募集終了に合わせて、構造化データを終了状態に更新するか、削除する仕組みがあるか
  • validThrough を設定している求人で、期限と実際の募集状況がずれていないか
  • 募集終了後も募集中として扱われるマークアップが残っていないか

② ページ自体の扱い

  • 募集終了後にページをどうするかが決まっているか（参考情報としてindex可能な状態で残す／404・410を返す／後継求人へ301で転送する）
  • その判断基準が、場当たりではなくルールとして共有されているか
  • ページを残す場合、募集が終了していることがユーザーに分かるか
  • 代わりの求人や、同じ職種・地域の一覧への導線があるか

この①と②は別の判断です。構造化データを終了状態にすることと、ページ自体を消すことは同じではありません。 ページを参考情報として残す選択もあり得ます。どちらを選ぶかの判断基準は、募集終了ページの扱いを扱った別記事に沿って決めてください。

③ サイトマップ

  • サイトマップの内容が、②で決めた最終的なindex方針と一致しているか

残すと決めたページはサイトマップに載っていてよく、404・410にしたページや転送したページは外します。「終了したら必ずサイトマップから外す」という一律の処理ではなく、②の結論に合わせるのが正しい順番です。

チェックリスト6：公開後の確認

  • リッチリザルトテストで、対象のURLがエラーなく認識されるか確認する
  • Search Consoleの関連するリッチリザルトのステータスレポートで、エラー・警告の件数と内訳を確認する
  • エラーと警告を区別する（警告は推奨項目の欠落で、必ずしも修正必須ではありません）
  • 1件だけでなく、テンプレートの種類ごとに複数のURLで確認する
  • JavaScriptで生成している場合、レンダリング後の状態で確認する
  • 新規求人が公開されてから認識されるまでのタイムラグを見込んでおく

1件確認して問題なければ全部大丈夫、とは限りません。派遣・紹介・正社員でテンプレートが分かれている場合や、給与形態が違う場合は、それぞれ確認してください。

よくある間違い

  • 「構造化データを入れたのに載らない」で止まってしまう
    ページ側の前提条件（ログイン、クロール可否、求人1件1URL）が満たされていないケースが多くあります。まずそちらを確認してください。
  • title に装飾語を入れる
    「【急募】」「高時給！」といった表現は、職種名ではありません。
  • 募集終了後の運用が決まっていない
    実装時は完璧でも、数か月後に終了求人が大量に残っている、という状態はよく見ます。
  • baseSalary に推定給与を入れる
    この項目は、雇用主が提供する実際の基本給を入れるものです。相場からの推計値や独自に算出した目安を入れる使い方は想定されていません。
  • 制作会社に「JobPostingを入れてください」とだけ依頼する
    hiringOrganization に何を入れるか、validThrough を社内のどの日付と連動させるか（そもそも設定するか）など、事前に整理が必要な項目があります。
  • 構造化データの実装をSEO施策の中心に据える
    掲載の前提条件を整えるものであって、それ自体が集客を生むわけではありません。求人ページの中身と検索の受け皿としての設計が土台です。

まとめ

Googleしごと検索への対応は、大きく3段階です。

  • ページの前提条件を整える（求人1件1URL、ログイン不要、クロール可能）
  • JobPosting構造化データを、ページの内容と一致させて実装する
  • 公開後の確認と、募集終了時の運用を仕組みにする

このうち3が抜けているケースが最も多い印象です。実装して終わりではなく、運用が続く形になっているかを確認してください。

求人ページの設計やGoogleしごと検索への対応を含めて見直したい場合は、ご相談ください。

関連記事