データベースSEOコンサルティング例│看護師求人ポータルの改善

K社様は、病院・クリニック・介護施設などの看護師求人を掲載する求人ポータルサイトを運営しています。

都道府県、市区町村、雇用形態、施設形態、診療科目、こだわり条件など、複数の条件から求人を検索できるデータベース型のサイトです。

サイト内には多数の求人情報が登録されていましたが、検索条件から生成される一覧ページの多くがGoogleにインデックスされておらず、「市区町村＋看護師求人」「地域＋施設形態＋看護師求人」など、応募につながりやすいキーワードで十分な検索流入を獲得できていませんでした。

成果

市区町村ページへの内部リンクと、条件付き一覧ページのクロール・インデックス制御を見直したことで、
主要一覧ページのインデックス率は12％から96％まで改善しました。

また、検索キーワードに対して適切な一覧ページが表示されるPLP一致率も18％から91％へ上昇。
「市区町村＋看護師求人」を中心に、10位以内の市区町村関連キーワードは46キーワードから1,415キーワードまで増加しました。

支援前の課題

K社様のサイトには多数の看護師求人が登録されており、ユーザーは都道府県、市区町村、雇用形態、施設形態、診療科目などから求人を絞り込める仕様でした。

しかし、Googleにインデックスされているのは都道府県単位の一覧ページや一部の求人詳細ページが中心で、市区町村ごとの一覧ページはほとんど検索結果に表示されていませんでした。

原因の一つは、市区町村ページへたどる通常の内部リンクがなかったことです。
ユーザーが検索フォームを操作すると市区町村で絞り込めましたが、Googlebotがリンクをたどって各ページへ到達できる構造ではありませんでした。

また、複数の条件を組み合わせると大量のURLが生成され、同じ求人が並ぶ類似ページが増えていました。
たとえば、条件の並び順やパラメータの違いだけで、内容がほぼ同じURLが複数存在する状態です。

そのため、検索結果に表示させる必要のない、ページのクロール・インデックスをコントロールする必要がありました。

提案・実施内容

1．検索需要と求人件数を基準にインデックス対象を定義

まず、生成できるすべての条件ページを検索対象にするのではなく、どのページをGoogleに評価させるかを定義しました。

判断基準として、主に次の項目を使用しています。

・検索需要があるか
・十分な求人件数があるか
・他の一覧ページと異なる求人が表示されるか
・継続的に求人を掲載できるか
・応募につながる条件か
・地域や職種の検索意図と一致しているか

都道府県、市区町村、主要な施設形態、雇用形態など、検索需要があり求人件数も確保できるページをインデックス対象としました。

一方、求人件数が極端に少ない条件や、検索需要がほとんどない細かな組み合わせは、noindexの対象にしています。

2．市区町村ページへクロールできる内部リンクを設置

ユーザーの検索操作に依存していた地域ページを、Googlebotが通常のリンクから発見できる構造へ変更しました。

都道府県ページから市区町村ページへ、市区町村ページから主要な施設形態や雇用形態のページへ移動できる階層を設計しています。

あわせて、パンくずリスト、フッター、関連地域、近隣エリアへの内部リンクも整備しました。

検索エンジンがJavaScriptやフォーム操作に依存せず、重要な一覧ページへ継続的に到達できる状態を作りました。

3．条件付きURLのクロール・インデックス制御を実施

絞り込み条件を増やすほど、データベース型サイトでは大量のURLが生成されます。そこで、条件の種類ごとに以下を使い分けました。
・インデックスさせる静的URL
・canonicalで代表ページへ集約するURL
・noindexを設定するURL
また、条件の並び順が違うだけのURLや、同じ内容を返すパラメータURLを統一しました。

上記を実装することで重複ページへのクロールを減らし、市区町村や主要条件の一覧ページへクロールリソースを集中させています。

4．検索キーワードとPLPの一致率を改善

各キーワードで、どの一覧ページを検索結果に表示させるべきかを整理しました。

たとえば、次のようにページの役割を定義しています。
「東京都 看護師求人」：東京都の求人一覧
「新宿区 看護師求人」：新宿区の求人一覧
「新宿区 クリニック 看護師求人」：新宿区のクリニック求人一覧
「東京都 看護師求人 パート」：東京都のパート求人一覧

PLPの一致率を高めるため、インデックス対象となる各ページに内部リンクを集めたり、条件付きページよりもコンテンツを充実させるなど行いました。
検索条件がページ上に反映されず、広すぎる一覧が表示される状態を解消したこともあり、検索キーワードとランディングページの一致率が改善しました。

5．求人件数が少ないページの品質を制御

求人データベースでは、求人が一時的に減ることで一覧ページの品質が低下することがあります。

そこで、求人件数に応じてページの扱いを切り替えるルールを設計しました。

一定件数以上の求人があるページはインデックス対象とし、件数が基準を下回った場合は、近隣地域や上位カテゴリへの誘導を表示します。
求人が0件になった場合も、空の一覧ページをそのまま検索結果に残さず、再掲載の可能性や検索需要に応じて、noindexを付与しました。

成果につながった理由

成果につながった理由は、検索キーワードごとに必要な求人一覧ページを定義し、そのページをGoogleが発見・評価できる構造へ変更したことです。

施策前は、条件なしの求人一覧ページのみが検索対象となっており、市区町村で絞り込んだページは独立したページとして評価されない設計でした。

さらに、市区町村ページへの内部リンクもなかったため、「市区町村＋看護師求人」で上位表示させたいページをGoogleが十分にクロールできていませんでした。

そこで、検索需要と求人件数をもとに、インデックスさせる市区町村ページを選定。各ページに固有のURLを設け、都道府県ページなどから内部リンクを設置しました。

一方で、検索需要の乏しい細かな条件ページや、内容が重複するURLは検索対象から外しています。

その結果、「市区町村＋看護師求人」に対して、その地域の求人だけを掲載した一覧ページが検索結果に表示されるようになり、インデックス率と順位が改善しました。。

導入経緯

K社様は、市区町村ページがインデックスされない原因や、条件付き一覧ページをどこまで検索対象にすべきか判断できず、複数のSEO会社へ相談されていました。

各社から提案を受ける中で、当社は一部のページだけを見るのではなく、URLの生成ルール、内部リンク、インデックス状況、重複ページ、PLPのずれまで細かく調査しました。

そのうえで、「なぜ重要な市区町村ページが評価されず、不要な条件ページがクロールされているのか」を一つずつ整理し、改善の優先順位と実装方法をご説明しました。
これまで曖昧だった課題の原因が明確になり、「何から手を付ければよいかがすっきりした」とご評価いただいたことが、契約の決め手となりました。

お客様インタビュー

――今回の施策は、クライアント様の開発チームとどのように進めたのでしょうか？
K社様：当社の開発チームと、清水さんが直接やり取りしながら進めました。
今回は、URLの生成ルールや内部リンク、インデックス制御など、サイトの仕組みに関わる施策が中心でした。
そのため、SEO担当から開発チームへ指示書を渡すだけではなく、打ち合わせの段階から開発担当者にも参加してもらいました。
清水：データベース型サイトの改善では、SEO上の理想だけを伝えても、そのまま実装できるとは限りません。
既存システムの仕様や求人データの持ち方、運用方法によって、実現できる方法が変わります。今回は、K社様の開発チームに現在の仕組みを説明していただきながら、現実的な実装方法を一緒に検討しました。

――特に慎重に進めた施策はありますか？
清水：市区町村ページのURL設計と、条件付きページのインデックス制御です。
一度実装すると、多数の求人一覧ページに影響します。仕様に抜けがある状態で開発を進めてしまうと、公開後に修正が必要になり、その分だけ追加のコストと時間がかかります。
そのため、工数の大きい施策については、実装を依頼する前に仕様書を作成しました。
どの条件をインデックス対象にするのか、どのURLを生成するのか、求人件数が少なくなった場合はどう扱うのか、既存URLからどこへ転送するのかなど、想定されるパターンを事前に整理しています。

K社様：実装後に「やはりこの仕様では問題があるので、作り直してください」となるのが一番避けたいところでした。
今回は、清水さんが例外ケースまで仕様書にまとめてくれたので、開発チームも必要な工数や影響範囲を把握したうえで着手できました。

――仕様書を渡すだけではなく、打ち合わせも行ったのでしょうか？
K社様：はい。仕様書を共有した後、開発チームを交えて内容を確認しました。
資料だけでは判断しにくい部分については、清水さんから画面やURLの例を使って説明してもらいました。開発側からも「この条件ではどうしますか」「求人が0件になった場合はどうしますか」といった質問が出て、その場で仕様を詰めていきました。

清水：仕様書を細かく作っても、書面だけでは解釈が分かれることがあります。
特に、インデックス対象とする条件の境界や、既存機能への影響は、開発担当者と会話しないと見えてこない部分があります。
そこで、仕様書を完成品として渡すのではなく、打ち合わせで認識を合わせるための土台として使いました。

――施策の必要性も、開発チームへ説明したのでしょうか？
清水：そこは特に重視しました。
「このURLにcanonicalを設定してください」「ここへ内部リンクを追加してください」という指示だけでは、開発チームにとっては作業項目の一つにしか見えません。
なぜ市区町村ページを独立させる必要があるのか、なぜすべての絞り込みページをインデックスさせてはいけないのか、
なぜ条件なしの一覧ページだけでは検索ニーズを満たせないのかまで説明しました。
目的を理解してもらえれば、細かな仕様に変更が必要になった場合でも、SEO上の意図を理解した状態で判断してもらえます。

K社様：以前は、開発チームにSEOの修正依頼を出しても、「なぜ必要なのか分からないが、依頼されたので対応する」という状態になりがちでした。
今回は、清水さんが検索結果や実際のページを見せながら説明してくれたので、開発側も施策の目的を理解していました。

――開発チームが施策の目的を理解したことで、変化はありましたか？
K社様：開発チームから改善案が出るようになりました。
例えば、市区町村ページへ内部リンクを設置する話をしていたとき、開発担当者から「既存の地域データを使えば、近隣市区町村へのリンクも自動で表示できる」という提案がありました。
また、求人件数によってインデックス対象を切り替える仕様についても、「管理画面に件数の基準を設定できるようにすれば、今後ほかの職種にも展開できる」というアイデアが出ました。

清水：こちらでは把握できないシステムの機能やデータもあります。
施策の目的を共有したことで、開発チームの皆さんから「それを実現したいのであれば、既存のこの機能を活用できます」と提案していただけるようになりました。
SEO会社が一方的に指示するよりも、実装方法の選択肢が増え、より運用しやすい仕組みにできたと思います。

――意見が分かれることはありませんでしたか？
K社様：ありました。特に、どの条件ページまでインデックスさせるかについては何度も話し合いました。
SEOの視点では検索需要のあるページを増やしたい一方、開発側としては、条件を増やすほど仕様や保守が複雑になります。

清水：そこで、最初からすべての条件を実装するのではなく、検索需要と求人件数が安定している市区町村ページを優先しました。
その後、インデックス状況や順位を確認しながら、施設形態や雇用形態との組み合わせへ段階的に広げる方針にしています。
理想の完成形を一度に作るのではなく、効果と開発工数を見ながら優先順位を決めました。

――実装後の確認はどのように行いましたか？
清水：公開された画面を見るだけではなく、URL、HTML、canonical、noindex、内部リンク、XMLサイトマップなどを確認しました。
市区町村ページが正しいURLで生成されているか、条件なしのページへ誤ってcanonicalが向いていないか、インデックス対象外の条件ページがサイトマップに含まれていないかなど、仕様書と照らし合わせて検証しています。
問題があった場合も、単に「修正してください」と返すのではなく、どの仕様と異なり、検索エンジンにどのような影響があるのかを伝えました。

K社様：開発チームとしても、指摘の理由が分かるので修正しやすかったと思います。
実装、確認、修正のやり取りが感覚的にならず、仕様書を基準に進められた点が良かったです。

――今回の進め方で、特に良かった点を教えてください。
K社様：SEO会社と開発チームが、発注側と作業側という関係ではなく、一緒にサイトを改善するチームとして動けたことです。
清水さんは、完成した指示書を渡して終わりではありませんでした。実装前の打ち合わせ、仕様の調整、公開後の確認まで参加してくれました。
その結果、開発チームも施策の背景を理解し、自分たちから改善案を出してくれるようになりました。

清水：データベースSEOは、SEO会社だけでも、開発チームだけでも進めにくい領域です。
私たちが検索需要やインデックス設計を整理し、K社様の開発チームがシステムに合った実装方法を提案することで、SEO効果だけでなく、今後の運用や横展開まで考えた仕組みにできました。
やり直しを防ぐために慎重に進めながらも、途中からは開発チームから新しいアイデアが出るようになり、非常に良い形でプロジェクトを進められたと感じています。