データベース型サイトのSEO完全ガイド｜4段階の判断基準

「ページは何万とあるのに、検索流入が増えない」「求人サイトの担当になったが、記事SEOのノウハウがどうも当てはまらない」——求人・EC・不動産といった大規模サイトの担当者から、私たちが最も多く受ける相談です。

その感覚に間違いはありません。データベース型サイトのSEO（DBSEO）は、記事を1本ずつ磨き込む通常のSEOとは別物で、サイトの構造そのものを設計する領域だからです。私はこれまで約20社のメディア改善に携わり、最大で月間4,500万セッション規模のサイト支援を経験し、現在も東証上場企業のデータベース型サイトのテクニカルSEOを担当しています。

この記事では、DBSEOの定義とコンテンツSEOとの違いから、成果を分ける「4段階の切り分けフレーム」までを整理します。そのうえで、一覧と詳細のどちらを受け皿にするかの決め方、絞り込みページとページ送りの扱い、正規URLが効かないときの見分け方、匿名化した実測データまでを1本にまとめました。読み終えたとき、「自社サイトはどの段階で詰まっていて、何から着手すべきか」をご自身の言葉で説明できるようになることが、この記事のゴールです。

先に結論：DBSEOは「記事を磨く」ではなく「構造を設計する」

まず最初に、結論からお伝えします。

1つ目。データベース型サイトの成果は、個別ページの品質ではなく「構造」で決まります。数万ページを1ページずつ直すことはできませんが、ページのひな型（テンプレート）と内部リンクの設計を変えれば、数千ページが一度に変わります。

2つ目。課題は「クロール→インデックス→PLP一致→順位」の4段階で切り分け、上流から直します。クロールされないページはインデックスされず、インデックスされないページに順位はつきません。

3つ目。最も多い失敗は、診断せずに「順位対策」から入ることです。私が見てきた支援の現場では、順位以前にクロールやインデックスの段階で詰まっているサイトが目立ちました。

いまの状況によって、読むべき章は変わります。次の表から自分に近い行へ進んでください。

いまの状況	まず読むべき章
これからDB型サイトを立ち上げる	キーワード戦略：面で取る市場設計
ページはあるのに流入が伸びない	成果を分ける4つの段階
想定と違うページが検索結果に出る	一覧ページと詳細ページ、どちらを受け皿にするか
絞り込みページを残すか外すかで迷っている	絞り込み（ファセット）とページ送りをどう扱うか
canonicalを入れたのに効いていない	正規URL（canonical）は「書いたつもり」で止まりやすい
外注・依頼先を検討している	内製か外注か：発注前チェックリスト
AI検索への影響が気になる	AI検索（LLMO）時代のDBSEO

データベース型SEO（DBSEO）とは

データベース型サイトとは、データベースから自動生成される大量のページを持つサイトのことです。DBSEOは、そのページ群をサイト全体の構造設計で評価させる領域を指します。範囲を曖昧にしたままだと、コンテンツSEOの手法をそのまま持ち込んで空振りしかねません。

• データベース型サイトとは何か
• どんなサイトが当てはまるか（求人・EC・不動産・比較）
• コンテンツSEOとどこが違うのか

データベース型サイトとは何か

データベースから自動生成される大量のページを持つサイトを「データベース型サイト」と呼びます。データベース型SEO（DBSEO）とは、こうしたサイトのページ群を、サイト全体の構造設計によって検索エンジンに正しく評価させるSEOの領域です。対象となるのは、求人サイト・不動産ポータル・ECサイト・店舗検索・比較サイトなど、「条件を選ぶとページが自動的に生成される」タイプのサイトで、ページ数は数千から、大手では数百万に達します。

構造は2層で考えると整理しやすくなります。条件で絞った結果を見せる「一覧ページ」と、1件ごとの情報を見せる「詳細ページ」です。この2層のどちらを検索の受け皿にするかが、あとになって成果を大きく分けます。

どんなサイトが当てはまるか（求人・EC・不動産・比較）

自社が当てはまるかどうかは、ページの作られ方で見分けられます。人が1ページずつ書いているなら記事サイト、データベースの1行がそのまま1ページになっているならデータベース型サイトです。求人サイトなら求人票、ECサイトなら商品、不動産ポータルなら物件、比較サイトならサービスが1行にあたります。

自社サイトのページの大半が「人が書いたページ」なら主戦場はコンテンツSEO、「データから自動生成されるページ」ならDBSEOです。両方を持つサイトは、どちらを主軸に置くかを先に決めます。

これから作る場合も、順番は同じです。どの条件の一覧ページを検索の入り口にするかを決め、次にページのひな型を設計し、最後にデータ入力のルールをそろえる——この順で作ると、公開後に直す量が減ります。

コンテンツSEOとどこが違うのか

同じ「SEO」という言葉で括られますが、記事を1本ずつ磨き込むコンテンツSEOとは、対象もスキルも成果の出方も根本的に異なるものです。

観点	コンテンツSEO	DBSEO
主戦場	記事単位の検索意図への一致	クロール・インデックスの構造的制御
改善の単位	1ページごとのリライト	テンプレート改善（数千ページに一括適用）
中核スキル	編集力	設計力・運用力
例えるなら	職人芸	都市計画
戦い方	個の戦い	群の統制

どちらが主戦場かを決めると、お金の置き場所も変わります。コンテンツSEOは人と編集に、DBSEOは開発とデータ整備に予算を寄せるのが基本の形です。

誤解されやすいのですが、DBSEOの本質は「大量のページをどう作るか」ではありません。「どのページだけを作り、どのページに評価を集めるか」を設計することです。ここを取り違えて「とにかくページを増やす」方向に走ると、後述するクロールの浪費と品質評価の低下を招き、むしろ逆効果になります。

成果を分ける4つの段階：どこで詰まっているかを先に知る

DBSEOの背骨になるのが、課題を4つの段階に切り分けるファネルの考え方です。検索流入は、次の4つの関門を順に通過してはじめて生まれます。自社サイトの症状と照らしながら見てください。

• 段階1 クロール：見に来てもらえているか
• 段階2 インデックス：登録されているか
• 段階3 PLP一致：狙ったページが受けているか
• 段階4 順位：勝てているか

段階	よくある症状	最初に確認するデータ
1. クロール	新しいページがいつまでも検索結果に出ない	Search Consoleのクロール統計とサイトマップ
2. インデックス	「クロール済み・未登録」が大量にある	インデックス作成レポートのステータス内訳
3. PLP一致	順位はあるのに想定と違うページが出る	主要キーワードの実際のランディングページ
4. 順位	狙ったページは出るが順位が低い	テンプレート単位の順位分布

この4段階の「どこで落ちているか」を先に確認してから、施策を選びます。

PLPはPreferred Landing Pageの略で、「このキーワードではこのページを出したい」という想定ページのことです。

大事なのは、各段階の「落ち率」を数字で確かめてから着手することです。感覚で「順位が低いから順位対策」と決めてしまうと、真因がクロールにある場合、下流の施策はすべて空振りします。

なお、大規模サイトのクロールについてはGoogle検索セントラルの「大規模なサイトの所有者向けのクロール バジェット管理ガイド」（2026年9月確認）が管理方法を解説しています。

クロールの割当（クロールバジェット）を意識すべきサイトは、次の3つです。

• 重複のないページが100万以上で、1週間に1回程度更新される
• 重複のないページが1万以上で、毎日更新される
• Search ConsoleでURLの大部分が「検出 – インデックス未登録」になる

このご相談は本当に多いのですが、DB型サイトでリライトが効くのは、4段階のうち下流（順位）だけが詰まっている場合です。私が関わった範囲では、流入が伸びないDB型サイトの多くで、それ以前のクロールかインデックスの段階に真因がありました。まず診断、施策はその後です。

段階1 クロール：見に来てもらえているか

最初の関門は、検索エンジンがページを見に来ているかどうかです。クロールで詰まる原因は、サイトマップの不備・内部リンクの欠落・不要URLへのクロールの浪費の3つに集約されます。

特に多いのが3つ目でした。絞り込みの組み合わせで無限に増えるURLに時間を使われると、本当に見てほしい詳細ページの巡回が後回しになります。

段階2 インデックス：登録されているか

見に来てもらえても、検索結果に登録されるとは限りません。インデックスで詰まる典型は、ページ同士の内容の重複と、情報量の薄い自動生成ページが多すぎることです。

「クロール済み・インデックス未登録」が大量に出ているときは、ページを足すより先に、減らす・まとめるという判断が要ります。

段階3 PLP一致：狙ったページが受けているか

登録されても、狙ったページが受けているとは限りません。一覧ページと詳細ページのテーマが曖昧だと、検索結果に出るページが想定とずれます。

この段階は症状が分かりにくく、順位表だけを見ていると気づけません。見分け方と直し方は、次の章で自社サイトでの実例とあわせて扱います。

段階4 順位：勝てているか

ここまで通過して、ようやく順位の話になります。順位段階の要因は、テンプレートの情報設計と、ドメイン全体の評価の2つです。

テンプレート単位で順位の分布を見ると、どのひな型が弱いのかが見えてきます。1ページずつではなく、ひな型ごとに直すのがDBSEOの進め方です。

段階	何を見るか	詰まっているときのサイン	次にすること
1. クロール	1日あたりのクロール数と、サイトマップの送信数に対する検出数	公開したページがいつまでも検出されない	不要URLへの巡回を減らし、内部リンクで導線を作る
2. インデックス	登録済みページ数と「クロール済み・未登録」の件数	未登録が増え続ける	重複と情報量の薄いページを減らし、登録対象を絞る
3. PLP一致	主要キーワードで実際に表示されているURL	一覧と詳細が入れ替わる・両方出る	受け皿を決め、内部リンクとテーマをそこへ寄せる
4. 順位	テンプレート単位の順位分布	特定のひな型だけ順位が低い	そのひな型の情報設計を直す

この4行を月に1回そろえて見るだけでも、施策の当たり外れはかなり減ります。指標を増やすより、段階ごとに1つずつ決めておくほうが運用は続きます。

一覧ページと詳細ページ、どちらを受け皿にするか

DB型サイトでつまずきやすいのが、一覧ページと詳細ページのどちらを検索の受け皿にするかという設計です。ここがずれると、順位はついているのに想定と違うページが出ます。

• 狙った詳細ページではなく一覧が受けていた実例
• 詳細ページが検索対象から外れる理由は「数えてから」決める
• 意味の近いページどうしがぶつかっているとき

狙った詳細ページではなく一覧が受けていた実例

当社が2026年7月に自社運営の比較サイトで行ったSearch Consoleのクエリ×ページの実測では、狙っていた詳細ページが検索語を受けていませんでした。受けていたのは、掲載企業名を含む検索語およそ10種について、31位の会社一覧ページと16位の絞り込み結果ページです。

原因は、一覧側が各件の紹介文を丸ごとページ内に抱えていたことです。一覧が詳細の内容をすべて持っていれば、検索エンジンから見て一覧のほうが答えとして十分に見えます。

ですから最初にやるのは、主要キーワードで実際に表示されているURLを確かめることです。受けているのが一覧なら、一覧を主役に据えて詳細を補助に回すほうが、早く結果につながる場合もあります。

実際に受けているページ	先にやること
一覧ページ	一覧を主役に据え、詳細は補助に回す
詳細ページ	詳細のテーマを強め、一覧からリンクを寄せる
両方が出ている	内容の重なりを減らし、受け皿を1つに決める

狙いと違うページが受けている状態を、PLP不一致と呼びます。その原因の1つが、自社のページ同士が同じ言葉で競合するカニバリゼーションです。

対処は、対象ページのテーマ性を強める（タイトル・見出し・コンテンツの一致度を上げる）ことと、競合してしまっている自社ページ側の評価を調整する（内部リンクの集約・ページの統合）ことの両輪で行います。片方だけでは効きにくい、というのが実務の感覚です。

「両方とも上位に出ているからOK」は放置の理由になりません。クリックと評価が分散して、どちらのページも伸び悩むのがカニバリの怖さです。サイト内部の施策全体の優先順位はSEOの内部対策で整理しました。

詳細ページが検索対象から外れる理由は「数えてから」決める

当社が2026年7月に自社運営の比較サイトで詳細ページ209件を点検した時点で、検索対象から外れていたのは10件でした。当初の仮説だった「地域が未入力」が当てはまったのは10件中2件で、主な原因は入力項目の少なさでした。

対処はコードの修正ではなくデータ入力で、該当は10件から9件、4件へと減っていきました。思い当たる原因のまま開発に依頼していたら、順番待ちの列に並んだうえで何も変わらなかったはずです。

読者の皆さんに持ち帰っていただきたいのは、原因を決める前に件数を数えるという順番です。数が分かれば、開発とデータ入力のどちらの問題なのかも同時に見えてきます。

意味の近いページどうしがぶつかっているとき

当社が2026年8月に自社メディアの直近28日のクエリ×ページを見た範囲で、同じ検索語に複数ページが当たっていたのは4件でした。いずれも、意味の近い内容をわざわざ別ページに分けていたことが原因です。

分けるか、まとめるかの判断基準は「読者が別々に探すかどうか」です。別々に探さない内容なら、1ページにまとめて評価を集めたほうが伸びやすくなります。

絞り込み（ファセット）とページ送りをどう扱うか

条件で絞り込むページと、何ページにも分かれる一覧。この2つはDB型サイト特有の論点で、扱いを決めないままだとURLだけが増えていきます。ここでは残す条件と、公式に示されている扱いを順に整理します。

• 絞り込みページは「残す条件」を先に決める
• Googleが示している絞り込みURLの扱い
• ページ送りで守る4つのこと

絞り込みページは「残す条件」を先に決める

絞り込みページは、全部を検索対象にするのでも全部を外すのでもありません。残す条件を先に決めておけば、あとは組み合わせが増えても迷わなくなります。判断の物差しは次の3点で十分です。

• その条件で検索している人が実際にいるか
• 表示できる件数が十分にあるか（数件しか出ないなら作らない）
• 他の絞り込みページと中身が重ならないか

3つとも「はい」なら、検索の受け皿として残す価値があります。1つでも「いいえ」があるなら、リンクを張らず、検索対象からも外す判断でよいはずです。

Googleが示している絞り込みURLの扱い

Google検索セントラルの「ファセット ナビゲーション URL のクロール管理」（2026年9月確認）は、推奨を2つの場合に分けて説明しています。「クロールさせる必要がない場合」と、「クロールさせ、インデックスに登録させる必要がある場合」です。条件が正反対なので、前のH3で残す・残さないを決めてから読んでください。

残さないと決めた絞り込みURL（クロールさせる必要がない場合）には、次の方法が挙げられています。

• robots.txt でそのURLのクロールを防ぐ
• rel=”canonical” で代表にしたいURLを指定する
• そのURLへのリンクに rel=”nofollow” を付ける
• 条件を「#」以降（URLフラグメント）で持たせる

4つ目の「#」だけは注意が必要です。原典は、Google検索が通常はクロールにもインデックス登録にもURLフラグメントを対応していないと説明しています。「#」に寄せた絞り込みページは検索結果にも載らないので、受け皿にしたくないページにだけ使う方法です。

残すと決めた絞り込みURL（クロールとインデックス登録をさせたい場合）には、次の2点が挙げられています。

• 条件の区切り文字は「&」を使い、カンマやセミコロンは避ける
• 該当する結果が出ない組み合わせは、そのURLのまま404を返す

404については、共通のエラーページへ転送しないことが条件です。単一ページのアプリ（SPA）では実装できない場合がある、という注記付きです。

ページ送りで守る4つのこと

ページ送り（ページネーション）については、Google検索セントラルの「ページ分け、段階的ページ読み込み、それらの Google 検索に対する影響」（2026年9月確認）が守るべき点を挙げています。

• 各ページをリンク（aタグのhref）で順に結ぶ
• 各ページに一意のURLを割り当てる
• 2ページ目以降の正規URLを1ページ目に向けない
• ページ番号を「#」で表現しない

2ページ目以降を1ページ目にまとめようとすると、そこから先の詳細ページへ向かう道が消えてしまいます。ページ送りは評価を集める仕組みではなく、奥のページへ入るための通路だと捉えると扱いを間違えません。

正規URL（canonical）は「書いたつもり」で止まりやすい

正規URL（canonical）は、同じ内容を持つ複数のURLのうち、どれを代表にするかを検索エンジンに伝える指定です。「入れたのに効かない」という相談が最も多い領域でもあります。

• canonicalはあくまで強いヒントにすぎない
• 画面を見ても分からない壊れ方がある
• 設定を見るのではなく、応答を測る

canonicalはあくまで強いヒントにすぎない

Google検索セントラルの「rel=”canonical” などを利用して正規ページを指定する方法」（2026年9月確認）には、正規化の指定は必須ではなく、指定がなくてもGoogleが自分で最適なURLを判断すると書かれています。

そのうえで rel=”canonical” は「強く示すシグナル」と位置づけられており、Googleが別のURLを選ぶこともあるのです。つまり、意図と違うURLが選ばれているときに疑うべきは、指定の書き方だけではありません。ページの中身が本当に同じなのか、内部リンクがどちらを向いているのかまで含めて見ます。

画面を見ても分からない壊れ方がある

当社が2026年7月に自社運営の比較サイトで本番環境の応答を実測した際には、絞り込みページの正規URLが、本番環境でだけ条件の並び順が違うURLになっていました。

ページタイトルは元の並び順のままだったので、画面を見ているかぎり異常には気づけません。開発環境で正しく動いていても、本番で同じとは限らない——この一件はそれを思い知らされた例でした。

設定を見るのではなく、応答を測る

当社が2026年7月に同じ比較サイトで、条件の並び順が違うURLを正しいURLへ転送する設定を入れたあとにHTTP応答を実測したときには、実際の応答が転送になっていませんでした。設定ファイルにどう書いてあるかと、サーバーが実際に何を返すかは別物です。

だから点検の対象は、設定画面ではなく応答そのものに置きます。転送されているつもりのURLに実際にアクセスするだけで、この種の見落としは見つけられます。

プロの判断基準：DBSEOでどこから着手するかの決め方

着手順は、この章の最後に挙げる3つの問いに順番に答えれば決まります。順番を決める物差しは社内の声の大きさではなく、上流から直すという原則です。

• 着手順を決める3つの問い

この4段階フレームは、DB型サイトだけの話ではありません。記事中心の当メディアでも、同じ構造で歩留まりが落ちることを実測で確認しています。

2026年5月10日から8月7日までの90日間に、公開済みの記事244本がどこまで到達したかを同じ考え方でファネルにしたのが、次の結果です。

もう1つ、自社データで裏付いた判断軸があります。2026年4月から7月にかけて公開本数を60本から220本へ3.67倍に増やしました。

しかし月間の表示回数は990回から3,019回へ3.05倍にとどまり、1本あたりの表示回数はむしろ16.50回から13.72回へと横ばい〜微減でした。ここでいう1本あたりの表示回数は、月間表示回数を月末時点の累積本数で割った値で、表示がゼロの記事も分母に含みます。

本数を増やすだけでは、1本あたりの評価は伸びないということです。DB型サイトの「ページを増やせば順位が上がるわけではない」という原則と、驚くほど同じ形をしています。

私が提案の場でクライアントに繰り返し伝えているのは、施策から入る前にまず診断するという順番です。「本数を増やす」「記事をリライトする」といった施策は、4段階のどこで止まっているかを数字で確認したあとに検討します。診断を飛ばして施策から入ると、真因が別の段階にあった場合、その投資はほぼ空振りに終わります。

これは自社ブログという1サイトの実測で、一部のクエリはデータが匿名化されて欠けたままです。表示がなかった記事が、そのままインデックスされていないとは限らない点にも注意してください。自社サイトがどうかは、同じ4段階をご自身のデータで測り直すのが近道です。

着手順を決める3つの問い

では、具体的にどこから着手するか。私は次の3つの問いに順番に答えて決めています。

• 上流（クロール・インデックス）に詰まりが残っていないか
• 直すのは1ページか、ひな型か（ひな型を優先する）
• 開発の順番待ちなしで動かせるか（データ入力や設定で済むか）

1つ目が「いいえ」なら、下流の施策はいったん止めるべきです。2つ目と3つ目は優先順位の話で、同じ効果が見込めるなら、ひな型に効くほうを・開発待ちなしで動かせるほうを先に選びます。

この3つで決めれば、順番を決めるのは社内の声の大きさではなく、効果の見込みと着手のしやすさです。説明もしやすく、途中で優先順位がひっくり返りにくくなります。

キーワード戦略：面で取る市場設計

ここからは、そもそもどの検索市場を狙うかという設計の話です。DB型サイトのキーワード戦略は、単一のビッグキーワードで戦うのではなく、「軸キーワード×修飾キーワード」の組み合わせで生まれる大量のロングテールを、面で取りに行くのが本質です。

• 太い言葉を正面から狙わない理由
• 3語から2語へ広げる考え方

例えば求人サイトなら「職種×勤務地」「職種×働き方」、不動産なら「エリア×間取り×条件」。組み合わせの1つひとつは検索数が小さくても、合計するとビッグキーワード単体を上回る市場になります。しかも条件が具体的な分、応募や問い合わせに近い検索意図を持っています。

どの組み合わせページを「作る」かは、データの裏づけで決めます。判断材料は、検索ボリューム（実需があるか）・自社データの在庫（その条件で十分な件数を表示できるか）・競合の供給状況の3点です。実需がない、あるいは検索結果が数件しか出ない条件ページは、「作らない」判断が正解になります。

太い言葉を正面から狙わない理由

当社が2026年8月に自社メディア112本を90日分のSearch Consoleデータで集計した結果では、狙った言葉で20位以内に入れたのは7本でした。7本はいずれも月間検索1,300回以下の言葉で、月間2,000回以上を狙った22本からは20位以内に入ったものが出ていません。ただしこれはドメインが新しく被リンク施策もしていない1サイトの実測で、公開からの日数が短い記事も多いため、評価が育ったサイトにそのまま当てはめることはできません。

それでも方向としては明確です。太い言葉を1本のページで取りにいくより、条件の組み合わせで生まれる細かい言葉を数で押さえるほうが、DB型サイトでは現実的な戦い方になります。

3語から2語へ広げる考え方

見極めの分かれ目は、3語目がデータベースの検索条件として使える言葉かどうかです。ここを取り違えると、投下した工数がそのまま無駄になります。

注意点は、3語から2語への波及がすべてのテーマで起きるわけではないことです。3語目が「年収」「勤務地」「特徴」のようにデータベースの検索条件として機能する領域では連動しやすい一方、2語の検索意図が「解説記事を読みたい」である場合、条件ページを無理に上げようとせず、記事コンテンツとDBページで役割分担します。この見極めを誤ると、検索意図のない条件ページの量産につながり、クロールの浪費と品質低下で逆効果になります。

内部リンクと一覧ページの設計：評価を集める都市計画

狙う市場を決めたら、次は評価をどのページに集めるかという設計です。DB型サイトの内部リンクは「張れば張るほど良い」ものではなく、主要な一覧ページに評価（リンクを通じて渡る評価）を集約しつつ、サイト全体の回遊性を保つ、意図を持った設計が必要です。都市計画で幹線道路と生活道路を分けるのと同じ発想だとイメージしてください。

• 流入を最大化したい一覧ページを先に決め、そこへリンクが集まる構造にする
• 詳細ページから親の一覧ページへ還流させる（パンくず・関連リンク）
• アンカーテキストにリンク先ページのキーワードを含める
• 主要ページへトップから浅い階層でたどり着けるようにする

• 全ページに同じリンク群を機械的に張る（評価が分散して薄まる）
• 「こちら」「詳細はこちら」のアンカーテキストで統一してしまう
• 関連性の低い自動リンクを大量に表示する
• noindexページへのリンクを大量に残す（評価の浪費）

順番も大切です。リンクを寄せる前に受け皿をどちらにするかを決めておかないと、せっかく集めた評価が想定と違うページに載ってしまいます。受け皿を決める、リンクを寄せる、という順で進めてください。

現場の実測データ：構造の改善はどこまで効くのか

ここからは、実際にどこまで変わるのかを、私が担当した案件の実測でお見せします。守秘義務があるため、社名と実数値は伏せています。

対象サイト	主な施策	結果
エリア特化型の転職サイト（DB型）	クロール改善・一覧ページのテーマ一致・不要ページの削除統合・詳細ページの情報拡充	市場全体が下落傾向のなか、半年でセッション約1.5倍。1位獲得比率+3pt（対象約9,000キーワード）
特定業界に特化した求人サイト（DB型）	同型のテクニカルSEO一式	下落トレンド下でセッション約1.2倍。1位獲得比率+1.7pt（対象約3,000キーワード）
ライフエンディング業界のDB型サイト（東証上場企業）	テクニカルSEOコンサルティング・開発チームとの協働運用	モニタリング対象カテゴリの1位獲得数が9倍
ECサイト（DB型・東証プライム上場企業）	テクニカルSEOコンサルティング	月間400万セッション規模の大規模サイトを継続支援中

※1〜3件目の数値は各案件の順位計測ツール・アクセス解析による実測（2024年時点の集計）。4件目（ECサイト）は2026年時点で継続支援中の実績です。市場環境・サイト規模により再現性は変わります。

1〜3件目に共通するのは、新しいページをほとんど足していないことです。既にあるページの「評価のされ方」を、クロールの整理・テーマ一致・内部リンクの再設計で変えたに過ぎません。DBSEOの成果は、コンテンツの追加投資よりも、いまある資産の構造改革から生まれることが多い——これが現場の実感です。

対象はいわゆる求人サイトに限りません。予約プラットフォーム型のサイトでのテクニカルSEO支援、大手の転職エージェントでのテクニカルSEOの業務設計と施策立案、新規に立ち上げるサイトでの公開前のサイト構成とSEO戦略の設計（IT・不動産の2業界）にも携わってきました。共通しているのは、データから自動生成されるページ群を抱えているという構造のほうです。

内製か外注か：費用・体制・期間の考え方と発注前チェックリスト

内製か外注かを分けるのは、担当者の頑張りではなく体制です。開発の改修枠を継続して確保できるかどうかが分かれ目で、ここではその判断材料を体制・費用・期間の3点からそろえます。

• 何にお金がかかるのか
• 社内で予算と人を確保するときの説明の順番
• 発注前チェックリスト10項目

DBSEOに求められるスキルセットは、コンテンツSEOとは別物です。URL・データ構造の設計力、テクニカルSEOの知識、そして開発・運用部門を巻き込むディレクション力です。

「SEO担当者が1人で頑張る」体制では構造的に進みにくい領域だと言えます。内製と外注の判断は、次の3軸で考えてください。

判断軸	内製が向く状態	外注が向く状態
開発リソース	SEO改修の実装枠を継続的に確保できる	開発の優先度がいつも後回しになる
専門人材	テクニカルSEOの経験者が社内にいる	コンテンツSEOの経験者しかいない
課題の状態	ボトルネックが特定できている	どこから手を付けるべきか診断から必要

また、大規模サイトの改善は「テンプレート改善 → データ入稿ルールの整備 → 部門横断の合意形成」の順で仕組み化するのが定石です。1ページずつ直す作業に人手を割くより、データ入力のルールを1つ直すほうが強いSEO施策になることも珍しくありません。

迷った場合の現実解は、診断と設計を外部に任せ、実装と日々の運用を社内に残すハイブリッドです。DBSEOの施策は自社のデータベース構造と開発フローに深く関わるため、すべてを丸投げすると社内に知見が残らず、契約終了と同時に改善も止まります。逆に、ボトルネックの診断と設計方針だけでも専門家の目を入れると、限られた開発リソースを正しい順番に投下しやすくなるでしょう。

何にお金がかかるのか

DBSEOの費用は、大きく3つに分かれます。開発（テンプレートやURLの改修）、データ整備（入力ルールの設計と入力そのもの）、分析（診断と効果検証）です。

見落とされやすいのはデータ整備でしょう。詳細ページが検索対象から外れていた原因が入力項目の少なさだったように、直す場所が開発ではなく入力側にあることは珍しくありません。開発費だけを見積もると、肝心の入力工数が予算から抜け落ちます。

金額はサイト規模と改修範囲で大きく変わるため、一律の相場は示せません。複数社の見積もりを比べるときは、診断・設計・実装・検証のどこまでが範囲に入っているかをそろえてから並べます。

社内で予算と人を確保するときの説明の順番

社内の合意は、施策の説明から入ると通りにくくなります。順番は、①いま4段階のどこで落ちているか、②そこを直すと何が増えるか、③そのために誰の工数が何か月必要か、の3つです。

①を数字で示せると、②の期待値も現実的な幅で語れます。時間軸の目安は、当社が担当した案件での体感として、クロールやインデックスの改善が数週間から数か月、ロングテールから親カテゴリへの波及が数か月から半年です。この幅を先に共有しておくと、途中で「まだ効果が出ない」と止まるリスクを下げられます。

開発チームの工数を取るときは、SEOの用語ではなく「どのひな型を、いつまでに、どう変えるか」で話すと合意が早くなります。相手が判断できる言葉に翻訳するのも、DBSEO担当者の仕事のうちです。

発注前チェックリスト10項目

外注する場合は、契約前に次の10項目を確認すると、施策の量産だけを提案する会社と、構造から直す会社を見分けられます。そのまま社内の比較検討資料にお使いください。

なお、この記事で紹介した考え方はどのDB型サイトにも共通ですが、具体的にどの施策をどの順番で打つかは、サイト構造・開発体制・競合状況に強く依存します。記事制作を含めた外注の考え方は記事制作の外注ガイドを、メディア戦略全体の設計はオウンドメディア完全ガイドをご覧ください。

AI検索（LLMO）時代のDBSEO：構造化データは効くのか

最後に、いま大規模サイトの担当者が無視できなくなっているAI検索（ChatGPT・Perplexity・GoogleのAIによる概要）への対応です。当社が2026年7月に自社メディアのGA4で確認した直近28日では、AIアシスタント経由は8セッションで、自然検索190セッションの約4%にあたりました。規模はまだ小さいものの、流入経路として数え始める時期に入っています。

DB型サイトにとって重要なのは、AIが情報を「構造」で理解するという点です。Google検索セントラルの「構造化データ マークアップとは」（2026年9月確認）は、構造化データ（ページ内容を機械が読める形式で示すマークアップ）をリッチリザルトの土台として説明しています。

AI検索での扱いまでは書かれていませんが、機械が読める形でデータを置くことは、AIに正確に読み取ってもらううえでも効くというのが当社の見立てです。求人・商品・施設のような定型データを大量に持つDB型サイトは、この点で記事サイトより有利な立場にあります。

• 構造化データを主要テンプレートに実装する（求人・商品・パンくず等）
• 「どの分野のデータベースか」をサイト名・カテゴリ名で一貫させる
• 集計データや相場情報など、AIが引用したくなる一次情報ページを持つ

ただし、「構造化データを入れればAIに引用される」という単純な関係ではありません。当社が2026年8月に、あるBtoB領域のキーワードで上位6ページのHTMLを取得して数えると、よくある質問の構造化データを実装していたのは1本でした。AIの要約に引用されていたのは、むしろ実装していないサイトのほうです。

この観測はDB型サイトを対象にしたものではないので、そのまま当てはめることはできません。それでも言えるのは、構造化データは引用の条件ではなく、自社のデータを誤解なく伝えるための土台だということです。実装は進めつつ、引用されるかどうかは中身で決まると考えておくほうが、判断を誤りません。

AI検索最適化（LLMO）の全体像はLLMOとは？企業がAIに引用されるための完全ガイドで、BtoB企業での優先度の考え方はBtoB企業のLLMO対策で解説しています。AI経由の流入を計測する設定はAI検索経由の流入をGA4で測定する方法に、自社がいまAIにどう引用されているかを知りたい場合は無料のAI検索引用診断にまとめています。

業種別・テーマ別に深掘りする

この記事で全体像をつかんだら、自社の業種・課題に合わせて各論へ進んでください。それぞれ「何が分かる記事か」を添えています。

• 求人サイトのSEO対策——大量の求人ページを成果に変える設計
• ECサイトのSEO対策——商品・カテゴリページ設計の勘所
• 不動産サイトのSEO対策——エリア×物件ページの設計
• 比較・ポータルサイトのSEO対策——大量ページとE-E-A-Tの両立
• SEOの内部対策——やるべき施策一覧と優先順位
• 構造化データとは——SEO・AI検索での効果と実装の基本
• AI検索（生成AI検索）とは——仕組みと企業が備えるべき対策

よくあるご質問

データベース型SEOとコンテンツSEOはどう違いますか？

データベース型SEOは、自動生成される大量のページをサイト構造の設計で評価させる手法です。1記事ずつ磨き込むコンテンツSEOとは対象もスキルも異なり、テンプレート改善など「数千ページに一括で効く施策」を優先します。

データベース型SEOの効果はどのくらいの期間で出ますか？

データベース型SEOの効果が出るまでの期間は、施策の階層によって幅があります。クロールやインデックスの改善は数週間から数ヶ月、ロングテールから親カテゴリへの波及は数ヶ月から半年が目安です。支援実績でも、テクニカル改善開始から半年でセッション約1.5倍という時間感覚でした。

データベース型のSEO対策として、ページ数を増やせば順位は上がりますか？

ページ数を増やしても、基本的に順位は上がりません。検索需要のないページの量産は、クロールの浪費とサイト全体の品質評価の低下を招き、むしろ逆効果です。「どのページを作り、どのページを作らないか」を設計することがデータベース型SEOの本質です。実際に当メディアでも公開本数を3.67倍に増やしましたが、1本あたりの月間表示回数はむしろ16.50回から13.72回へと微減しました。

小規模なサイトにもデータベース型SEOは必要ですか？

データベース型SEOが必要なのは、ページが自動生成される構造を持つサイトです。数十ページの記事型サイトであれば通常のコンテンツSEOが適しています。ただし、カニバリの解消や内部リンク設計といった考え方の一部は記事型サイトにも転用できます。

データベース型サイトにはどんな例がありますか？

データベース型サイトの例は、求人サイト・不動産ポータル・ECサイト・店舗検索・比較サイト・グルメ情報サイトなどです。共通点は、データベースの1行が1ページになり、条件を選ぶと一覧ページが自動的に生成されることです。ページ数は数千から、大手では数百万に達します。

絞り込み（ファセット）ページは検索に載せたほうがよいですか？

絞り込みページは条件を絞った結果を見せるページで、すべてを検索に載せる必要はありません。判断は、その条件に検索需要があるか・表示できる件数が十分か・他のページと中身が重ならないかの3点で決めます。3つのうち1つでも当てはまらない組み合わせは、サイト内からリンクを張らず、検索対象からも外すのが基本です。

まとめ：まずインデックスレポートを開く

最後に、この記事の要点を振り返りましょう。

• DB型サイトの成果は、個別ページではなくテンプレートと構造の設計で決まる
• 課題はクロール→インデックス→PLP一致→順位の4段階で切り分ける
• 上流が詰まったまま下流を磨かない（診断が先、施策は後）
• 一覧と詳細のどちらが受けているかを、実際のURLで確かめる
• 絞り込みページは需要・件数・重複の3点で残すかどうかを決める
• 正規URLは設定ではなく、実際の応答を測って確かめる
• 自社ブログの実測でも同じ4段階の歩留まりが確認でき、量より診断が優先される
• キーワードは軸×修飾のロングテールを面で取り、3語から2語へ波及させる
• AI検索時代は、構造化データと一次情報がDB型サイトの新しい武器になる

次の一歩としておすすめしたいのは、Google Search Consoleの「インデックス作成」メニューにある「ページ」レポート（旧カバレッジレポート）を開き、「クロール済み・インデックス未登録」の件数を確認することです。自社が4段階のどこで詰まっているかは、その1画面からかなりの精度で読み取れます。

そのうえで、今日から着手できることを3つ挙げます。時間が取れるものから1つ選んでください。

• 「クロール済み・インデックス未登録」の件数を記録する
• 主要キーワードで表示されているURLが一覧か詳細かを調べる
• 絞り込みページを書き出し、残す条件に合うものだけ選ぶ

そのうえで、自社だけでの切り分けが難しいと感じたら、現状のデータを拝見しながらボトルネックの特定をお手伝いします。下の窓口からお気軽にご相談ください。