採用サイトのSEO対策｜求人の構造化データと応募導線の設計

この記事でわかること

採用サイトの競合は「他社の採用サイト」ではない

採用サイトのSEOがうまくいかない理由の多くは、施策そのものではなく、想定している競合が間違っていることにあります。ここを最初に整理しておかないと、あとに続く実装の優先順位がすべてずれます。

求職者は会社名ではなく「職種＋勤務地」で探す

転職活動の初期段階にいる人は、まだ企業名を持っていません。手元にあるのは「自分ができる仕事」と「通える範囲」だけです。したがって検索窓に入るのは職種名と地名の組み合わせになります。この検索に対して上位を占めるのは、求人を大量に保有している求人媒体のページです。1社の採用サイトが1つの職種ページで勝てる領域ではありません。

一方で、選考が進むにつれて検索語は変わります。媒体で見つけた求人に応募するかどうかを決める段階になると、求職者は会社名を打ち込みます。「会社名 採用」「会社名 求人」「会社名 中途」といった指名検索です。つまり採用サイトのSEOには、職種名や勤務地で探される発見のフェーズと、会社名で確認される検討のフェーズという、性質のまったく違う2つの戦場があります。両方に同じ施策を当てても効きません。

媒体経由と自社応募のどちらを増やしたいのかを先に決める

採用サイトの設計は、この一点で大きく変わります。

媒体経由の応募を増やしたい場合、採用サイトの役割は「媒体で自社を見つけた人が会社名で検索したときの受け皿」です。自社サイトは指名検索と、応募前の不安を解消するコンテンツに絞り込めます。求人ページを大量に自社サイトで持つ必要は必ずしもありません。

自社サイトからの直接応募を増やしたい場合、話は変わります。自社の求人ページそのものが検索の入口にならなければならず、JobPosting構造化データの実装、職種別ページの整備、応募フォームまでの導線の短縮が、すべて必須の作業になります。媒体費用を下げることが目的なら、この方向への投資です。

どちらが正しいということはありません。ただし決めずに始めると、「求人ページは作ったが構造化データは入れていない、社員インタビューは書いたが応募ボタンがない」という中途半端な状態になります。

2つの戦略で優先順位はこう変わる

やること	媒体経由を伸ばす場合	自社応募を伸ばす場合
JobPosting構造化データ	あれば望ましい	必須。最優先
職種別ページの整備	主要職種のみ	募集中の全職種
勤務地別ページ	不要なことが多い	拠点が複数あるなら必要
会社名＋採用の指名検索	必須。最優先	必須
社員インタビュー等のコンテンツ	必須（応募前の不安解消）	必須（同左）
応募フォームの短縮	媒体側の応募フローに依存	必須。段数を数えて削る
募集終了ページの処理	必要	必須。放置は違反リスク

この表を見ると、どちらの戦略でも共通して必要なのは「指名検索」「応募前の不安解消」「募集終了の処理」の3つだとわかります。リソースが限られているなら、まずこの3つから着手するのが安全です。

求人ページにJobPosting構造化データを実装する

Googleは、求人情報のウェブページにJobPosting構造化データを追加すると、その求人がGoogleの求人検索機能の表示対象になると説明しています。ロゴ、レビュー、評価、求人の詳細を目立たせられること、求職者が場所や役職で絞り込めるようになること、そしてサイトへアクセスする新たな手段が増えることが、公式ドキュメントに挙げられているメリットです。この機能が利用できる地域には日本も含まれています。

構造化データそのものの考え方は構造化データマークアップ完全ガイドで扱っているため、ここでは求人に固有の要件だけを整理します。

実装前に確認する3つのこと

Googleが示している手順の冒頭は、マークアップの書き方ではなく前提の確認です。

1. Googlebotがサイトを効率的にクロールできる状態になっていること
2. 同じ求人情報のコピーを別のURLに掲載する場合は、ページの各コピーで正規URLを使用すること
3. 必須プロパティと推奨プロパティを追加し、技術ガイドラインとコンテンツポリシーに従うこと

2番目は採用サイトで見落としやすい項目です。同じ求人を複数のURLで持つ構成（プレビュー用URL、パラメータ違いのURL、印刷用ページなど）になっていないかを先に確認してください。実装後は、リッチリザルトテストでコードを検証し、数ページだけ先行導入してURL検査ツールで表示を確認する順序が推奨されています。robots.txtやnoindexタグ、ログイン要件でページがブロックされていないかも、このタイミングで確認する項目として明記されています。

必須プロパティは5つ

求人情報としてGoogle検索に表示されるために必要なプロパティは次の5つです。

プロパティ	型	注意点
datePosted	Date	雇用主が求人情報を投稿した最初の日付。ISO 8601形式
description	Text	HTML形式の詳細な説明。職務・資格・スキル・業務時間・学歴要件・経験要件など。titleと同じ内容にはできない
hiringOrganization	Organization	会社名を指定する。所在地は含めない
jobLocation	Place	従業員の職場となる特定の場所。addressCountryを含める必要がある
title	Text	職務の名称。求人情報のタイトルではない

それぞれに、実務で引っかかりやすい細かい規定があります。

descriptionはHTML形式で書く

descriptionはHTML形式にする必要があり、段落を追加するにはbr、p、または改行を使うと記載されています。この機能が認識するHTMLタグはp、ul、liの3つです。h1やstrong、emといった見出しタグ・文字レベルのタグは書式設定に影響しないとされていますが、ページ内に追加しても安全だとも明記されています。つまり、装飾は効かないが害もない、という位置づけです。

hiringOrganizationに勤務地を混ぜない

会社名を指定するプロパティであり、所在地は含めないよう明示されています。ドキュメントには「Starbucks, Inc」は可、「Starbucks on Main Street」は不可という例が挙げられています。日本語の求人でも「株式会社サンプル 東京本社」のような書き方は避けてください。

なお、匿名で採用を行っている場合（匿名の雇用主の代理である人材派遣会社や、利用しているプラットフォーム上で直接採用を行う雇用主の場合）は、hiringOrganization.nameフィールドにconfidentialという値を使うと記載されています。

titleは職務の名称だけ

titleには求人コード、住所、日付、給与、会社名を含めないよう指定されています。ドキュメントが挙げている非推奨例は「ブカレストでフランス語を話せるIT技術者を募集中」、推奨例は「マーケティング専門家、フランス語話者」です。また、感嘆符やアスタリスクなどの特殊文字を多用すると、スパム行為のある構造化マークアップと見なされることがあると警告されています。アスタリスクで囲んで「倉庫でのお仕事です！バス停のすぐ近く！」と装飾した書き方が非推奨例、「倉庫での出荷・入荷の担当者」が推奨例として示されています。

加えて、titleの代わりにnameを使ってはならず、この2つのプロパティを入れ替えることはできないと明記されています。

推奨プロパティで求人の質を上げる

推奨プロパティは、ユーザーエクスペリエンスの向上につながる追加情報という位置づけです。

プロパティ	役割	注意点
employmentType	雇用形態	FULL_TIME／PART_TIME／CONTRACTOR／TEMPORARY／INTERN／VOLUNTEER／PER_DIEM／OTHERから1つ以上。大文字小文字を区別。複数指定可
baseSalary	基本給	雇用主から提示された実際の基本給。概算額は不可。雇用主以外は指定しない
validThrough	有効期限	求人情報に有効期限がある場合は必須。期限がない・不明な場合は指定しない
identifier	求人の識別子	採用側組織の一意の識別子
jobLocationType	リモート勤務	完全にリモートワークの求人ではTELECOMMUTEを設定。完全リモートの場合は必須
applicantLocationRequirements	勤務可能地域	完全リモートの場合は必須。国を1つ以上指定する
directApply	直接応募の可否	Boolean。使い方はまだ開発中で、すぐには検索に反映されない場合がある

baseSalaryのunitTextに使える値は、HOUR・DAY・WEEK・MONTH・YEARのいずれかで、大文字小文字を区別します。給与の範囲を示す場合はvalueではなくminValueとmaxValueを定義します。

このほか、学歴と経験に関するベータ版のプロパティとして、educationRequirements、experienceRequirements、experienceInPlaceOfEducationが用意されています。credentialCategoryに使える値はhigh school、associate degree、bachelor degree、professional certificate、postgraduate degreeで、要件がない場合はno requirements、不明な場合はプロパティ自体を追加しないと案内されています。いずれも、プロパティを追加したうえでdescriptionにも引き続き要件を記述するよう指示されている点に注意してください。

実装例

必須プロパティと主要な推奨プロパティを含めた形が次になります。JSON-LDをページのscript要素に埋め込みます。

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "JobPosting",
  "title": "フロントエンドエンジニア",
  "description": "<p>自社プロダクトの画面開発を担当していただきます。</p><ul><li>TypeScriptでの実務経験2年以上</li><li>勤務時間 9:30〜18:30（フレックスタイム制）</li></ul>",
  "identifier": {
    "@type": "PropertyValue",
    "name": "株式会社サンプル",
    "value": "ENG-2026-014"
  },
  "datePosted": "2026-09-01",
  "validThrough": "2026-11-30T23:59",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "株式会社サンプル",
    "sameAs": "https://www.example.com",
    "logo": "https://www.example.com/images/logo.png"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "丸の内1-1-1",
      "addressLocality": "千代田区",
      "addressRegion": "東京都",
      "postalCode": "100-0005",
      "addressCountry": "JP"
    }
  },
  "baseSalary": {
    "@type": "MonetaryAmount",
    "currency": "JPY",
    "value": {
      "@type": "QuantitativeValue",
      "minValue": 5000000,
      "maxValue": 8000000,
      "unitText": "YEAR"
    }
  }
}
</script>

descriptionの中にHTMLタグを書いている点に注目してください。「HTML形式にする必要がある」という規定に沿った書き方です。また、baseSalaryを入れるなら同じ給与情報を求人ページ上にも表示する必要があります。マークアップにあってページにない情報は、後述するコンテンツガイドライン違反として扱われます。

hiringOrganizationのlogoは、画像の幅と高さの比率を0.75〜2.5にする必要があります。ただしGoogleは通常、会社のナレッジグラフカードに表示されている画像と同じロゴを求人情報に使用します。logoプロパティは求人サイトだけに表示されるもので、組織の標準ロゴとしては扱われないと説明されています。

完全リモートの求人は3つのプロパティで表す

在宅勤務・リモートワークの求人には、専用の指定方法があります。Googleが挙げているプロパティは次の3つです。

• jobLocationType：在宅勤務の求人であることを指定する
• applicantLocationRequirements：従業員が在宅勤務のために所在する地域を指定する。国を1つ以上指定する必要がある
• jobLocation：勤務地となる特定の場所を指定する。オフィスや建設現場のような特定の場所が存在しない場合は使用しなくてよい

完全にリモートワークの求人で、勤務地の制約が国単位である場合は次の形になります。

"applicantLocationRequirements": {
  "@type": "Country",
  "name": "Japan"
},
"jobLocationType": "TELECOMMUTE"

ここで重要なのはTELECOMMUTEを付けてよい条件です。ドキュメントには、TELECOMMUTEが設定された求人は完全にリモートワークである必要があり、一時的な在宅勤務が許される求人、交渉次第でリモートワークが可能な求人、完全なリモートワークではないその他の業務形態にこの値を設定してはならないと明記されています。「週2日はリモート可」といった求人に付けるのは誤りです。

加えて、jobLocationTypeを追加するだけでなく、その求人が完全にリモートワークであることを求人情報の本文にも明記する必要があるとされています。構造化データとページの表示内容を一致させる、という原則がここにも適用されます。

特定のオフィスへの出社とリモートを選べる求人では、jobLocationとjobLocationTypeを併用します。applicantLocationRequirementsが指定されていない場合は、jobLocationで指定された国のすべての求職者にその求人情報が表示される、という挙動も記載されています。

マークアップとページの表示内容は一致させる

トラブルシューティングの項目に、「コンテンツが構造化データと一致しない」という典型的な失敗が挙げられています。ページ上の職務名がtitleプロパティの値と一致しない場合や、給与がマークアップに含まれているのに求人ページには含まれていない場合が例として示されており、後者についてはマークアップのすべての情報を求人ページに表示する必要があると明記されています。この場合、Search Consoleに「構造化データのポリシー違反 – ページ上のコンテンツがページの構造化データと異なっています」というメッセージが表示されることがあります。修正後は、URL検査ツールでレンダリングされたページにコンテンツが表示されていることを確認し、再審査を送信します。

募集終了の求人をどう扱うか

採用サイトのSEOで最も事故が多いのがここです。求人ページは公開して終わりではなく、募集が終わったときに必ず処理が必要なページだという点が、他のコンテンツとの決定的な違いになります。

放置すると手動による対策の対象になり得る

ドキュメントには、すでに応募を受け付けていない求人は終了させる必要があり、終了した求人に対してタイムリーな措置を講じないと、手動による対策が必要になる場合があると書かれています。コンテンツポリシーにも「期限切れの求人情報は掲載できません」という項目が独立して設けられています。

Search Consoleに「構造化データのポリシー違反 – 有効期限が切れた求人のJobPosting構造化データ」というメッセージが表示されることがあり、その原因としては次が挙げられています。

• validThroughプロパティがないか、過去の日付に設定されていない
• ページがまだ公開されている
• 求人情報の応募機能のフローが期限切れになった求人情報ページにリンクしている
• 求人が期限切れになっても、JobPosting構造化データがページにまだ存在している

3番目は見落としやすい項目です。求人ページ自体は消したつもりでも、応募フォームの完了画面や確認メールからリンクが残っていることがあります。

終了処理は3つのいずれか

期限切れの求人情報を削除する方法として、次のいずれかを行うよう記載されています。

1. validThroughプロパティが設定されていて、その期間を過ぎていることを確認する
2. ページを完全に削除する（ページのリクエストに対して404または410ステータスコードが返されるようになる）
3. JobPosting構造化データをページから削除する

実務ではこの3つを使い分けます。他の募集への導線としてページを残したい場合は3番目、求人ページを完全に整理したい場合は2番目、公開時点で終了予定日が確定しているなら1番目を最初から仕込んでおく方法です。

なお、validThroughは「求人情報に有効期限がある場合に必須」のプロパティであり、有効期限がない場合や、いつ期限切れになるかがわからない場合は指定しないよう指示されています。そして求人情報が期限切れになる前に採用が決まった場合は、求人情報を削除してくださいと明記されています。期限日まで放置してよいわけではありません。ページを削除する場合の404と410の使い分けはリダイレクトとは？301・302の違いと設定方法・SEO影響で整理しています。

Googleへの通知はIndexing APIが推奨されている

求人情報の扱いで独特なのが、更新をGoogleに伝える手段の推奨順です。ドキュメントは、求人情報のURLではサイトマップではなくIndexing APIを使用することをおすすめしますと明記しています。理由として、Indexing APIのほうが早くGooglebotに対しページをクロールするよう指示を出せること、削除の場面ではサイトマップからURLを削除するよりも早いことが挙げられています。

ただしIndexing APIだけで完結するわけではなく、サイト全体をカバーするためにサイトマップを送信することも引き続き推奨されています。Googleはサイトマップ全体を取り込み、lastmodの時刻が前回のクロールより新しいページを再クロールする、という説明も添えられています。

サイトマップ側にも求人情報向けの追記があります。lastmodの値にはできる限り正確な時刻を指定すること、検索結果ページ・リストページ・その他の動的なページを含めないこと、各求人情報の正規ページを含めることの3点です。基本的な作り方はサイトマップとは？XMLの作り方・SEO効果・送信手順を参照してください。

募集の再開は「実際に募集中の職種」のみ

コンテンツポリシーには「募集の再開」という項目があり、サイト運営者は募集中の職種についてのみ募集を再開できると書かれています。あわせて、Googleは応募者のデータを収集しながら採用を行っていない求人は削除する場合があると明記しています。

「とりあえず通年で募集を出しておく」「人材データベースを作るために募集を続ける」といった運用は、このポリシーに抵触します。求人の要件の項目にも、応募者が就業を応諾している場合には求人情報は掲載できないと書かれています。採用が決まったら、その求人ページは終了処理をしてください。

職種別・勤務地別ページの設計

ここからは、求人ページをどう並べるかという情報設計の話に移ります。

構造化データはリーフページに、一覧ページには置かない

技術に関するガイドラインの冒頭に、次の指示があります。構造化データは可能な限り最も詳細なリーフページに実装し、求人リストを提供することを目的としたページ（検索結果ページなど）には追加しない。構造化データは1件の求人とそれに関連する詳細情報を記載した、最も詳細なページに適用します。

トラブルシューティングにも「構造化データが間違ったページにある」という項目があり、求人リストのページにJobPosting構造化データがある場合、「構造化データのポリシー違反 – リスティングページに個々の求人の構造化データを含めることはできません」というメッセージがSearch Consoleに表示されることがあると説明されています。

採用サイトのテンプレートでは、求人一覧ページに各求人のカードを並べ、その勢いで一覧側にもJSON-LDを出力してしまう実装がよくあります。これは明確に違反です。一覧ページには置かない、と実装ルールに書いてください。

コンテンツポリシーの「無関係なコンテンツ」でも、JobPostingマークアップは求人情報が1件掲載されるページでのみ使用するものだと繰り返されています。会社紹介ページや採用トップページに置くのも同様に不可です。

職種別ページを作るかどうかの判断

職種別ページには2つの意味があります。ひとつは個別の求人ページ、もうひとつは職種を説明する常設ページです。この2つを混同すると設計が崩れます。

個別の求人ページは、募集が終われば終了処理が必要な一時的なページです。一方、「当社のエンジニア職について」のような常設ページは募集の有無にかかわらず残り続けるページで、JobPosting構造化データを載せる対象ではありません。募集中の求人へのリンクを持つハブとして機能させ、募集がないときは「現在募集はありません」と表示すればページ自体は残せます。

常設ページを作る価値があるのは、その職種に検索需要があり、かつ自社が語れる中身がある場合に限られます。職種名だけを差し替えたテンプレートページを量産すると、内容の薄いページが増えるだけです。キーワードの需要と競合状況の確認手順はキーワード選定の完全マニュアルにまとめています。

同じ求人を複数URLで持つときはcanonicalで一本化する

先述のとおり、別のURLでホストされているサイトに同じ求人情報のコピーを掲載する場合は、ページの各コピーで正規URLを使用するようGoogleは案内しています。サイトマップに含めるURLも各求人情報の正規ページであるべきだと明記されています。

採用サイトでこの問題が起きやすいのは、職種一覧と勤務地一覧の両方からパラメータ違いのURLで同じ求人ページに到達できるケース、採用管理システム（ATS）が生成するURLと自社サイト上の求人ページが両方存在するケース、プレビュー用URLや旧テンプレートのURLが公開されたまま残っているケースです。いずれも正規URLを1つ決めて全コピーから指し示すことで解決します。実装の判断基準はcanonicalタグとは？URL正規化と重複コンテンツ対策を参照してください。

勤務地ページとローカルSEOの境界

複数拠点で採用している企業では、勤務地別のページを作るかどうかが論点になります。JobPostingの側から見ると、職場が複数ある場合はjobLocationプロパティを配列で複数追加でき、Googleは求職者の質問に基づいて表示する最適な場所を選択すると説明されています。つまり、1つの求人ページで複数勤務地を表現すること自体は仕様上可能です。

一方で、店舗や事業所そのものを地域名で検索されたときにどう見せるかは、採用サイトのSEOではなくローカルSEOの領域です。Googleビジネスプロフィールの整備や地域ページの設計はローカルSEOとは？MEOとの違い・GBP最適化・対策7選で扱っています。採用の文脈で勤務地ページを作る場合も、既存の拠点ページと役割が重複しないかを先に確認してください。

なお、トラブルシューティングには「求人の場所が実在しない、または間違っている」という項目があり、jobLocation、addressLocality、addressRegionに指定した値がGoogleで認識されない場合に発生すると説明されています。できるだけ多くの地域プロパティを指定するほど求人情報の質が高くなるとも書かれています。住所は略さず、正確に入れてください。

会社名＋採用の指名検索を取りに行く

ここが、採用サイトを自前で持つ最大の理由です。

指名検索で何が起きているか

「会社名 採用」「会社名 求人」「会社名 中途採用」といった検索をする人は、すでに自社を認知しています。媒体で求人を見た人、知人から会社名を聞いた人、面接の前に情報を集めている人です。応募・辞退の判断がこの検索の先で行われると考えて構いません。にもかかわらず、この検索結果に自社の採用サイトが必ず出るとは限りません。求人媒体の企業ページ、クチコミサイト、まとめ記事が上位を占めていることがあり、自社が発信していない情報だけが読まれる状態は採用活動にとって明確な不利になります。

指名検索で自社ページを確実に出すためにやることは、通常のSEOと変わりません。採用サイトのトップページで会社名と「採用」を自然に含んだタイトル・見出しを整え、コーポレートサイトから明確にリンクし、パンくずリストで階層を示します。パンくずリストの設置方法と構造化データとSEO内部リンク戦略の設計と実装が実装の参考になります。

クチコミサイトが上位を占めるとき

クチコミサイトの順位を下げることはできません。できるのは、自社の情報を充実させて検索結果のうち自社が占める枠を増やすことだけです。採用トップ、職種別ページ、社員インタビュー、選考フローの説明、福利厚生のページと、指名検索に対して答えられるページを複数持っておくと、結果として自社ページが表示される確率が上がります。あわせて、残業・評価制度・離職率など応募者が気にする論点に自社の言葉で答えるページを用意しておけば、「何も書かれていない」という状態は避けられます。

採用サイトを分けるか、コーポレートサイト内に置くか

別ドメイン、サブドメイン、サブディレクトリのどれにするかは、採用サイトの構築で必ず出る論点です。SEOの観点だけで言えば、コーポレートサイトのサブディレクトリに置くのが最も無駄がありません。既存ドメインの評価をそのまま使え、内部リンクで往復でき、サイトマップも一本で済みます。

別ドメインにすると、そのドメインの評価をゼロから積み上げることになります。ドメインパワーとは？調べ方・目安・上げ方で扱っているとおり、これは時間のかかる作業です。採用ブランディングの都合で別ドメインにする判断はあり得ますが、SEO上のコストは理解したうえで決めてください。すでに別ドメインで運用しているなら、コーポレートサイトからの導線を明確にし、どちらが指名検索で出ても求職者が迷わないようナビゲーションを揃えるのが現実的な対応です。

社員インタビューなどのコンテンツの役割

採用サイトの制作でほぼ必ず作られるのが社員インタビューです。ただし、この種のコンテンツを「検索流入を取るためのコンテンツ」として位置づけると、期待した結果になりません。

検索流入は取れない。それでも必要な理由

社員インタビューが上位表示される検索語は、基本的に存在しません。「〇〇（社員名）」で検索する人はいませんし、職種名で検索する人が求めているのは求人情報です。にもかかわらずインタビューが必要なのは、指名検索で来た人が読むからです。

求人票に書かれているのは条件です。しかし応募を決める段階で人が知りたいのは、実際にどんな仕事なのか、どんな人と働くのか、入社後に何が起きるのかという情報です。この差を埋めるのがインタビューやプロジェクト紹介の役割になります。応募数ではなく、応募前の離脱を減らすためのコンテンツだと考えてください。

ただし、詳細をインタビュー任せにするのは別の問題を招きます。Googleはコンテンツポリシーで、求人の説明が不完全である求人情報は掲載できないと明記しており、必要な資格や求職中のユーザーに関わる情報など、募集中の職種に関する説明を記載する必要があるとしています。求人票は求人票として完結させたうえで、インタビューを補足として置くのが正しい構成です。

職種ページからインタビューへの内部リンクを設計する

インタビューを作っただけでは読まれません。読まれる経路は、ほぼ職種ページか求人ページからの内部リンクに限られます。「フロントエンドエンジニアの求人ページ」から「フロントエンドエンジニアとして働く社員のインタビュー」へリンクが通っているか。この対応関係を作らずにインタビューだけを量産している採用サイトは少なくありません。逆方向のリンクも必要で、インタビューを読んで興味を持った人がその職種の募集へすぐ移動できるようにします。

AI検索で会社について尋ねられたときの情報源になる

求職者が生成AIに「この会社はどんな会社か」と尋ねるケースは増えています。このとき参照されるのはウェブ上に存在する情報であり、自社が何も書いていなければ第三者の情報だけが読まれます。

AI検索に引用されやすい記事の条件は、当メディアでも焦点を絞った具体的な記事はAIに引用されやすい？で扱いました。採用コンテンツでも同じで、「風通しの良い社風です」のような形容よりも、具体的な業務内容、使っている技術、意思決定の進め方といった固有の情報のほうが引用の対象になります。AI検索全般への対応はLLMO対策｜ChatGPT・Gemini・Perplexityに引用される手順にまとめています。

応募フォームまでの導線を設計する

SEOの成果は応募数で測られます。検索から求人ページに到達した人が応募を完了するまでに、どれだけの障害があるかを点検します。

応募方法が示されていない求人は掲載できない

これはコンテンツポリシーに明記された要件です。応募方法が示されていない求人情報は掲載できないとされ、該当する例として次の2つが挙げられています。

• 求職求人フェアへの招待など、イベントの広告になっている求人情報
• 求人の説明を表示するためにログインを必要とする求人情報。ユーザーがログインすることなく、求人情報の詳細を閲覧できるようにする必要がある

2番目は、採用管理システムを導入している企業で起きがちです。求人詳細を見るために会員登録を求める設計になっていないか確認してください。トラブルシューティングにも「応募機能がない」という項目があり、求人情報ページ上にユーザーが求人に応募するための手段がない場合、「構造化データのポリシー違反 – 求人ページで申し込みを送信できません」というメッセージが表示されることがあると説明されています。

あわせて、応募者からの支払いを必要とする求人情報は掲載できないという項目もあります。

directApplyの考え方＝余計な中間ステップを挟まない

directApplyプロパティ自体は、この情報の使い方がまだ開発中で、すぐには検索に表示されない、または効果が表れない場合があるとされています。ただし、Googleが「直接応募」をどう定義しているかは、導線設計の基準としてそのまま使えます。

ドキュメントによれば、直接応募とはページ上に不必要な中間ステップがなく、簡潔かつ短いステップで応募プロセスを完了できることを意味します。ユーザーが応募をクリックして応募フォームに記入し、応募プロセスに際して何度もログインしなければいけない場合は、直接応募が実現されていないことを示すと明記されています。

直接応募が実現されている可能性が高い条件として、次が挙げられています。

• ユーザーがサイト上で応募プロセスを完了できる
• ユーザーがGoogle経由でページにアクセスした後、応募プロセスを完了するために何度もクリックしてユーザー情報を入力する必要がない
• 求人情報に、応募書類を提出できるメールアドレス・電話番号・住所や、雇用主との面接を設定する方法が記載されている。記載するのは、人材を募集している企業またはその担当者に直接問い合わせるための方法である必要がある

この基準に照らして、自社の応募導線を実際にクリックして数えてみてください。求人ページ→応募ボタン→会員登録→メール認証→ログイン→フォーム入力、という流れになっていれば、途中で相当数が離脱しています。

応募完了までのステップを数える

実務では、次の順で削っていくのが効率的です。

1. 会員登録の必須化を外せないか：応募と会員登録は別のものです。まず応募させて、必要ならあとで登録を案内します
2. 入力項目を減らせないか：初回応募で必要なのは連絡先・応募職種・職務経歴です。それ以外は面接調整時でも聞けます
3. スマートフォンで完了できるか：履歴書ファイルの添付を必須にすると、スマートフォンからの応募が事実上できなくなります
4. エラー時に入力内容が消えないか：やり直しになる実装は、そこで応募が終わります

ボタンの文言や配置の設計はCTAとは？効果的なボタンのデザイン・配置・文言の作り方、フォーム完了率の改善全般はCVRとは？コンバージョン率の計算・業界平均・改善施策で扱っています。

効果測定：媒体経由と自社応募を分けて見る

採用サイトのSEOは、応募数という最終指標だけを見ていても改善点が見えません。段階ごとに分けて見ていきます。

Search Consoleで求人の表示状況を監視する

構造化データを初めてデプロイした後、新しいテンプレートをリリースした後やコードを更新した後、そしてトラフィックを定期的に分析する場合に、Search Consoleを確認することが推奨されています。ページがインデックスに登録されたら、リッチリザルトのステータスレポートで有効な項目が増え、無効な項目が増えていない状態を確認します。

テンプレート更新後に無効な項目が増加した場合は、新しく公開したテンプレートが正常に機能していないか、既存のテンプレートの新しい操作方法に問題があると考えられると説明されています。有効な項目が減少している（無効な項目の増加と一致しない）場合は、ページに構造化データが埋め込まれていない可能性があるとされ、URL検査ツールで原因を特定します。Search Console自体の使い方はサーチコンソールの使い方完全ガイドにまとめています。

UTMパラメータで求人検索経由の流入を分離する

Google検索セントラルは、求人の詳細ページからサイトにユーザーを誘導した後のアクセスを追跡するために、カスタムのUTMパラメータを使えると案内しています。Googleアナリティクスまたはその他のサードパーティトラッキングツールで使用できるパラメータとして、次の3つが示されています。

utm_campaign=google_jobs_apply
utm_source=google_jobs_apply
utm_medium=organic

これを応募完了イベントまで引き継げるようにしておくと、求人検索経由の流入がどれだけ応募に結びついたかを分離して見られます。GA4側の設定はGA4でSEO効果を測る方法にまとめています。

どこで落ちたかを見る

追うべき数字は、少なくとも次の4段階に分解できます。

段階	見る指標	下がっているときの主な原因
検索での表示	表示回数（Search Console）	構造化データの不備、募集終了ページの残存、インデックス未登録
求人ページへの到達	クリック数・CTR	職務名がわかりにくい、勤務地・雇用形態が伝わっていない
応募開始	応募ボタンのクリック率	求人内容と検索意図のずれ、情報不足、給与非公開
応募完了	フォーム完了率	入力項目過多、会員登録の必須化、スマートフォン非対応

指標の定義と選び方はSEO指標一覧｜重要度別の定義・確認方法・改善策、レポートの型はSEOレポートの作り方を参考にしてください。

採用サイトSEOのチェックリスト

ここまでの内容を、着手順に並べ直します。

優先度	項目	確認内容
最優先	募集終了ページの処理	終了した求人が公開されたままになっていないか。validThroughが過去日か、404／410か、構造化データが外れているか
最優先	一覧ページのJobPosting	求人一覧・検索結果ページにJobPostingを出力していないか
最優先	応募導線	ログインなしで求人詳細が読めるか。応募方法がページ上に示されているか
高	必須プロパティとtitle	5つの必須プロパティが揃っているか。titleに会社名・勤務地・給与・求人コード・特殊文字が混ざっていないか
高	マークアップと表示の一致	給与など、マークアップに入れた情報がページにも表示されているか
中	正規URLとリモート指定	同じ求人が複数URLで存在していないか。TELECOMMUTEを完全リモート以外に付けていないか
中	Indexing APIとサイトマップ	求人URLの更新・削除をIndexing APIで通知しているか。サイトマップも送信しているか
中	指名検索	「会社名 採用」で自社ページが上位に出るか。コーポレートサイトから導線があるか

採用サイトのSEOに関するよくある質問

Q1: 求人媒体に載せているなら、自社の求人ページは不要ですか？

媒体経由の応募だけで採用計画が満たせているなら、自社の求人ページを大量に持つ必要はありません。ただし「会社名＋採用」の指名検索の受け皿だけは自社サイトに必要です。媒体で自社を見つけた人は、応募前にほぼ必ず会社名で検索します。

Q2: 給与を公開したくないのですが、baseSalaryは省略できますか？

baseSalaryは推奨プロパティなので、省略しても構造化データとしては成立します。ただし省略する場合はマークアップ側にも書かないでください。マークアップに給与があってページに表示されていない状態は、コンテンツガイドライン違反として扱われます。なおbaseSalaryは雇用主から提示された実際の基本給を指定するもので、概算額は不可、雇用主以外は指定しないと明記されています。

Q3: 通年で募集を出し続けても問題ありませんか？

実際に募集している職種であれば問題ありません。ただしコンテンツポリシーには、募集の再開は募集中の職種についてのみ可能であり、応募者のデータを収集しながら採用を行っていない求人はGoogleが削除する場合があると記載されています。

Q4: 「週2日リモート可」の求人にTELECOMMUTEを付けてもよいですか？

付けてはいけません。TELECOMMUTEが設定された求人は完全にリモートワークである必要があり、一時的な在宅勤務が許される求人、交渉次第でリモートワークが可能な求人、完全なリモートワークではないその他の業務形態にこの値を設定しないよう明記されています。ハイブリッド勤務は、jobLocationで勤務地を示したうえで、勤務条件を本文に書くのが適切です。

Q5: 構造化データを入れれば必ず求人検索に表示されますか？

されません。構造化データを使用するコンテンツが必ず検索結果に表示されるとは限らないと明記されています。また、ページを公開してからGoogleが検出してクロールするまで数日かかる場合があることにも注意が必要です。表示されない場合は、リッチリザルトテストと構造化データエラーの一覧、手動による対策レポートを順に確認してください。

Q6: 採用担当者が自分で更新できる体制にする際の注意点は？

JSON-LDは手書きさせず、テンプレート側で自動出力する設計にしてください。担当者が入力するのは職務名・説明・勤務地・雇用形態・期限といったフィールドだけにします。そのうえで、募集終了時の処理を運用フローに組み込んでください。手作業に依存すると、終了処理の抜けが必ず発生します。

まとめ｜構造化データより先に、終了処理と応募導線

採用サイトのSEOの要点を整理します。

• 採用サイトが検索で並ぶ相手は他社の採用サイトではなく求人媒体。媒体経由を伸ばすのか自社応募を伸ばすのかで、施策の優先順位が変わる
• JobPostingの必須プロパティは、datePosted・description・hiringOrganization・jobLocation・titleの5つ。titleには職務の名称だけを書く
• 構造化データは1件の求人の専用ページにだけ置く。一覧ページや検索結果ページに置くのはポリシー違反
• マークアップした情報は必ずページ上にも表示する。給与をマークアップだけに書くのは違反
• 募集終了時は、validThroughを過去日にする／404か410で削除する／構造化データを外す、のいずれかで必ず処理する。放置は手動による対策の対象になり得る
• 求人URLの更新・削除は、サイトマップよりIndexing APIでの通知が推奨されている。ただしサイトマップの送信も引き続き必要
• ログインしないと求人詳細が読めない設計、応募方法が示されていない求人は掲載できない

優先順位に迷ったら、構造化データの実装より先に募集終了ページの処理と応募導線の点検から手をつけてください。前者は違反リスクを直接下げ、後者は今すでに来ている求職者の離脱を止めます。構造化データは、その土台ができてから積む施策です。

サイトの種類が変われば、SEOで効く打ち手も変わります。技術面の全体像はテクニカルSEO完全ガイド、SEO施策全体の見取り図はSEO対策とは？基本から実践手順・チェックリストまでを参照してください。

本記事の求人情報（JobPosting）構造化データに関する記述は、Google 検索セントラル「求人情報（JobPosting）の構造化データ」（日本語版・最終更新日 2026年2月20日、2026年9月5日取得）の記載にもとづいています。必須／推奨プロパティ、コンテンツポリシー、募集終了時の処理、トラブルシューティングの各項目は、同ドキュメントに記載されている内容の範囲で記述しました。求人媒体など外部サービスの仕様については、公式の一次情報を確認できていないため本記事では扱っていません。構造化データの仕様およびポリシーは変更されることがあるため、実装前に必ず最新のドキュメントをご確認ください。

関連記事｜サイト種別別SEO

他の種別の考え方も見ておくと、自社の優先順位が判断しやすくなります。

• サイト種別で変わるSEO対策— 6タイプ別に打ち手の優先順位を整理した全体像
• ECサイトのSEO対策— 商品ページ・カテゴリ設計・重複の扱い
• BtoBサイトのSEO対策— 検索数が少ない前提での商談への設計
• コーポレートサイトのSEO対策— 指名検索と信頼性の設計
• メディアサイトのSEO対策— 回遊設計とAI検索時代の記事設計
• ポータル・比較サイトのSEO対策— 大量ページの品質を保つ設計

無料ダウンロード資料

はじめてのSEO 完全ガイド

Web担当になった人が、90日で自走するための実務書

検索エンジンの仕組みから、キーワード選定・記事づくり・技術対応・効果測定、 そしてAI検索時代の打ち手まで。専門用語の知識ゼロの状態から読み始められるよう、用語はすべて本文中で説明しています。

体裁	PDF／A4縦・全109ページ
収録	図解21点、チェックリスト120項目、90日実行プラン、用語集56語

※フォーム送信後、ご入力のメールアドレス宛にダウンロードリンクをお送りいたします。

資料の詳細と目次を見る

こちらのフォームにご記入ください

入力は1分ほどで終わります。

Website

会社名必須

部署名任意

お名前必須

メールアドレス必須

電話番号必須

従業員規模必須 選択してください 1〜9名 10〜49名 50〜99名 100〜299名 300〜999名 1,000名以上

SEOの検討状況必須 選択してください 何から始めるべきか検討中 自社で運用しているが成果が出ていない 外部への委託を検討している 現在の委託先を見直したい 情報収集のみ

プライバシーポリシーに同意する必須

資料をダウンロードする

ご入力いただいた情報は、資料のご送付および当社サービスのご案内のために利用します。