制作・引き渡し

Googleしごと検索に掲載されないときの確認順

Googleしごと検索で求人が見つからないときに、公開URLの取得、インデックス登録、正規URL、JobPostingの出力と内容を確認する順番を整理します。WordPressとSearch Consoleで見る場所、修正後に残す記録も紹介します。

取得、登録、求人要件の3段階を縦に並べ、Googleしごと検索に掲載されないときの確認順を示した図解

WordPressで求人を公開し、リッチリザルト テストにも合格した。それでもGoogleしごと検索で見つからないと、構造化データのどこを直せばよいのか迷います。

調べる段階は3つあります。Googleがページを取得できるか、検索対象として登録されているか、求人情報としての要件を満たすかを分けて確認します。検索結果に見当たらないという事実だけでは、止まっている段階を特定できません。

求人情報を検索エンジンへ伝える構造化データがJobPostingです。ただし、正しく設定しても掲載は保証されません。Googleは、リッチリザルト テストで検証できる技術要件と、そこで判定しきれない品質要件を分けています。Googleの構造化データに関するガイドライン

まず、求人詳細URLを1件に絞る

確認するのは、現在募集中の求人詳細URLです。求人一覧や管理画面のプレビューURLを入力していないか、最初に確かめてください。複数の求人を同時に追うと、あるページの検査結果を別のページの修正根拠にしてしまいます。

次の表を上から確認し、問題が見つかった段階の修正を先に進めます。右端の欄は、調査の範囲を絞るために使います。各項目を直しても掲載の保証にはなりません。

確認すること見る場所問題がある場合の次の作業
募集中で、求人詳細を誰でも読めるかログインしていないブラウザー終了求人なら終了処理へ。非公開の求人を無理に検索対象へ戻さない
Googleが取得・登録できる設定かSearch ConsoleのURL検査、公開ページの設定取得失敗、クロール制限、noindexによる検索除外を切り分ける
意図したURLが正規URLになっているかURL検査の登録済みデータ正規URLの指定と転送先を確認する
公開URLから有効な求人情報を読めるかリッチリザルト テストのURL検査未検出なら出力を、無効なら指摘された項目を調べる
求人の内容と応募方法が要件に合うか求人本文、構造化データ、応募先情報の不一致や応募できない状態を直す

ログインしていない状態で求人詳細を開く

管理者には見えていても、一般の訪問者にはログイン画面や準備中の案内しか表示されない場合があります。公開URLをログインしていないブラウザーで開き、求人内容を最後まで読めるか確認します。応募ボタンの有無だけでなく、応募先へ進めるかも見てください。

人が読めるページでも、検索対象から除外する設定は残り得ます。WordPressでは「設定」→「表示設定」の検索エンジン向けの設定を確認します。「検索エンジンがサイトをインデックスしないようにする」は、通常の訪問者を遮断する設定ではありません。WordPress公式の表示設定の説明

ここで設定を変更するのは、一般公開する本番サイトだと確認できた場合です。検証環境や非公開サイトの保護を、掲載されない原因を探すために外さないでください。

ページ側のnoindexにも確認が必要です。HTML内の指定に加え、サーバーが返すHTTPヘッダーのX-Robots-Tagにも指定できます。制作担当者には、両方の出力を確認してもらいます。GoogleのrobotsメタタグとHTTPヘッダーの説明

Search Consoleでは、前回の取得結果と現在を分ける

URL検査を開いて最初に出るのは、Googleが把握しているページの情報です。修正直後のページを、その場で読み直した結果とは限りません。まず、最終クロール日時が表示されていれば、自分たちが修正した日時と比べます。

「URL が Google に登録されていません」と出た場合は、ページのインデックス登録欄で理由を確認します。未登録という状態だけで、JobPostingの記述ミスとは判断しません。

次に「公開URLをテスト」で現在の状態を調べます。取得できたか、クロールが許可されているか、インデックス登録を妨げる指定がないかを確認してください。クロールが許可されていなければ、robots.txtの制限を調べます。取得失敗があるなら、構造化データの項目を増やす前に、その失敗を制作担当者へ渡します。

公開URLのテストが成功しても、インデックス登録済みになったわけではありません。Googleが選ぶ正規URLや、すべての掲載要件を判定できる検査でもありません。GoogleのURL検査ツールの説明

たとえば、修正後の公開テストは成功し、最終クロール日時は修正前のまま、という結果も考えられます。その場合は、以前の結果だけを根拠に同じ設定を直し続けず、再取得後の結果と比べられるよう日時を残します。

Googleが選んだ正規URLを確かめる

同じ求人を複数のURLで公開している場合は、どのURLを代表として扱うかも確認します。その代表が正規URLです。Search Consoleの登録済みデータでは、サイト側の指定と、Googleが選んだ正規URLを見比べます。

たとえば、求人詳細の正規URLを誤って求人一覧へ指定していれば、詳細URLを調べ続ける前に指定の意図を確かめる必要があります。これは診断のための仮例であり、掲載されない原因が常に正規URLにあるという意味ではありません。

制作担当者とは、この求人の代表URLを確かめます。rel="canonical"の指定、リダイレクト先、サイトマップ、内部リンクの行き先が食い違っていないかを調べてください。正規URLの指定はGoogleへの手がかりであり、必ず採用される命令ではありません。Googleの重複URLを統合する方法

別URLが選ばれていても、それだけで設定ミスとは決めません。意図した重複なのか、指定が食い違っているのかを確認し、実際に代表となった求人ページの内容も調べます。

公開URLの検査結果と、求職者が読む内容を照合する

ページを取得でき、調べるURLも定まったら、リッチリザルト テストへ公開URLを入力します。手元のコードが合格していても、そのコードが本番ページに出力されているとは限りません。

求人情報が検出されない場合は、ページ側の出力を確認します。検出された情報が無効なら、検査結果にあるエラーを確認します。この2つを分けると、出力処理と求人データのどちらから調べるかを決めやすくなります。Googleのリッチリザルト テストの説明

続いて、構造化データと画面上の職種、勤務地、募集内容が一致しているかを見ます。JobPostingを置くのは求人1件の詳細ページであり、複数求人の一覧ではありません。求人の説明はログインなしで読め、応募方法も必要です。Googleの求人情報の構造化データ要件

募集が終わっていると分かったら、掲載を戻すために期限を先へ延ばすのはやめます。終了した求人の扱いは、募集終了・期限切れ・再募集を管理する手順へ進んでください。

修正記録を残し、再確認する対象を決める

調査を終えたら、求人詳細URLと修正日時を記録します。同じ記録へ最終クロール日時、公開テストの結果、正規URL、構造化データのエラーを添えます。分からなかった項目は未確認のままにして、推測で正常と埋めないようにします。

技術的な検査が通っても掲載されない場合は、Search Consoleで手動による対策の有無を確認します。求人内容がGoogleのポリシーに合うかも見直してください。検査に合格したことと、検索結果に表示されることは別の判断です。

取得や登録を妨げていた設定を直し、公開テストで確認できたら、Search Consoleから再クロールをリクエストできます。ただし、同じURLへの繰り返し要求はクロールを早めません。登録や表示の時期も保証されないため、追加要求の回数ではなく、修正後のページをGoogleが取得したかを次の確認点にします。Googleの再クロールをリクエストする方法

求人の更新通知にはIndexing APIという仕組みもありますが、利用対象は限定されています。通常の解説記事まで対象に広げず、JobPostingを含む求人ページの更新手段として別に検討します。GoogleのIndexing APIの対象と始め方

原因を一度で言い切れなくても、取得、登録、求人情報のどこまで確認できたかが残れば、次の担当者はそこから調べられます。構造化データの出力から見直す必要がある場合は、WordPressでGoogleしごと検索に対応する方法で初期実装の手順を確認してください。