求人は毎日入ってくるのに、自然検索からの流入はじわじわ減るばかり。転職サイトの運営を担当していると、そんな時期に心当たりがあるかもしれません。記事を増やしても、求人の件数を増やしても戻りません。原因を探っていくと、とうに掲載を終えた求人ページと、求人が1件も無い一覧ページが、検索エンジンから見たサイトの大部分を占めていた、ということがあります。
転職サイトのSEOに取り組む前の状況と掲載終了求人の増え方
この転職サイトは、ITエンジニアと営業職を中心に、首都圏と主要都市の中途採用の求人を載せている中規模のサイトです。運営会社の社員は五十名ほどで、そのうち自然検索を見ているのはWEBマーケティング担当の二名でした。掲載中の求人は常時一万五千件前後あり、毎月そのうちのかなりの数が入れ替わります。
ここで使う言葉を先にそろえておきます。求人詳細ページは、求人1件ごとの募集要項を載せたページのこと。一覧ページは、職種とエリアの組み合わせなどで求人を絞り込んだ結果を並べる、サイト内のページを指します。求人を出す企業が自社で持っている採用ページのことではありません。
この節では、掲載終了の求人ページがなぜ積み上がったのかを、求人の入れ替わり方と、運営の事情の両面から見ていきます。先に求人の動きを押さえたのは、ページが生まれて消える速さが分からないと、仕組みの規模感がつかめないからでした。調べると、根っこにあったのは、終わったページを誰も片づけない状態が何年も続いていたことでした。
求人の入れ替わりが速い転職サイトで起きていたこと
転職サイトの求人は、出版物のように一度出したら終わり、というものではありません。掲載企業は採用が決まれば募集を止め、条件を変えて出し直し、繁忙期には同じ職種を何件も並べます。この転職サイトでも、新しい求人が入るたびに求人詳細ページが1つ生まれ、掲載期間が過ぎると「この求人の掲載は終了しました」という表示に切り替わる作りでした。
求人がこれだけ動くのは、転職する人そのものが多いからでもあります。総務省統計局の労働力調査によると、2025年の転職者数は330万人。2021年の290万人から持ち直し、ここ数年は330万人前後で推移しています。
問題は、切り替わったあとのページがそのまま公開され続けていたことです。表示は変わっても、URLは残り、ステータスコードは正常を示す200を返し、サイトマップにも載ったまま。検索エンジンからすれば、中身の薄いページが毎月数千件ずつ増えていく状態でした。
一覧ページのほうも似たことが起きていました。職種とエリアとこだわり条件を掛け合わせた一覧ページは、条件の組み合わせの数だけ自動で作られます。ある時期に求人があった組み合わせでも、その求人が終わると0件になります。0件のまま「該当する求人はありません」と表示するページが、気づけば掲載中の求人より多くなっていました。
ページ整理が後回しになっていた運営の事情
片づけが進まなかったのは、担当者が怠けていたからではありません。この転職サイトでは、掲載企業の数と掲載求人数が営業成績の指標になっていて、ページを減らすことは、数字を減らすことと同じように受け止められていました。
システムの側にも事情がありました。求人の登録と掲載期間の管理は営業部門の業務システムにあり、公開サイトはそこからデータを受け取って表示するだけ。掲載が終わった求人をどう見せるかは、何年も前に決めた作りのまま、誰も持ち主がいない領域になっていたのです。
加えて、求人は掲載期間より早く埋まることがよくあります。採用が決まっても掲載企業から連絡が来なければ、サイトの上では募集中のまま。営業担当者が気づいたときに手で止める運用で、止め忘れもそれなりにありました。
ここで手が止まる気持ちは分かります。求人を減らせと言えば社内で角が立ち、システムを直すには開発の予定を押さえなければなりません。だからこそ、あとで触れるように、この転職サイトでは削る話から入らず、残す基準を先に決めるところから始めています。
掲載終了の求人ページが自然検索の流入を削っていた課題
流入が落ちた原因を、この転職サイトでは三方向から確かめました。検索から来た人がどのページに着地し、そのあと何をしたか。検索エンジンがサイトのどのページをインデックスに入れているか。そして、Googleしごと検索にどの求人が表示されているか。インデックスとは、検索エンジンが検索結果に出す候補として登録しているページの一覧のことです。
まず着地の行動から見たのは、数字として一番早く取れ、社内でも説明しやすいからです。続けてインデックスとGoogleしごと検索に目を移すと、着地で見えた問題が、サイト全体の評価と求人の露出の両方に広がっていたことが分かってきます。個別のページの問題ではなく、サイトの作りの問題だと判断できたのは、この三つを並べて見たからでした。
求人だけ見たい求職者が掲載終了の求人に着地して離れていく状態
検索から求人詳細ページに着地した人の行動を見ると、掲載終了のページに着地した人のほとんどが、ほかのページを見ずにサイトを離れていました。当然といえば当然です。職種名と勤務地で検索して、ようやく見つけた求人が「掲載は終了しました」の一行だけなら、戻るボタンを押すしかありません。
掲載終了のページには、関連する求人へのリンクも置かれていませんでした。似た職種や同じエリアの求人がサイトの中にいくらでもあるのに、そこへの道がありません。求職者は会員登録をしたいわけでも、サイトを探索したいわけでもなく、求人を見たいだけです。その目的に応えられないページが、検索結果の入口になっていたわけです。
離脱の多さは、検索エンジンにも伝わっているはずだと担当の二人は考えました。開いてすぐ検索結果へ戻られるページは、その検索語に役立っていないページです。そうしたページがサイトの大きな割合を占めれば、掲載中の求人まで巻き添えで評価を落としかねない、という見立てでした。
インデックスの大半を掲載終了ページと求人0件の一覧ページが占める状態
Google Search Consoleのページのインデックス登録のレポートを見ると、登録されているページの多くが、掲載終了の求人詳細ページと、求人0件の一覧ページでした。一方で、掲載中の新しい求人は「クロール済み – インデックス未登録」や「検出 – インデックス未登録」のまま止まっているものが目立ちます。
クロールの統計情報のレポートも確かめました。Googlebotがサイトを訪れる回数には限りがあり、その多くが、中身の変わらない掲載終了ページと0件の一覧ページに使われていました。新しい求人のページが見つけてもらえるまでに日数がかかり、見つかったころには募集が終わりかけています。転職サイトにとっては致命的な遅れです。
さらに、掲載終了のページのかなりの数がソフト404として報告されていました。ソフト404とは、ページが存在しないような中身なのに、正常を示す200を返しているページのことです。検索エンジンは、そうしたページを実質的に無いものとして扱います。表示を切り替えただけの対応では、何もしていないのとほとんど変わらなかったのです。
Search Console ヘルプの「ページのインデックス登録レポート」の解説です。ソフト404は、ページが登録されなかった理由の一つとしてこのレポートに並びます。ヘルプでは、実際に見つからないページには404を返し、URL 検査の公開テストで Google からの見え方を確かめる方法も案内しています。
Googleしごと検索に終了済みの求人が残り続けていた状態
Googleしごと検索は、Googleの検索結果に求人をまとめて表示する機能で、Googleのドキュメントでは「求人検索」と呼ばれています。求人詳細ページにJobPostingという構造化データを入れておくと、求人の職種や勤務地、雇用形態の情報を読み取って、専用の枠に表示してくれます。構造化データとは、ページの中身を検索エンジンが機械的に読める形で書き添えたデータのこと。この転職サイトの求人詳細ページにも、以前からJobPostingが入っていました。
ところが、掲載が終わったページにも、同じ構造化データが入ったままでした。そのため、Googleしごと検索には応募できない求人が表示され続けます。求職者がそこから来ても、応募はできないのです。これは流入の質を下げるだけでなく、求人を扱うサイトとしての信頼にも関わります。
Googleの求人情報の構造化データのドキュメントには、応募を受け付けていない求人は削除し、タイムリーな措置を講じないと手動による対策が必要になる場合があると書かれています。手動による対策とは、Googleの担当者がサイトの問題を確かめて、検索結果での扱いを制限する措置のこと。
掲載終了の求人の放置は、Googleしごと検索に出られなくなるおそれも抱えていたのです。
掲載終了の求人ページを仕分けた判断基準
課題が見えたあと、この転職サイトが最初にしたのは、ページを消すことではなく、残すものの基準を決めることでした。消す基準から話し始めると、営業部門は「うちの求人が減る」と受け止めます。残す基準から話せば、「残る理由がはっきりしているページだけを残す」という話になり、議論が数字の取り合いになりにくいのです。
もう一つ、最初に決めたことがあります。仕分けは人の目ではなく、システムが自動で当てはめられるルールにすること。求人は毎月入れ替わるので、一度の大掃除で終わらせても、半年もすれば元に戻ってしまいます。
判断材料には、求人詳細ページごとの過去の自然検索の流入、外部サイトからのリンクの有無、同じ企業の後継の求人があるかどうか、の三つを使いました。棚卸しをしてみると、掲載終了のページのうち、検索からの流入や外部からのリンクを持っていたのはごく一部で、大半はどちらも持っていません。残す理由を持つページは思っていたよりずっと少ない、というのが仕分けを通して分かったことでした。
削除とリダイレクトと掲載継続を分けた判断材料
仕分けの行き先は、ページを消して「もう存在しない」と伝える削除、後継の求人へ転送するリダイレクト、そしてページを残す掲載継続の三通り。どれに回すかは、次のように決めました。
| 行き先 | 対象にしたページ | ページの扱い |
|---|---|---|
| 掲載継続 | 直近の数か月で自然検索の流入があったページ、外部サイトからリンクされていたページ | 掲載を終えたことを上部に明記し、同じ職種と同じエリアで掲載中の求人を並べる。検索結果には出さず、一定期間を過ぎたら削除に回す |
| リダイレクト | 同じ企業の後継の求人があるページ | 後継の求人へ転送する |
| 削除 | 上のどちらにも当たらないページ | 掲載が終わった時点で削除する |
掲載継続といっても、求人として残すわけではありません。ブックマークやリンクから来た人の受け皿として、一定期間だけ置いておく扱いです。
検討の途中では、掲載終了のページをすべてトップページや一覧ページへリダイレクトする案も出ています。作業としては一番楽です。けれど、トップページに飛ばされた人は、探していた求人を見つけられません。中身の違うページへの大量の転送は、検索エンジンから見ても削除と変わらない扱いになりかねません。そう考えて、この案は見送りました。
同じ企業と同じ職種で後継の求人がある場合の扱い
リダイレクトの対象は、同じ掲載企業が、同じ職種で、同じ勤務地の求人を掲載しているときに限りました。条件を狭くしたのは、転送先が「探していた求人の続き」と読めるかどうかを基準にしたからです。
同じ企業でも職種が違えば、求職者にとっては別の求人です。営業職の求人を見に来た人がエンジニアの求人に飛ばされたら、戸惑うでしょう。勤務地が変わる場合も同じで、通えない場所の求人を見せられても困ります。後継の候補が複数あるときは、掲載を始めた日が最も新しいものを転送先にしました。
雇用形態が変わっている場合、たとえば正社員の募集が契約社員の募集に切り替わっている場合は、同じ職種でも転送しません。求職者にとって、雇用形態は給与と同じくらい大事な条件です。以前のページを見て来た人を、条件の違う求人へ黙って連れていくのは、誤解を生む見せ方になりかねません。そう判断して、削除側に回しました。
転送先が見つからない掲載終了ページも、削除したあとに何も出さないわけではありません。検索エンジンには削除を伝えつつ、開いた人には同じ職種とエリアの求人一覧への案内を表示します。検索エンジンへの伝え方と、人への見せ方を分けて考えたことが、あとの実装の土台になりました。
求人0件になった職種とエリアの一覧ページの扱い
一覧ページのほうは、求人詳細ページよりも判断が難しくなりました。職種とエリアの組み合わせは、求人が無くなっても、また入ってくる可能性があるからです。
そこで、0件の一覧ページを、一時的に0件のページと、構造的に0件のページに分けました。一時的に0件とは、過去に求人が継続して入っていて、検索からの表示もあった組み合わせのこと。構造的に0件とは、組み合わせとしては作られたものの、求人がほとんど入ったことがなく、検索されてもいない組み合わせのことです。
一時的に0件のページは、URLを残したまま、検索結果には出さない設定にしました。ページには近いエリアや近い職種の掲載中の求人を並べ、求人が入った時点で自動的に検索結果に戻す作りです。切り替えは、0件が一定期間続いたときだけにしました。出たり消えたりを細かく繰り返すと、検索エンジンの再評価が追いつかないと考えたからです。
構造的に0件のページは削除し、サイト内のリンクからも外しました。求人の無い組み合わせのページを自動で作る仕組みそのものも止め、求人が一定数そろった組み合わせだけ一覧ページを公開するように変えています。入口が生まれる元を絞ったことが、同じ状態に戻らないための要でした。
転職サイトのシステム側で進めた失効処理の実装
仕分けのルールが決まったら、それをシステムに落とし込む番です。この転職サイトで最初に直したのは、求人の状態を持つ場所でした。
それまでは、掲載中か終了かの判断が、ページの表示、サイトマップ、構造化データの出力で、それぞれ別々に行われていました。表示は掲載終了日を見て切り替わるのに、サイトマップは月に一度しか作り直されず、構造化データは掲載終了日を見ていませんでした。同じ求人について、ページごとに言っていることが違う状態です。
そこで、営業部門の業務システムから受け取る掲載終了日と、前の節で決めた仕分けの結果を、求人ごとの「掲載状態」という一つの値にまとめました。ステータスコード、検索結果に出すかどうかの指示、構造化データ、サイトマップ、そしてGoogleへの通知は、すべてこの値から決まります。
こうしておけば、どこかだけ古い情報が残ることは起きにくいはずです。
掲載終了時に返すステータスコードとnoindexの使い分け
ステータスコードは、サーバーがページを返すときに添える三桁の番号で、ページが正常にあるのか、移動したのか、もう無いのかを伝えます。noindexは、ページを検索結果に出さないよう検索エンジンに伝える指示。人には見せたいが、検索結果には出したくないページに向いています。仕分けの行き先ごとに、この二つを次のように組み合わせました。
| ページ | ステータスコード | 検索結果への出し方 |
|---|---|---|
| 掲載中の求人詳細ページ | 200（正常） | 出す |
| 削除に回した求人詳細ページ | 410（もう無い） | インデックスから外れる |
| 後継の求人がある求人詳細ページ | 301（恒久的な移動） | 後継の求人へ転送する |
| 掲載継続にした求人詳細ページ | 200（正常） | noindexで出さない |
| 一時的に0件の一覧ページ | 200（正常） | noindexで出さない |
404も410も、ページが無いことを示す番号です。Googleの説明では、429を除く400番台のステータスコードは同じように扱われ、インデックスから削除されるとされています。それでも410を選んだのは、意図して消したページとリンク切れを、社内のログで見分けるためでした。
ここで気をつけたのは、noindexのページをrobots.txtでクロール禁止にしないことでした。robots.txtは、検索エンジンのクローラーにどのページを訪れてよいかを伝えるファイルです。Googleのドキュメントには、robots.txtでブロックされているとクローラーがnoindexの指示を読めず、検索結果に残る可能性があると書かれています。クロールを減らしたくて両方を掛けると、指示が届かなくなるわけです。
JobPosting構造化データのvalidThroughと掲載終了の連動
JobPostingの構造化データには、validThroughという項目があります。求人の有効期限を書く項目で、Googleのドキュメントでは、求人に有効期限がある場合は必須とされています。この転職サイトでは、入稿された掲載終了日をそのままvalidThroughに入れるようにしました。以前は、この項目が空のまま出力されていたのです。
求人の終わり方は一通りではないので、場合ごとに扱いを分けています。
- 掲載終了日が決まっている求人
掲載終了日を、日本時間であることが分かるように時差を付けてvalidThroughに出力する - 期限前に採用が決まった求人
validThroughを待たずに掲載状態を終了に変え、ステータスコードと一緒に構造化データも外す - 掲載が延長された求人
validThroughを新しい日付に書き換える - 掲載期限を決めずに出す求人
validThroughは出力せず、掲載を続けるかを定期的に確かめる対象にする
期限前に採用が決まったら求人情報を削除すること、有効期限が無い場合や分からない場合は指定しないことは、どちらもGoogleのドキュメントに書かれている扱いです。時差を付けたのは、時差が無いと、掲載終了日の当日に応募できるのかどうかの扱いがあいまいになるからでした。
<!-- validThrough まわりの抜粋（title・description・hiringOrganization・jobLocation などの項目は省略） -->
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "JobPosting",
"datePosted": "2026-09-01",
"validThrough": "2026-10-31T23:59:59+09:00"
}
</script>Indexing APIとサイトマップで求人の削除を早く伝える仕組み
ページを正しく直しても、検索エンジンが訪れるまでは古い情報が残ります。そこで、変化をGoogleへ早く伝える仕組みを二つ組み合わせました。
一つがIndexing APIです。求人情報のページを追加・更新・削除したときに、サイトからGoogleへ直接知らせる仕組みで、JobPostingを含むページとライブ配信のページにしか使えません。この転職サイトでは、新しい求人が公開されたときと内容が変わったときに更新の通知を、ページを410に切り替えたときに削除の通知を送るようにしました。Googleのドキュメントでは、削除の通知を送る前に、そのURLが404か410を返すか、noindexが入っている状態にしておくことが求められています。そのため、通知はステータスコードを切り替えた後に送ります。既定の割り当てはテスト用の範囲にとどまるので、Googleへの承認と割り当ての申請も済ませました。
Google 検索セントラルの「Indexing API の使用」のページです。通知は更新（URL_UPDATED）と削除（URL_DELETED）の2種類で、1回のリクエストで送れる URL は1つ。送った通知の状態を後から取得する方法も、同じページに載っています。
もう一つがサイトマップです。Googleは、求人のURLにはサイトマップよりIndexing APIを勧めつつ、サイト全体をカバーするためにサイトマップも送ることを勧めています。この転職サイトでは、サイトマップを掲載中の求人詳細ページと一覧ページに分け、掲載状態が変わるたびに作り直すようにしました。分けておくと、Search Consoleで送信したURLと登録されたURLの差を、種類ごとに見比べられます。
掲載企業と営業部門を巻き込んだ入稿運用の見直し
システムをどれだけ整えても、元になる掲載終了日が正しく入っていなければ、失効処理は動きません。掲載終了のページが増えた根っこは、入稿のしかたにありました。そこに気づいてから、この転職サイトは営業部門と掲載企業を巻き込んだ話し合いに進みました。
営業部門へ最初に説明したのは、SEOの都合ではなく、求人を扱う事業者としての決まりでした。職業安定法の第五条の四は、求人の情報を提供する事業者に、情報を正確かつ最新の内容に保つための措置を求めています。その中身を定めた職業安定法施行規則の第四条の三第四項には、次の措置が並んでいます。
- 中止や訂正の求めへの対応（どの事業者にも必須）
情報の提供の中止や内容の訂正を求められたら、遅滞なく応じる - 正確でない・最新でない情報への対応（どの事業者にも必須）
そう分かったら、遅滞なく依頼主に訂正の有無を確かめるか、提供をやめる - 終了の通知の依頼か、時点の表示（どちらかを選ぶ）
掲載企業の依頼を受けて求人を載せる事業者は、募集が終わったり変わったりしたら知らせてもらうよう依頼するか、情報がいつ時点のものかを明らかにする
職業安定法の条文（e-Gov 法令検索）です。第五条の四は第一項で虚偽や誤解を生じさせる表示を禁じ、第三項で募集情報等提供事業を行う者などに、情報を正確かつ最新の内容に保つ措置を求めています。措置の中身は、別の法令である職業安定法施行規則の第四条の三に定められています。
このうち、どちらかを選ぶ最後の措置について、この転職サイトは、知らせてもらう依頼と、時点の表示の両方をとることにしました。流入のための整理が、そのまま決まりを守る運用にもつながるのです。この説明で、営業部門の受け止め方がはっきり変わったといいます。
掲載終了日を入稿時の必須項目にした経緯
それまで、掲載終了日は入稿画面の任意項目でした。空欄のまま入稿されると、求人は掲載期間の上限まで出続けます。まずこれを必須項目に変える案を出したところ、営業部門からは反対の声が上がりました。掲載企業は、いつ採用が決まるか分からないから求人を出しているのだ、という理屈です。
もっともな話です。そこで、必須にしたうえで「未定」も選べるようにし、未定を選んだ求人には、一定の期間ごとに掲載を続けるかどうかの確認が営業担当者と掲載企業の両方に届くようにしました。返事が無いまま期限を過ぎた求人は、自動で掲載終了に回ります。空欄で放置されることは無くなり、同時に、掲載企業に日付を無理に決めさせることも避けられました。
掲載企業の管理画面には「募集を終了する」ボタンを置き、採用が決まったらそこから知らせてもらうよう、掲載の案内に書き添えています。ボタンが押されると、掲載状態がその場で終了に変わり、前の節で触れたステータスコードの切り替えとGoogleへの削除の通知まで、一続きで流れる作りです。求人詳細ページには、情報がいつ時点のものかも表示するようにしました。
再掲載の求人でURLを使い回すかどうかの取り決め
入稿の運用でもう一つ決めておく必要があったのが、再掲載のときのURLです。終えた求人を同じ内容でまた出したい、という依頼はよくあります。そのとき、以前のURLを使い回すのか、新しいURLを発行するのか。
この転職サイトで決めた取り決めは、次のとおりです。
| 再掲載の求人 | URLの扱い |
|---|---|
| 同じ企業・同じ職種・同じ勤務地・同じ雇用形態で、掲載終了から間もなく再開する | 以前のURLを使い回す。ページを410から200に戻し、Indexing APIで更新を通知する |
| 給与や仕事内容が大きく変わる | 新しいURLを発行する |
| 内容は変わらないが、掲載日を新しく見せたい | URLだけ変えた出し直しは禁止 |
使い回しの利点は、外部サイトからのリンクや、求職者のブックマークがそのまま生きること。ただ、以前のURLに付いていた評価やリンクは、以前の求人内容に対するものです。中身の違う求人をそこに載せ替えると、以前のページを見て来た人に、別の求人を同じ求人のように見せることになってしまいます。
出し直しを禁じたのは、同じ求人のページが並べば、どれを検索結果に出すか検索エンジンも迷うからでした。掲載終了のページを増やすだけだ、と説明して、営業部門にも納得してもらっています。
整理後に転職サイトの自然検索流入が戻るまでの経過
ここからは、整理のあとに数字がどう動いたかを見ていきます。繰り返しになりますが、この記事はモデルケースで、以下の数値は、同じような整理をしたときの動きを示す一例です。
変化を見る指標は、整理を始める前に決めておきました。インデックスに登録されているページのうち、掲載中の求人と、求人の入った一覧ページが占める割合。新しい求人が登録されるまでの日数。求人詳細ページと一覧ページそれぞれの自然検索流入。そして、自然検索から来た人の応募数です。流入だけを追うと、整理の直後に数字が落ちたときに判断を誤るので、登録の中身と応募まで並べて見ることにしました。
実際、整理を始めてからしばらくは、流入がむしろ下がっています。消したページにも、わずかながら流入はあったからです。社内で「本当に戻るのか」という声が出たのもこの時期でした。そこで踏みとどまれたのは、登録の中身を示す指標が先に動いていたからです。
インデックス数とクロールの配分に表れた変化
最初に動いたのは、インデックスの中身でした。登録されているページの数は減りましたが、中身は大きく違います。掲載中の求人と求人の入った一覧ページが占める割合は、整理前の三割ほどから、八割を超えるところまで上がりました。
| 指標（一例） | 整理前 | 整理後 |
|---|---|---|
| インデックスに登録されているページの総数 | ― | 整理前のおよそ半分（整理を始めてから三か月ほど） |
| 登録のうち、掲載中の求人と求人の入った一覧ページの割合 | 三割ほど | 八割超 |
| 新しい求人が公開されてから登録されるまでの日数 | 一週間前後 | 二、三日ほど |
ソフト404として報告されていたページも、ほとんど見られなくなりました。クロールの統計情報を見ると、Googlebotの訪問は掲載中の求人詳細ページと一覧ページに多く向かうようになり、それが登録までの日数の短縮につながっています。求人の鮮度が勝負の転職サイトにとって、この短縮は流入以上に大きな意味を持つでしょう。
Search Console のクロールの統計情報は Google から見た集計なので、どの求人の URL に Googlebot が来て、どの番号を受け取ったかまで一件ずつ追うのは得意ではありません。転職サイトを WordPress で運営しているなら、このアクセスログのプラグインがその隙間を埋めます。URI・User-Agent・ステータスコードを記録し、ボットの判定とステータスコード別のグラフも備えているので、410 に切り替えた求人へのクロールが減っていくか、掲載中の求人に訪問が移っているかを、自分のサーバーの記録で確かめられます。
Googleしごと検索でも、終了済みの求人が表示される状態は解消しました。掲載状態が終了に変わった求人は、数日のうちにGoogleしごと検索からも外れるようになっています。
求人詳細ページと一覧ページの流入と応募数の一例
流入は、整理を始めてから三か月目あたりで下げ止まり、そこから上向きました。求人詳細ページの自然検索流入は、以前のいちばん多かった時期を百とすると、整理前には七十ほどまで落ちていました。それが整理の直後に六十台まで下がったあと、半年後には百を少し上回るところまで戻っています。
一覧ページのほうは、公開しているページの数を絞ったにもかかわらず、流入の合計は整理前を上回りました。0件のページに分散していた評価が、求人の入った一覧ページに集まったと見るのが自然でしょう。
応募数の動きは、流入よりも大きなものでした。自然検索から来た人の応募数は、半年後には整理前のおよそ一・四倍になっています。掲載中の求人に着地する人が増えたことと、Googleしごと検索に出る求人が応募できるものだけになったことが、流入以上に応募を押し上げたのでしょう。
掲載終了ページの整理で流入の回復に効いたこと
振り返ると、この転職サイトの回復は、個々の技術的な設定よりも、いくつかの判断の積み重ねで決まっていました。ステータスコードもnoindexもIndexing APIも、調べれば手順は分かります。それでも手が止まるのは、どのページをどう扱うかを社内で決めきれないときではないでしょうか。
この節では、流入が戻るまでに効いた判断と、同じ課題を抱える転職サイトがまず確かめたい数字を取り上げます。成果の数字を並べるより、判断の順番を残しておくほうが、別の転職サイトでも使いやすいからです。並べてみると、効いた判断はどれも技術そのものではなく、社内の誰が何を決めるかに関わるものでした。数字のほうも、開発に頼らず担当者が自分で取れるものに絞っています。
流入が戻るまでに要になった判断
私の立場から振り返ると、いちばん効いたのは、消す基準より先に残す基準を決めたことです。残す理由のあるページが先に決まっていれば、それ以外を削除に回すことに社内の抵抗が起きにくくなります。この順番を逆にしていたら、営業部門との話し合いはもっと長引いたはずです。
求人の状態を一つの値にまとめ、そこからステータスコード、検索結果への出し方、構造化データ、サイトマップ、Googleへの通知を決めるようにしたことも、同じくらい効いています。どれか一つだけ直しても、ほかが古いままなら、検索エンジンには矛盾した情報が届きます。
掲載終了日を入稿の必須項目にしたことは、再発を防ぐ役目を果たしました。システム側の片づけは、すでに生まれた掲載終了ページを処理するものでしかありません。入稿の段階で終わりの日が決まっていなければ、同じ状態はまた積み上がります。発生源を止めたことで、整理が一度きりの大掃除で終わらず、毎日の運用として続くようになりました。
同じ課題を抱える転職サイトで最初に確かめたい数字
同じような流入の落ち込みに心当たりがあるなら、まずは次の数字を並べてみてください。
- インデックスに登録されているページの数と、掲載中の求人の数
Search Consoleで見て、登録されているページが掲載中の求人よりずっと多いなら、掲載終了のページや0件の一覧ページが登録を占めている可能性があります - ソフト404として報告されているページの数
掲載終了の表示に切り替えただけのページが、ここに多く出ているはずです - 掲載終了からJobPostingが外れるまでの日数
掲載を終えた求人のページをいくつか選んで確かめると、Googleしごと検索に古い求人が残るおそれの大きさがつかめます - サイトマップに載っているURLの数と、掲載中の求人の数
合っていなければ、サイトマップの作り直しの頻度か、掲載状態の反映のどこかに穴があります
サイトマップと掲載中の求人の突き合わせは、一度やって終わりにすると、数か月後にまたずれます。このプラグインは、登録したサイトマップの件数を数え、中に載っている URL が生きているかを一件ずつ確かめ、その結果を決まった時刻にメールで届けます。転職サイト本体が別のシステムでも、サイトマップの URL を登録すれば確かめられるので、410 を返す求人がサイトマップに残っていないかを毎日の点検に組み込めます。
並べた数字の差が大きいところから手を付ければ、整理の順番も自然に決まってきます。
まとめ
転職サイトの自然検索の流入が落ちているとき、原因は記事や求人の少なさではなく、掲載を終えた求人ページと求人の無い一覧ページの積み上がりかもしれません。表示を「掲載終了」に切り替えただけでは、検索エンジンにはページが残っているように見え、Googleしごと検索にも応募できない求人が出続けます。
この転職サイトでは、残す基準を先に決め、削除とリダイレクトと掲載継続を自動で振り分けるルールを作りました。求人の状態を一つの値にまとめ、そこからステータスコード、noindex、validThrough、Indexing APIの通知、サイトマップが決まるように組み直しています。入稿では掲載終了日を必須にし、再掲載のURLの扱いも取り決めました。
まず確かめたいのは、インデックスに登録されているページの数と、掲載中の求人の数の差です。その差が、整理に取りかかる理由と規模をそのまま教えてくれます。
よくある質問
関連記事
