データベース型サイトのSEO完全ガイド｜テンプレート単位で数十万ページを動かす技術【2026年版】

求人、不動産、EC、店舗検索、比較ポータル——データベースからページを自動生成するサイトのSEOは、記事メディアのSEOとはまったく別の技術です。

記事SEOが「1本ずつ良いコンテンツを積む」ゲームなのに対し、データベース型サイトは数万〜数百万ページを1枚ずつ直すことが物理的に不可能です。その代わり、テンプレートを1本直せば数十万ページが同時に動きます。この非対称性を理解しているかどうかで、同じ工数をかけても成果が二桁変わります。

本記事は、月間数億PV規模のデータベース型サイトを事業側のSEO責任者として運用し、求人・転職・地図・ECのDB型サイトを支援してきた経験をもとに、クロール・インデックス・テンプレート・ページ生成・計測の5レイヤーで「何を・どの順に・どこまでの粒度でやるか」をまとめたものです。

一般的な解説記事のように「サイト構造を整えましょう」で終わらせず、実際に開発チケットへ落とせる粒度まで書きます。

まず、実例から:DB型サイトで実際に起きた変化

机上論ではないことを最初に示します。いずれも当社(および当社メンバー)が支援・運用したデータベース型サイトの実測値です。

共通しているのは、記事を大量に書いて伸ばしたわけではないという点です。やったのは、ページを生成する仕組みそのものの作り替えでした。クロールされていなかったページを通し、インデックスすべきでないページを閉じ、テンプレートを検索意図に合わせ直す。順序と粒度さえ間違えなければ、DB型サイトの改善は再現性が高い領域です。

1. データベース型サイトのSEOが「記事SEO」と別物である3つの理由

理由1:直す対象がページではなくテンプレート

記事メディアなら、順位が悪い記事はその記事をリライトすれば直ります。DB型サイトでは、1ページの不備は同じテンプレートで生成された全ページに等しく存在します。

裏を返せば、テンプレートのtitle生成ルールを1行変えるだけで、数十万ページのtitleが同時に変わる。これがDB型SEO最大のレバレッジであり、同時に最大の事故要因でもあります(誤った変更も同じ規模で波及します)。

理由2:クロールとインデックスが「全部は通らない」前提で設計する

Googleはサイトの規模や評価に応じて、クロールに割くリソースを調整します。数千ページ規模なら基本的に気にする必要はありませんが、数十万ページを超えたあたりから「重要なページにクローラーが到達しているか」自体が成果を左右する変数になります。

さらに、クロールされてもインデックスされるとは限りません。GoogleSearch Consoleで「クロール済み - インデックス未登録」「検出 - インデックス未登録」が数十万件積み上がっているサイトは珍しくなく、これはDB型に特有の症状です。

理由3:施策の出口が「原稿」ではなく「開発チケット」

記事SEOの成果物は原稿ですが、DB型SEOの成果物はほぼすべて実装依頼です。canonicalの出し分け、noindexの条件分岐、URL設計の変更、構造化データの実装——どれもエンジニアが手を動かさないと1ミリも動きません。

ここがDB型SEOで最も詰まるポイントです。「canonicalを正しく設定してください」という粒度の依頼は、開発チームにとっては着手不能です。詳しくは11章で扱いますが、施策を要件定義の粒度まで翻訳できるかが、実行フェーズの成否を決めます。

2. 思考の単位を「ページ」から「テンプレート」に変える

DB型サイトの改善で最初にやるべきは、サイトをテンプレート単位に分解し、それぞれの役割と枚数を数えることです。

求人サイトなら、たとえばこう分解できます。

この表を作るだけで、議論の質が変わります。「SEOを改善したい」ではなく「職種×地域テンプレートのtitle生成ルールと本文量を直せば、8,000ページが同時に動く」という具体的な打ち手に変換されるからです。

そして多くのDB型サイトでは、ページ数の8割以上を占めるテンプレート(上表なら求人詳細とこだわり条件)が、流入にほとんど貢献していないという状態になっています。この非対称性の把握が、すべての優先順位づけの出発点です。

3. 診断:5レイヤーで現状を測る

改善策を考える前に、症状を特定します。DB型サイトの診断は、以下の5レイヤーを上から順に見ます。上のレイヤーが壊れていると、下のレイヤーをどれだけ磨いても成果はゼロだからです。

1. クロール — そもそもGooglebotが到達・取得できているか
2. インデックス — 取得されたページが検索対象に登録されているか
3. テンプレート — 登録されたページが評価されるだけの中身を持っているか
4. ページ生成戦略 — そもそも生成しているページが、検索需要と噛み合っているか
5. 計測 — 上記の変化を、テンプレート単位で追えているか

レイヤー1の診断:クロールされているか

見るべき場所は3つです。

• Search Console > 設定 > クロールの統計情報:1日あたりのクロール数、レスポンスコードの内訳、平均応答時間。応答時間が1秒を大きく超えているとクロール数が抑制されます
• サーバーログ:Googlebotのアクセスを抽出し、どのテンプレートに何%のクロールが配分されているかを集計。これがDB型SEO診断で最も情報量の多い作業です
• site: 検索とサイトマップ送信数の乖離:サイトマップに10万URL送信して、インデックス済みが8千なら明確な異常

ログ分析で頻出するのは、クロールの大半がSEO上どうでもいいURLに吸われているというパターンです。並び替えパラメータ、ページネーションの深い階層、検索結果ページ、カレンダーの無限生成——ここに7割のクロールが流れていて、肝心の一覧ページが月に1度しか巡回されていない、という状態が実際にあります。

レイヤー2の診断:インデックスされているか

Search Consoleの「ページ」レポート(旧カバレッジ)を、テンプレート単位で見ます。

サイト全体の数字を見ても意味がありません。サイトマップをテンプレートごとに分割して送信すれば(例: sitemap-jobs.xml、sitemap-area.xml)、Search Consoleの「サイトマップ」からテンプレート別のインデックス率が読めるようになります。これは診断の解像度を上げる最も費用対効果の高い施策のひとつです。

見るべき除外理由と、その意味:

「クロール済み - インデックス未登録」が大量にある場合、それはクロールの問題ではなくテンプレートの中身の問題です。 ここを取り違えて「クロールバジェットを増やそう」と動くのが典型的な誤診です。

レイヤー3〜5の診断

• テンプレート: 各テンプレートの代表URLを5枚ずつ実際に見て、title・h1・本文量・独自情報の有無を確認。「地域名だけが違う同一文面」が並んでいたら赤信号
• ページ生成戦略: 生成しているURLの掛け合わせと、実際の検索需要(キーワードツールの実測volume)を突き合わせる。需要0の掛け合わせを10万ページ生成していないか
• 計測: テンプレート単位で流入・順位・インデックス率を追える状態か。追えていないなら、まずそこから作る

4. 施策レイヤー1:クロールを通す

診断で「重要ページにクローラーが到達していない」と分かった場合の打ち手です。

JavaScriptで生成したページが読まれているか

React/Vue/Next.jsなどで構築されたサイトで、クライアントサイドレンダリングのみの実装は、DB型SEOにおける最頻出かつ最重篤の症状です。

Googleはレンダリングを行いますが、それは初回HTML取得とは別キューで、遅延も制限もあります。当社が診断した荷物預かりプラットフォームでは、HTMLの段階で読み取れるコンテンツが全体の1割程度しかない状態でした。残り9割はレンダリング頼み——つまり、評価されるかどうかがGoogleの気分次第という状態です。

打ち手はSSR(サーバーサイドレンダリング)またはSSG/ISRへの移行です。判断基準はシンプルで、view-source: で見た生HTMLに主要コンテンツとリンクが含まれているか。含まれていなければ対応が必要です。方式の選び方と段階的な移行戦略は「JavaScript SEOとレンダリング方式の選び方」で扱っています。

無限スクロールは「リンクがない」から辿れない

一覧ページの無限スクロールは、UXとしては優れていてもクローラーには不可視です。スクロールで読み込まれるコンテンツにaタグのリンクが存在しない限り、Googlebotは2ページ目以降に到達できません。

打ち手は、無限スクロールを維持したうえで?page=2 形式のページネーションリンクをHTML内に併存させること。UXを壊さずクロール経路だけを確保できます。

robots.txt とサイトマップの設計

• ビルド生成物やAPIエンドポイントなど、クロールされても意味のないパスは Disallow で遮断する
• ただし、noindexにしたいURLをrobots.txtで遮断してはいけません。 ブロックするとGoogleはページを取得できず、noindexタグを読めないため、かえってインデックスに残り続けます。これはDB型サイトで頻発する事故です
• サイトマップは1ファイル50,000URL・50MBが上限。テンプレート単位で分割し、サイトマップインデックスでまとめる
• lastmod を正しく出力する。更新頻度の高いDB型サイトでは、鮮度シグナルとして実際に効きます

クロールバジェットの配分を変える

クロールバジェットは「増やす」よりも「配分を変える」ものだと考えたほうが実務に合います。パラメータURLやページネーション深部への浪費を止め、その分を主戦場のテンプレートに回す。診断手順・浪費の止め方・効果測定は「クロールバジェット最適化の実務」で詳しく解説しています。

5. 施策レイヤー2:インデックスを絞る

DB型サイトでは、インデックスさせるページを意図的に減らすことが増加施策になります。 薄いページが大量に存在すると、サイト全体の評価が押し下げられるためです。

ファセット(絞り込み)URLの爆発を止める

「職種×地域×こだわり条件×並び順×ページ番号」を自由に組み合わせられるUIは、組み合わせ爆発により無限に近いURLを生みます。これを放置すると、クロールは食い潰され、重複判定が積み上がります。

方針は、掛け合わせを3つの層に分類することです。

判断基準を「担当者の感覚」ではなく閾値にしておくのが重要です。たとえば「メインKWの月間検索volumeが10以上、かつ該当件数が5件以上ならインデックス許可」といったルールを決めれば、開発側で条件分岐として実装でき、以後は自動で正しく制御されます。

なお、Search Consoleの「パラメータ処理ツール」は廃止済みで、パラメータ制御はサイト側の実装(canonical・noindex・リンクの出し分け)で行う必要があります。

canonicalとnoindexの正しい使い分け

• canonical: 「同一・ほぼ同一の内容が複数URLにある」場合に正規版を示す。あくまでヒントであり、Googleが従わないことも普通にある
• noindex: 検索結果に出したくないページに使う。canonicalとの併用は矛盾したシグナルになるため避ける
• 並び替え・表示件数のパラメータ: 中身が同じならcanonicalで親を指す
• 絞り込み結果: 中身が異なるので、canonicalは自URLを指したうえで、育てる／閉じるを上記の閾値で判断する

「とりあえず全部canonicalで親に寄せる」は、絞り込み結果ページで需要があるものまで捨てることになり、DB型サイトでは機会損失が大きい選択です。閾値の決め方と実装手段の使い分けは「ファセットナビゲーションのSEO設計」で詳しく扱っています。

6. 施策レイヤー3:テンプレートを効かせる

クロールが通り、インデックスされるべきページが絞れたら、テンプレートの中身を作り込みます。ここが1本の改修で数十万ページが動くレバレッジの最大点です。

title・meta descriptionの動的生成ルール

全ページ共通の固定titleは論外として、「{地域}の{職種}求人」だけの機械的な生成も弱い。実務では、データの状態に応じて出し分けるルールを設計します。

# 生成ルールの例(求人一覧テンプレート)
件数 >= 50 : 「{地域}の{職種}求人{件数}件｜{最頻出こだわり条件}も検索できる｜{サイト名}」
件数 >= 5  : 「{地域}の{職種}求人{件数}件｜{サイト名}」
件数 <  5  : 一覧ページ自体をnoindex(薄いページを作らない)

件数のような動的な数値をtitleに入れると、鮮度と情報量が同時に上がります。ただしCTRの実測で検証してください——テンプレートの変更は全ページに波及するため、悪化した場合の被害も全ページ規模です。可能なら一部テンプレートで先行検証します。

一覧ページに「DBの出力以外」を足す

DB型サイトの一覧ページが弱いのは、ほぼ例外なくデータの羅列しかないからです。競合が同じデータソース(たとえば同じ求人ATS)を使っている場合、差がつくのは周辺の独自情報だけになります。

追加すべきは、その掛け合わせ固有の情報です。求人なら「その地域・職種の平均年収」「求人数の推移」「よくある応募条件」、不動産なら「その沿線の家賃相場と推移」など、DBから計算で出せる独自の集計値が費用対効果に優れます。手書きの紹介文を数万ページ分用意するのは現実的ではないので、まず計算で出せる情報から実装します。

構造化データ

DB型サイトは構造化データとの相性が非常に良い領域です。求人ならJobPosting、商品ならProduct、店舗ならLocalBusiness。テンプレートに1度実装すれば全ページに反映されるため、投資対効果が高い施策の筆頭です。

実装後はリッチリザルトテストとSearch Consoleの拡張レポートで、エラー率をテンプレート単位で監視します。

内部リンクで評価を集約する

DB型サイトの内部リンクは、UIの都合で作られていることが多く、SEO観点で設計されていないケースが大半です。設計の原則は3つ。

• 主戦場のテンプレートにリンクを集める(求人サイトなら職種×地域一覧)
• パンくずを階層通りに実装する(トップ > 職種 > 地域 > 詳細)。BreadcrumbList構造化データも併せて実装
• 詳細ページから一覧への還流を作る。求人詳細から「同じ地域の同じ職種の求人一覧」へ確実にリンクする。詳細ページは枚数が多いため、ここが最大のリンク供給源になります

診断手順やアンカーテキストの設計まで含めた詳細は「大規模サイトの内部リンク設計」で解説しています。

7. 施策レイヤー4:検索意図からページ生成を設計する

ここまでは「既にあるページをどう扱うか」でしたが、より上流に「そもそもどのページを生成するか」という論点があります。DB型サイトで最もインパクトが大きいのは、実はこのレイヤーです。

需要のある切り口でURLを切り出す

DBには複数の属性が入っています。求人なら職種・地域・雇用形態・年収・こだわり条件。この掛け合わせのうち、実際に検索されている組み合わせだけをURLとして切り出すのが理想形です。

手順は単純です。

1. キーワードツールで、自ジャンルの掛け合わせKWの実測volumeを網羅的に取得する
2. 現在生成しているURLパターンと突き合わせる
3. 「需要はあるがページがない」組み合わせ → 新規生成(最優先。取りこぼしの回収)
4. 「ページはあるが需要がない」組み合わせ → 閉じる、または内部リンクを出さない

3が最も効く施策です。当社が支援した求人サイトでも、伸びの主因は記事追加ではなく「需要のある掛け合わせページを新規に生成した」ことでした。

コンテンツがユーザーの探し方と一致しているか

もう1つ重要なのが、ユーザーの検索語とページの単位がズレていないかという観点です。

たとえば駅のコインロッカーを探すユーザーは「新宿駅 コインロッカー」で検索しますが、サイト側が「新宿駅の荷物預かりサービス一覧」の中の一要素としてコインロッカー情報を持っている場合、検索意図とページ単位が一致しません。この場合、コインロッカー情報を独立したURLとして切り出すだけで順位が動きます。

DBの構造(事業側の都合)とユーザーの検索単位(検索側の都合)は一致しないのが普通です。後者に合わせてURLを切り直すのが、DB型SEOの本質的な仕事のひとつです。

8. 施策レイヤー5:テンプレート単位で計測する

DB型サイトの効果測定は、サイト全体の折れ線グラフを見ていても何も分かりません。必要なのは以下です。

• サイトマップのテンプレート分割(3章)によるテンプレート別インデックス率
• Search Consoleの検索パフォーマンスをURLフィルタで分解。/jobs/ /area/ など、テンプレートのURLパターンごとに表示回数・クリック・平均順位を追う
• サーバーログのGooglebot集計を定点化。テンプレート別クロール配分の推移
• リリースと数値変化の対応表。どの改修がどのテンプレートに効いたかを記録する

テンプレート改修は影響範囲が広いため、何をいつ変えたかの記録がないと、後から効果を切り分けられません。リリース日を縦線で入れたグラフを標準の運用にすることを強く推奨します。

9. 優先順位:どの順にやるか

すべてを同時にはできません。インパクトと工数で並べると、標準的な順序は次のようになります。

1が壊れているサイトで3以降をやっても成果はゼロです。 逆に1が問題なければ、3と5から着手するのが最短距離になります。

10. よくある失敗

失敗1:症状の取り違え

前述のとおり、「クロール済み - インデックス未登録」はコンテンツの問題であり、クロールバジェットを増やしても解決しません。逆に「検出 - インデックス未登録」が大量ならクロール側の問題です。Search Consoleの除外理由を読まずに施策を決めない。 除外理由ごとの意味と対処は「ページがインデックスされない原因と対処」に一覧でまとめています。

失敗2:全ページ一括適用

テンプレート改修は数十万ページに一度に波及します。titleの生成ルール変更で全体のCTRが下がった場合、被害も全ページ規模です。可能な限り、影響の小さいテンプレートや一部カテゴリで先行検証してから展開します。

失敗3:robots.txtとnoindexの併用事故

繰り返しますが、robots.txtでブロックされたURLはnoindexタグを読まれません。「消したいのに消えない」の大半がこれです。消したいならクロールさせてnoindexを読ませる、が正解です。

失敗4:記事で解決しようとする

DB型サイトのSEOが伸びない相談の多くで、「コンテンツSEOの提案(月◯本の記事制作)」が既に走っています。しかしDB型サイトの流入の主戦場は一覧ページであり、記事はそこを補完するものであって代替にはなりません。テンプレートが壊れたまま記事を積んでも、投下コストに対する回収は見込めません。

11. 開発チームとどう進めるか

DB型SEOの実務で最大のボトルネックは、技術ではなくSEO側と開発側の翻訳です。ここは一般的なSEO記事がまず書かない領域ですが、実際に成果を左右します。

「canonicalを設定してください」では着手できない

開発チームが着手できる依頼は、最低限この粒度です。

【対象】/jobs/{職種}/{地域}/ テンプレート
【条件】クエリパラメータ sort / view / per_page のいずれかが付与されている場合
【実装】<link rel="canonical"> にパラメータを除去したURLを出力する
　　　　例: /jobs/sales/osaka/?sort=new → canonical: /jobs/sales/osaka/
【対象外】絞り込みパラメータ(experience / salary)は内容が変わるため、canonicalは自URL
【検証】上記4パターンのURLでcanonicalの出力を確認。ステージングで先行確認

対象・条件・実装・対象外・検証がそろって初めてチケットになります。「対象外」を書くことが特に重要で、これがないと開発側が善意で範囲を広げ、育てるべきページまで正規化されるという事故が起きます。

優先順位は「開発工数」と一緒に決める

SEO観点のインパクトだけで優先順位を作ると、実装に3ヶ月かかる施策が最上位に来て、実行が止まります。インパクトと開発工数の両方を並べ、開発チームと一緒に順序を決める。これができるかどうかで、施策が実装される速度が変わります。

工数見積もりのために、SEO側も対象テンプレートのコードと生成ロジックを読める状態にしておくのが理想です。当社がDB型SEOでエンジニア出身メンバーを必ず入れているのはこの理由です。

12. よくある質問(FAQ)

Q. データベース型サイトのSEOは、何から着手すべきですか? A. まずテンプレート一覧表(2章)を作り、次にクロール診断(3章)です。テンプレートごとのページ数・流入・インデックス率が並んだ時点で、どこがボトルネックかはほぼ自明になります。この2つは外部に頼まなくても社内で着手できます。

Q. ページ数は多いのに、ほとんどインデックスされません。原因は? A. Search Consoleの「ページ」レポートの除外理由で切り分けます。「検出 - インデックス未登録」が多ければクロール側(到達・バジェット配分)、「クロール済み - インデックス未登録」が多ければコンテンツ側(薄い・重複)の問題です。DB型サイトでは後者が圧倒的に多く、その場合の解は「テンプレートの中身を厚くする」か「そもそも生成をやめる」のどちらかです。

Q. 絞り込みページは、インデックスさせるべきですか? A. 一律の正解はなく、閾値で決めます(5章)。「検索需要が実測で存在し、かつ結果件数が十分」なものだけを許可し、それ以外は閉じるのが基本方針です。重要なのは、判断を感覚ではなくルールにして、開発側で条件分岐として実装できる形にすることです。

Q. SSR対応には大きな開発コストがかかります。本当に必要ですか? A. view-source: で主要コンテンツとリンクが見えているかを先に確認してください。見えているなら不要です。見えていない場合、検索流入を主要チャネルにする方針であれば投資回収は十分に見込めます。ただし全ページ一斉ではなく、流入の主戦場となるテンプレートから段階的に対応する進め方も可能です。

Q. 記事コンテンツ(コンテンツSEO)は必要ですか? A. DB型サイトの主戦場は一覧ページであり、記事は必須ではありません。まずテンプレート側の最適化で伸ばせる余地が大きいケースがほとんどです。記事が効くのは、DBでは答えられない検索意図(「営業職の志望動機の書き方」など)を拾い、そこから一覧ページへ内部リンクを供給する役割としてです。順番としては、テンプレート最適化が先です。

Q. 成果が出るまでどのくらいかかりますか? A. テンプレート改修は数十万ページに一度に波及するため、インデックス数やクロール配分の変化は数週間で表れることが多いです。順位・流入への反映はサイト規模とクロール頻度に依存し、3〜6ヶ月を目安に見ていただくケースが一般的です。

まとめ:DB型サイトSEOの設計図

1. サイトをテンプレート単位に分解する(2章) — すべての議論の土台
2. 5レイヤーで診断し、症状を特定する(3章) — 上のレイヤーから順に
3. クロールを通す(4章) — 壊れていれば他は全部無効
4. インデックスを意図的に絞る(5章) — 減らすことが増加施策になる
5. テンプレートを効かせる(6章) — 1本の改修で数十万ページ
6. 需要のある切り口でページを生成し直す(7章) — 最大の取りこぼし回収
7. テンプレート単位で計測する(8章) — 効果を切り分けられる状態を作る

データベース型サイトのSEOは、コンテンツの巧拙ではなく設計と実装の勝負です。設計を誤れば何十万ページあっても評価されず、正しく設計すればテンプレート1本の改修で数十万ページが同時に動きます。

自社サイトのどのテンプレートに何の症状があり、どこから手をつけるべきか——具体的な診断をご希望の方は、データベース型サイトSEOコンサルティングのページをご覧いただくか、無料相談をご利用ください。月間数億PV規模のDB型サイトを運用してきた知見をもとに、開発要件に落とせる粒度でご提案します。

株式会社ハウクレイジー 代表取締役 関口拓人

早稲田大学在学中に月間数千万PVのメディアをゼロから立ち上げ、株式会社ゲームエイトの創業に参画。同社執行役員として月間3億PV規模サイトのSEO・広告事業を統括。業界No.1プログラミングスクールを運営する株式会社インフラトップのCMOを経て独立し、株式会社ハウクレイジーを設立。大規模メディアからデータベース型サイトまで、累計50サイト以上のマーケティング支援を実施。

プロフィール詳細

テンプレート単位でどこを直せば全ページに効くのか。自社のページ構成を前提にした優先順位を、無料で整理してお渡しします。

無料でDB型サイトのSEO相談をする