更新日: 2026.09.24

ECサイトや求人サイト、不動産検索サイトなど、データベースから多数のページを生成するサイトでは、記事コンテンツとは異なるSEO課題が発生します。
「ページ数は多いのに検索流入が伸びない」「インデックスされていないURLが大量にある」「狙っている一覧ページとは別のページが検索結果に表示される」といった状況です。
これらは、個別ページの文章を書き直すだけでは解決できません。データベース型サイトでは、同じテンプレートから数千、数万ページが自動的に生成されるためです。
1ページずつではなく、どのURLをSEO対象とするのか、どのテンプレートを改善するのかという単位で考える必要があります。
本記事では、SEO対象URLの選別から、クロール・インデックスの制御、ページ設計、テンプレート改善、UI/UX改善までを、実務で進める順番に沿って解説します。
目次
データベース型サイトのSEOとは、商品や求人、物件などのデータをもとに自動生成されるページに対して、検索エンジンが適切にクロール・インデックスできる環境を整え、検索流入の獲得につなげるためのSEO対策です。
ECサイトや求人サイト、不動産検索サイトなどでは、数千~数十万ページが同じ仕組みやテンプレートから生成されるケースも珍しくありません。そのため、一般的な記事コンテンツのSEOとは異なり、1ページずつ改善するのではなく、URLの生成ルールやサイト構造、一覧・詳細ページのテンプレートなどをまとめて見直すことが重要になります。
まずは、データベース型サイトがどのような仕組みで構成されているのか、一般的な記事型サイトとの違いも含めて確認していきましょう。
データベース型サイトとは、あらかじめ蓄積された情報をもとに、ユーザーが選択した条件やページの種類に応じてコンテンツを表示するサイトです。
代表的なものとして、ECサイト、求人検索サイト、不動産検索サイト、中古車検索サイト、旅行・予約サイト、店舗・口コミサイト、商品・サービスの比較サイトなどがあります。
たとえば中古車検索サイトであれば、「メーカー」「車種」「価格」「年式」「走行距離」「販売地域」などの情報がデータベースに登録されています。
これらの情報をもとに、メーカー別・車種別・地域別の一覧ページや、「地域×車種」のような掛け合わせ一覧、個別の車両詳細ページなどが生成されます。さらに、価格帯や年式などを指定すれば、ユーザー向けの絞り込み結果も表示されます。

このように多数のページを効率的に生成できることがデータベース型サイトの特徴です。
一方で、生成できるすべての条件をURLとして持たせてしまうと、検索需要がほとんどないページや、内容がほぼ同じページまで大量に生まれる可能性があります。
そのため、「生成できるURL」と「SEO対象とするURL」を分けて考える必要があります。
記事型サイトとデータベース型サイトでは、SEOで改善する対象が異なります。
| 観点 | 記事型サイト | データベース型サイト |
|---|---|---|
| ページ生成 | 人が1ページずつ作成 | データと条件の組み合わせで自動生成 |
| 改善単位 | 個別ページ | ページタイプ(テンプレート)単位 |
| コンテンツの源泉 | 執筆内容 | 掲載データの量・鮮度・項目の充実度 |
| URL数 | 管理可能な範囲 | 条件の組み合わせで際限なく増えやすい |
| 主な課題 | 独自性、網羅性 | URLの重複、クロール・インデックス、テンプレートの薄さ |
| 成果地点 | 記事の閲覧・回遊 | 一覧で比較し、詳細を見てCVへ進む |
記事型サイトでは、「検索ユーザーが知りたい情報をどのように記事へ盛り込むか」という改善が中心です。
一方、データベース型サイトでは、どの条件でURLを生成するのか、どのページを検索結果に表示させるのか、一覧・詳細ページにどの情報を掲載するのかといった、サイト全体の設計が重要になります。
文章を書き足すことよりも、仕組みを整えることが成果に直結する点が大きな違いです。
課題が生まれる背景は、大きく2つあります。
1つは、条件の組み合わせによってURLが増えやすいことです。
エリア・カテゴリ・価格帯・並び順などを自由に組み合わせられる場合、条件ごとに異なるURLが生成されます。条件の順序が違うだけで、内容がほぼ同じ別URLが作られることもあります。こうしたURLが大量に存在すると、重要度の低いURLまで検索エンジンに発見・クロールされ、本当に評価してほしいページの発見や再クロールを妨げる可能性があります。
もう1つは、テンプレートの問題が多数のページへ一括して影響することです。
たとえば一覧ページのタイトル生成ルールに問題があれば、同じテンプレートを利用するすべてのページで同じ問題が発生します。反対に、テンプレートを適切に改善できれば、その効果も多数のページへまとめて反映されます。
つまり、問題も改善もページ単位では完結しません。検索流入が伸びない原因を探すときは、個別ページの順位だけを見るのではなく、URLの生成ルールから順に確認していく必要があります。
具体的な施策へ進む前に、データベース型サイトのSEOで特に重要となる考え方を3つに整理します。
いずれも「ページを増やす」ための考え方ではなく、「どのページに検索エンジンとユーザーの評価を集めるか」を決めるための考え方です。
データベースから生成できるすべてのURLを、検索結果に表示させる必要はありません。
検索需要があり、ユーザーに十分な情報を提供できるページはSEO対象とします。
一方で、並び替え結果や細かすぎる絞り込み条件などは、ユーザーには必要でもSEO対象にする必要がない場合があります。さらに、条件の順序違いや計測パラメータなど、そもそも生成やクロールを抑えた方がよいURLもあります。
まずは、SEO流入を獲得するページと、ユーザー向けの機能として利用するページを分けて考えることが出発点になります。
次に、どのキーワードでどのページを検索結果に表示させたいのかを整理します。
本記事では、検索キーワードに対して優先的に表示させたいページをPLP(Preferred Landing Page)と呼びます。
たとえば、「地域名+中古車」という検索であれば地域別一覧、「車種名+中古車」であれば車種別一覧というように、検索意図とページタイプを対応させます。
この対応が整理されていないと、似たページ同士が競合し、意図していないページが検索結果に表示されることがあります。
データベース型サイトでは、1ページずつ改善するのではなく、一覧ページや詳細ページなどのテンプレート単位で改善します。
たとえば、一覧ページであればタイトル・H1・掲載件数・内部リンクなどを共通ルールとして設計します。詳細ページでは、固有情報や関連ページへの導線、CTAなどをテンプレート単位で見直します。
同じテンプレートを利用する多数のページに改善内容を反映できる点が、データベース型サイトSEOの特徴です。
データベース型サイトでまず確認したいのが、URLの生成ルールです。
絞り込みや並び替えに使うパラメータURLを、すべてなくす必要はありません。
重要なのは、SEO対象とするURLと、ユーザー向けの機能としてのみ利用するURLを明確に分けることです。
パラメータURLが増える主な原因には、次のようなものがあります。
パラメータが付いたURLそのものが、SEO上の問題になるわけではありません。
問題になるのは、同じ内容を返す別URLが大量に存在したり、条件の組み合わせによって実質的に無限のURLが生成されたりすることです。
こうしたURLが増えると、検索エンジンに評価してほしいページが埋もれてしまいます。
まずは、自社サイトでどのような条件のときにURLが生成されるのかを把握することから始めます。
SEO対象とするURLは、「ページを生成できるかどうか」ではなく、そのページで検索流入を獲得する価値があるかどうかで判断します。
主な判断基準は次のとおりです。
| 判断軸 | 確認内容 |
|---|---|
| 検索需要 | その条件で検索するユーザーがいるか |
| 掲載件数 | 一覧として比較できるだけのデータがあるか |
| 独自性 | 他のページと異なる情報を提供できるか |
| 継続性 | 一時的ではなく継続してデータが存在するか |
| 事業価値 | CVや売上につながるページか |
この基準をもとに、サイト内のURLを大きく3つに整理します。
カテゴリページ、地域別一覧、検索需要のある掛け合わせ一覧、詳細ページなどが該当します。
内部リンクを集め、テンプレートを重点的に改善する対象になります。
並び替え、一時的な絞り込み結果、細かすぎる条件の組み合わせ、サイト内検索結果などです。
ユーザーの利便性のために残しつつ、検索結果への表示は狙いません。
条件の順序違いによる重複URL、計測パラメータ付きURL、成立しない条件の組み合わせなどです。そもそも存在させる必要がないURLにあたります。
特に重要なのは、2つ目と3つ目を分けて考えることです。
ユーザーが実際に使うページと、そもそも存在させる必要がないURLでは、適切な処理方法が異なります。この区別があいまいなまま一律にnoindexを設定したり、逆にすべてを残したりすると、必要なページまで検索結果から消えたり、不要なURLが増え続けたりします。
価格帯やエリア、属性など複数の条件から商品や求人を絞り込む仕組みを、ファセットナビゲーションと呼びます。ユーザーにとっては便利な機能ですが、条件の組み合わせごとにURLが生成される仕様の場合、検索需要のない条件まで含めて非常に多くのURLが生まれます。
対策の基本は、役割を分けることです。検索需要のある条件はSEO対象の固定URLとして持たせ、それ以外の細かな絞り込みはユーザー向けの機能として扱います。そのうえで、SEO対象としないURLについては、サイトの仕様に応じてURLの生成ルールを見直したり、robots.txtでクロールを抑えたりすることを検討します。
SEO対象としないURLへの対応には複数の方法があり、それぞれ目的が異なります。どれを選ぶかは、次の3つの視点で判断すると整理しやすくなります。
ユーザーには使わせたいが検索結果には出したくないのであればnoindex、内容が重複しているのであればcanonical、そもそも存在させる必要がないのであればURLの生成自体を止める、という判断になります。
| 処理 | 主な目的 |
|---|---|
| インデックス対象とする | 検索結果への表示を狙う |
| canonical | 重複・類似URLの正規URLを示す |
| noindex | 検索結果から除外する |
| robots.txt | クロールを抑える |
| 404/410 | URLが存在しない、削除済みであることを示す |
| 301 | 明確な後継URLへ恒久的に転送する |
| URLを生成しない | 不要URLの発生自体を防ぐ |
| 内部リンクを設置しない | 不要URLを発見されにくくする |
実務では、次のような誤りが起こりやすい点にも注意が必要です。
robots.txtでクロールをブロックしたURLにnoindexを設定しているケースでは、検索エンジンがページ内のnoindexを読み取れず、意図に反して検索結果に残り続ける可能性があります。
また、削除した詳細ページを一律でトップページへ301リダイレクトすると、Googleにソフト404として扱われる場合があります。301は、元のページの代替として成立する明確な後継ページがある場合に使用します。
在庫や募集状況が変動するデータベース型サイトでは、昨日まで掲載されていた情報がなくなり、一覧が0件になったり、詳細ページの掲載が終了したりします。
このとき、「0件ならすべて404」「掲載終了ならすべて削除」と一律に処理するのは適切ではありません。状況によって取るべき対応が異なります。
| 状況 | 基本的な考え方 |
|---|---|
| 一時的に0件だが再掲載が見込まれる | ページを維持し、代替候補を提示することを検討 |
| 空の状態が継続している一覧 | noindexを検討。カテゴリ自体を廃止するなら404 |
| 無効な絞り込み条件による0件 | そのURLで404を返す |
| 個別ページの掲載終了 | 情報価値が残るなら維持。残らなければ404/410 |
| 明確な後継ページがある | 301で後継ページへ転送 |
判断のポイントは、そのURLが今後もユーザーにとって価値を持つかどうかです。
たとえば、一時的に掲載件数が0件でも、検索需要が継続しており今後再びデータが追加される可能性が高いのであれば、ページを維持したうえで近い条件の候補を提示する方が、ユーザーにとっても有益です。反対に、構造上成立しない条件で恒常的に0件となるURLであれば、404を返す方が適切です。
なお、0件ページを放置すると、内容の薄いページが大量に存在する状態になります。どのくらいの期間0件が続いたら処理するのかを、あらかじめルールとして決めておくと運用しやすくなります。
一覧ページでは、2ページ目以降に掲載されている詳細ページを検索エンジンが発見できる状態にする必要があります。
ページネーションを実装する場合は、次の点を確認します。
「もっと見る」ボタンや無限スクロールを採用している場合も、ユーザーがクリックやスクロールをしなくても検索エンジンが対象ページへ到達できる仕組みを用意することが重要です。
URLの整理と並行して確認したいのが、検索エンジンによるクロールとインデックスの状況です。
URL数が多いサイトでは、不要なURLへクロールが集中し、本来評価してほしいページの発見や再クロールに影響が出ていないかを確認します。ただし、これはすべてのデータベース型サイトで対策が必要になるテーマではありません。まずは自社サイトが該当するかどうかを見極めることから始めます。
クロールバジェットとは、Googleがサイトをクロールする際に使う時間やリソースを表す考え方です。サーバーに負荷をかけずにクロールできる量と、サイトの規模や更新頻度から判断されるクロール需要をもとに、クロール量が決まります。
ここで押さえておきたいのは、クロール頻度を高めれば検索順位が上がるわけではないという点です。クロールバジェットへの対応は、重要なページが適切に発見・再クロールされる状態を保つための施策であり、順位改善の施策ではありません。
Googleもクロールバジェットについて、大規模サイトや更新頻度が高いサイトで特に考慮すべきテーマとして説明しています。目安としては、100万ページ以上あってコンテンツが週単位で更新されるサイトや、1万ページ以上あってコンテンツが日々更新されるサイトなどが挙げられています。
ただし、これらは厳密なしきい値ではありません。実務ではページ数だけで判断せず、次のような状況が起きていないかを確認します。
これらに該当しないのであれば、クロールバジェットを優先的な課題として扱う必要はありません。該当する場合は、不要URLの生成やクロールを抑えることから着手します。
関連記事:インデックス数とは?SEO効果と正しい調べ方・改善法を解説
検索エンジンに重要なページを発見してもらうためには、内部リンクとXMLサイトマップの状態も確認します。
SEO対象とする一覧ページには、トップページや上位カテゴリ、詳細ページなどから継続的にリンクが集まる状態を作ります。
反対に、計測用パラメータ付きURLや細かすぎる絞り込み結果など、SEO対象としないURLへ内部リンクが大量に設置されていないかも確認しましょう。
XMLサイトマップには、原則としてインデックス対象とする正規URLのみを掲載します。あわせて次の点を確認します。
サイトマップをページタイプごとに分割しておくと、どのページタイプのインデックス状況に問題があるのかを把握しやすくなります。改善後の効果測定にも役立つため、URL数が多いサイトでは早い段階で分割しておくことをおすすめします。
クロールを妨げる原因は、URL設計だけではありません。
サーバーエラーやタイムアウトが頻発している場合、クロールにも影響する可能性があります。Search Consoleの「クロールの統計情報」で、サーバーの平均応答時間や5xxエラーの発生状況を確認しましょう。ただし、サーバーを高速化すれば必ずクロール数が増えるわけではありません。クロールを妨げる技術的な問題を取り除くための確認と考えます。
また、一覧の表示や内部リンクをJavaScriptに依存している場合は、検索エンジンがユーザー操作なしで主要なコンテンツやリンクを取得できているかを確認します。商品名や求人名などの主要情報、詳細ページへのリンク、titleやcanonicalが正しく認識されているかが確認のポイントです。
問題が見つかった場合も、実装方式そのものを変更する前に、まず現在の実装で何が認識されていないのかを特定します。
クロール・インデックスの環境を整えたら、次はどのキーワードでどのページを検索結果に表示させたいかを整理します。この、検索キーワードに対して優先的に表示させたいページがPLPです。
PLPを決めずにページを増やしていくと、同じ検索意図を狙うページが複数存在することになり、意図しないページが検索結果に表示される原因になります。
まず、検索キーワードのパターンごとに、どのページタイプを表示させたいのかを整理します。中古車検索サイトであれば、次のように対応させられます。
| キーワードのパターン | 想定するPLP |
|---|---|
| 地域名+中古車 | 地域別一覧 |
| メーカー名+中古車 | メーカー別一覧 |
| 車種名+中古車 | 車種別一覧 |
| 地域名+車種名+中古車 | 地域×車種の一覧 |
| 車種名+中古車+相場 | 相場情報を含む一覧・解説ページ |
| 車両名・型式 | 詳細ページ |
この対応表を作ると、どのテンプレートを優先的に改善すべきかも判断しやすくなります。
たとえば地域別一覧に多くの検索需要が集まっているのであれば、地域別一覧のテンプレート改善が優先度の高い施策になります。
なお、すべてのキーワードにPLPを設定する必要はありません。検索需要が大きいキーワード群から順に整理していけば十分です。
掛け合わせ一覧は、生成できる条件をすべて作るのではなく、検索需要から逆算して設計します。
SEO対象とするかどうかは、先ほど挙げた判断軸と同じく、検索需要があるか、継続して十分な掲載件数を確保できるか、他のページと異なる情報を提供できるか、CVや売上につながるかといった観点で判断します。
運用面では、「掲載件数が一定以上の場合のみ一覧ページとして公開する」「掛け合わせる条件数は2つまでとする」といった社内ルールを設ける方法もあります。ルール化しておけば、担当者が変わっても判断がぶれません。
ただし、一律の数字をすべてのサイトに当てはめるのは適切ではありません。掲載データの母数や検索需要の分布はサイトによって異なるため、自社の状況に合わせて基準を決めることが重要です。
狙ったPLPが検索結果に表示されない場合は、順位だけを見るのではなく、上流から原因を確認します。
特に多いのが、同じ検索意図を狙うページが複数存在しているケースです。たとえば地域別一覧と、同じ地域を対象とした掛け合わせ一覧が並存していると、どちらを評価すべきか検索エンジンが判断しづらくなります。
この場合は、どちらをPLPとするかを決めたうえで、ページを統合するか、それぞれの役割を分けるかを検討します。役割を分ける場合は、タイトルや掲載内容が明確に異なる状態にすることが前提になります。
PLPと決めたページには、サイト内から継続的にリンクが集まる構造を作ります。
パンくずリストやカテゴリページ、詳細ページなどから関連する一覧へ内部リンクを設置し、ユーザーと検索エンジンの双方がページ同士の関係を理解しやすい状態にします。
反対に、PLP以外の類似ページへ内部リンクが集中していないかも確認しましょう。リンクが分散していると、どのページを重視すべきかが伝わりにくくなります。
関連記事:内部リンクとは?SEO効果を最大化する設置と最適化のポイント
PLPが整理できたら、次はそのページの中身を改善します。
データベース型サイトでは、多数のページが同じテンプレートから生成されます。そのため改善も1ページずつではなく、一覧ページや詳細ページといったページタイプ単位で行うことが基本です。
この章では、タイトルなどの生成ルール、一覧・詳細ページの掲載内容、そしてそれらを支えるデータと内部設計という3つの層に分けて解説します。
一覧ページでは、エリアやカテゴリなどの条件からタイトルやH1を自動生成するケースがほとんどです。
このとき、条件名だけを機械的に入れ替えるルールにすると、検索意図とずれたタイトルが大量に生成されます。そのページがどの検索意図に対応するのかを踏まえて、生成ルールを設計することが重要です。たとえば地域別一覧であれば、地域名と対象カテゴリに加えて、ユーザーが確認したい掲載件数などを含める設計が考えられます。
説明文についても、条件に応じてページ固有の情報を出せる場合は、テンプレートへ組み込むことを検討します。
ただし、ページ固有の情報を十分に出せないほど細かな条件ページが大量にある場合は、タイトルの工夫よりも先に、そのページをSEO対象とすべきかを見直す必要があります。生成ルールの改善で解決できるのは、あくまでSEO対象とする価値があるページに限られます。
ユーザーは一覧ページで候補を比較し、詳細ページで判断してCVへ進みます。それぞれのページで必要な情報は異なるため、テンプレートも分けて設計します。
一覧ページは、ユーザーが複数の商品・求人・物件などを比較するためのページです。次のような情報が掲載されているかを確認します。
ここで重要なのは、SEO目的で説明文を大量に追加することではありません。
たとえば地域別一覧であれば、その地域の掲載件数や価格帯の分布、多く扱われている条件の傾向など、掲載データそのものから分かる情報を提示できます。こうした情報は、その一覧ページでしか提供できない内容であり、ユーザーが比較・判断する際にも役立ちます。
詳細ページでは、ユーザーが最終的に判断するために必要な固有情報を十分に提供します。
商品であれば価格や在庫、求人であれば勤務条件や待遇、物件であれば面積や設備など、扱う対象によって必要な項目は異なります。そのうえで、画像や属性情報、口コミや評価、販売者・掲載元の情報、関連ページや類似アイテムへの導線、問い合わせや応募などのCTA、掲載終了時の代替情報といった要素を確認します。
注意したいのは、項目の欠損が多い詳細ページが大量に存在するケースです。この場合、テンプレートを改善しても表示できる情報が増えません。データの入力ルールや外部からのデータ連携の仕組み自体を見直す必要があります。
テンプレートを整えても、そこに流し込むデータや、ページ同士のつながりに問題があれば十分なページにはなりません。ここでは、テンプレートを支える3つの要素を確認します。
データベース型サイトでは、元データの品質がそのままページの品質に反映されます。特に次の点を確認します。
ただし、掲載数が多ければSEOで有利になるという単純な話ではありません。重要なのは、検索ユーザーのニーズに対して十分な選択肢と比較情報を提供できているかどうかです。件数が少なくても、比較に必要な情報が揃っていれば十分に機能する一覧ページもあります。
内部リンクも、ページごとに手作業で設定するのではなく、テンプレートへ組み込むことで効率的に展開できます。一覧ページから関連カテゴリや詳細ページへ、詳細ページから上位カテゴリや類似アイテムへ、といった導線をページタイプごとに設計します。
一方で、内容の薄いページへ無条件にリンクを増やさないことも重要です。「掲載件数が一定以上の場合のみリンクを表示する」「在庫が存在する場合のみ表示する」といった条件をテンプレート側に持たせることで、不要なページへリンクが集中することを防げます。
同じ考え方は、ページの生成段階にも当てはまります。データベース型サイトでは、タイトルの一部だけが異なるページや、固有情報がほとんどない詳細ページ、掲載件数が極端に少ない一覧ページが大量に生成されることがあります。公開後に1件ずつ整理するのは現実的ではないため、最低掲載件数や条件の組み合わせといったルールを生成段階で設け、基準を満たさないページは生成しない、またはSEO対象から外す仕組みを設計します。
ページやコンテンツの内容に応じて、適切な構造化データの設定を検討します。代表的なものには、次のような構造化データがあります。
| ページ・コンテンツ | 主な構造化データ |
|---|---|
| ECの商品詳細 | Product |
| 求人詳細 | JobPosting |
| 店舗・施設詳細 | LocalBusiness |
| パンくず | BreadcrumbList |
| 商品・サービスの口コミ・評価 | Review、AggregateRating |
構造化データを設定することで、ページ内の商品情報や求人情報、店舗情報などを検索エンジンに明確に伝えやすくなります。
ただし、構造化データ自体が直接検索順位を上げるものではありません。実装する際は、ページ上に実際に掲載されている内容と一致させ、テンプレート単位で正しく反映されるように設計します。
各構造化データの仕様や実装方法は、Google検索セントラルの構造化データに関するドキュメントで確認できます。
SEOで検索流入を獲得しても、ユーザーが必要な情報を探しにくかったり、問い合わせや購入まで進みにくかったりすれば、事業成果にはつながりません。
データベース型サイトでは、一覧ページや詳細ページのUI/UXを改善することで、獲得した流入を成果へつなげやすくなります。共通テンプレートを利用しているため、一つの改善を多数のページへ一度に展開できる点も特徴です。
たとえば一覧カードに表示する情報を見直したり、詳細ページのCTAの位置を変更したりすれば、同じテンプレートを利用しているすべてのページへ反映されます。
一定の自然検索流入があるサイトであれば、この横展開によって多数のユーザー体験をまとめて改善できるため、CVRやCV数への影響も大きくなります。記事型サイトのように1ページずつ改善する場合と比べ、投じた工数に対する効果が広がりやすい構造です。
ただし、絞り込み機能やCTAの改善そのものを、直接的な順位向上施策として捉えるべきではありません。SEOで流入を獲得し、UI/UX改善によってその流入を成果へつなげる、というように役割を分けて考えることが重要です。
一覧ページでは、ユーザーが条件を選び、候補を比較しやすい状態を作ります。次のような点を確認します。
特に見落とされやすいのが、0件になった場合の表示です。SEOで流入を獲得しても、条件を絞り込んだ結果として0件の画面が表示され、そこから何もできなければ、ユーザーは離脱します。近いエリアや条件を緩めた候補を提示するだけでも、詳細ページへ進む可能性は変わります。
詳細ページでは、ユーザーが知りたい情報を確認したあと、問い合わせ・応募・購入といった行動へ進みやすい導線を作ります。
スマートフォンでは、CTAの表示位置や入力の負荷がCVRへ影響しやすいため、デバイスごとに確認します。画面下部に固定表示するかどうかなど、PCとは別に設計が必要になる場合もあります。
データベース型サイトでは、一覧に多数の画像を掲載したり、絞り込み機能でJavaScriptを利用したりするため、表示速度に問題が出やすい傾向があります。
画像の読み込み方法やファイルサイズ、不要なスクリプト、サーバーの応答時間などを確認し、ユーザーが快適に利用できる状態を目指します。表示速度やCore Web Vitalsは検索におけるページエクスペリエンスにも関係するため、SEOとユーザー体験の両面から確認しておきましょう。
UI/UX改善の効果は、サイト全体のCVRだけで判断するのではなく、ページタイプごとに確認します。主に次のような指標を見ます。
これらを組み合わせると、課題がどこにあるのかを切り分けられます。
一覧から詳細への遷移率は高いのに詳細ページのCVRが低いのであれば、詳細ページの情報やCTAに課題がある可能性があります。反対に、一覧ページで多くのユーザーが離脱しているのであれば、絞り込み条件の設計や一覧カードの見せ方から改善する必要があります。
サイト全体の数値だけを見ていると、こうした切り分けができません。ページタイプ単位で計測できる状態を先に整えておくことが、改善の前提になります。
データベース型サイトのSEOでは、確認を進めるほど多くの改善候補が見つかります。
すべてを一度に改修するのではなく、問題が発生している箇所と事業への影響を確認したうえで、優先順位をつけて進めることが重要です。ここでは、実務で進める際の流れを6つのステップに整理します。
まずはサイト内にどのようなURLが存在するのかを、ページ単位ではなくURLパターン・ページタイプ単位で整理します。
整理する項目は、URLパターン、推定URL数、インデックス状況、クロール状況、自然検索流入、CV、掲載件数、利用しているテンプレートなどです。Search Consoleやアクセス解析ツールなど、複数のデータを突き合わせて確認します。
この棚卸しによって、「URLは多いが検索流入がないページタイプ」「流入はあるがCVにつながっていないページタイプ」といった課題が見えてきます。以降のステップは、この一覧をもとに判断していきます。
次に、検索キーワードごとに表示させたいページを決めます。
このとき、同じ検索意図を狙っている一覧ページが複数存在していないかもあわせて確認します。役割が重なっているページが見つかった場合は、統合するのか、それぞれの対象を明確に分けるのかを整理します。
検索流入が伸びない原因は、検索順位だけとは限りません。
たとえば、順位改善に取り組む前に、そもそも対象ページがクロールやインデックスの対象になっていないケースもあります。この場合、タイトルや掲載情報をいくら改善しても成果は出ません。
次の図のように上流から順に確認することで、どの段階に課題があるのかを切り分けられます。

上流の段階に原因がある場合、下流だけを改善しても解決しません。ページタイプごとにこの流れを確認していくと、必要のない施策へ工数を使うことを防げます。
データベース型サイトの改善には、システム改修が必要になるケースが多くあります。そのため、SEO効果の大きさだけで優先順位を決めることはできません。
判断は、SEO効果の大きさと、実装に必要な開発工数の2つの軸で行います。
SEO効果は、その施策が影響するURL数、見込まれる流入の大きさ、CVや売上への貢献度、問題の深刻度から判断します。同じ改善でも、数万ページに反映される施策と数十ページにしか反映されない施策では、得られる効果が大きく異なります。
開発工数は、実装の難易度と必要な工数に加えて、他の機能へ影響が及ぶかどうかも含めて判断します。
この2軸で整理すると、着手する順番が見えてきます。

効果が大きく工数が小さい施策から着手し、URL構造そのものの変更など影響範囲の大きな施策は計画的に進めます。
この整理は、開発部門へ改修を依頼する際の説明材料にもなります。「SEOのために必要」という説明だけでは優先度が上がりにくい場面でも、影響するURL数や見込まれる流入・CVへの影響を示せれば、判断の材料として共有しやすくなります。
テンプレートの変更は多数のページへ同時に影響します。そのため、最初から全ページへ適用せず、一部のカテゴリやページ群で検証する方法があります。
適用後はインデックス状況や表示回数、クリック数、CVRなどを確認し、想定どおりの結果になっていることを確認してから対象範囲を広げます。
特に注意が必要なのは、noindexの一括適用とURL構造の変更です。noindexは対象URLの範囲を事前に確認しないと、想定以上のページが検索結果から消えることがあります。URL構造の変更は、リダイレクト設計を誤ると流入を大きく失う可能性があるため、段階的に進めることが重要です。
改善後は、ページタイプごとに効果を確認します。クロール状況、インデックス率、PLPの一致状況、表示回数、クリック数、検索順位、CVR、CV数といった指標を見ます。
サイト全体の数値だけでは、どのページタイプの改善が効いたのかが分かりません。XMLサイトマップをページタイプ別に分けておくと、インデックス状況も比較しやすくなります。
ここまでの6つのステップを、一般的な中古車検索サイトを例に整理します。
まずSTEP1で、メーカー別・車種別・地域別・地域×車種の一覧、絞り込み結果、車両詳細ページといったURLパターンを棚卸しします。STEP2では、検索需要と掲載台数が継続して存在する条件をSEO対象とし、キーワードごとのPLPを決めます。細かな絞り込み条件は、ユーザー向けの機能として扱います。
STEP3で、PLPとしたページがクロール・インデックスされ、意図したとおり検索結果に表示されているかを段階ごとに確認します。そのうえでSTEP4として、見つかった課題を影響するURL数と開発工数で整理し、着手する順番を決めます。
改修はSTEP5で一部のページタイプに適用して結果を確認し、問題がなければ全体へ広げます。STEP6では、地域別一覧、車種別一覧、詳細ページといったページタイプごとに効果を測定し、次の改善対象を判断します。
このように、URLの選別からクロール・インデックス、PLP、テンプレート、UI/UXの順に整理していくことで、どこから着手すべきかを判断しやすくなります。
データベース型サイトのSEOでは、ページを大量に生成することよりも、どのURLをSEO対象とするのかを整理することが出発点になります。
まず、検索需要や掲載データをもとにSEO対象URLを選別し、不要なパラメータURLや重複URLの生成・クロールを抑えます。そのうえで、検索キーワードごとにPLPを整理し、一覧ページ・詳細ページのテンプレートと掲載データを改善していきます。
さらに、SEOで獲得した流入を成果につなげるためには、一覧ページや詳細ページのUI/UX改善も欠かせません。共通テンプレートを利用しているデータベース型サイトでは、一つの改善が多数のページへ反映されるため、投じた工数に対する効果が広がりやすいことも特徴です。
一方で、一つの変更が多数のページへ影響するということは、誤った変更も同様に広がることを意味します。URL、クロール・インデックス、テンプレート、CVRといった課題を分けて確認し、SEO効果と開発工数を踏まえて優先順位を決めながら、段階的に改善を進めていきましょう。
現在デジタルマーケティングにおいてお悩みがある方や、
課題を感じているがどうしていいかわからない方向けに
無料でご相談会を実施しております。
まずは自社の現状を知り、可能な改善施策はどういったものがあるのか、
スケジュール、予算感はどのようなものなのか等も含めて
ご説明しますので、お気軽にご相談ください。
監修者プロフィール
A.すべての絞り込みページをnoindexにする必要はありません。
検索需要があり、十分な掲載件数と固有の情報を提供できる条件であれば、SEO対象として残す価値があります。
一方で、細かすぎる条件や検索需要のない絞り込みまでSEO対象にすると、内容の薄いURLが増える原因になります。
条件ごとの検索需要と掲載データを確認したうえで、SEO対象とするものとユーザー向けの機能として扱うものを分けて判断しましょう。
A.ページ数だけで判断するのではなく、実際のクロール・インデックス状況を確認することが重要です。
Search Consoleで「検出 - インデックス未登録」が増え続けている、不要なパラメータURLが大量にクロールされている、新規ページの検索結果への反映が遅いといった状況があれば、URLの生成ルールやクロール状況を確認します。
こうした兆候がないのであれば、優先的な課題として扱う必要はありません。
A.一律に削除する必要はありません。
一時的に0件となっているだけで再掲載が見込まれる場合は、ページを維持したうえで近い条件の候補を提示する方法もあります。
恒常的に不要となったURLについては、noindexや404を検討します。
掲載終了ページも、情報としての価値が残っているか、明確な後継ページがあるかによって対応が変わります。
判断のポイントは、そのURLが今後もユーザーにとって価値を持つかどうかです。
A.表示速度やCore Web Vitalsなど、ページエクスペリエンスに関わる要素は検索評価にも関係します。
一方で、絞り込み機能の使いやすさやCTAの改善は、検索順位を上げるための施策ではなく、主にCVRを高めるための施策です。
データベース型サイトでは共通テンプレートを利用しているため、こうした改善を多数のページへ一度に反映できる点に効果があります。
SEOによる流入獲得と、獲得した流入をCVへつなげる改善は、それぞれ分けて評価することが重要です。
セミナー
さらに学びたい方や、弊社のサービスについて知りたい方向けに通常セミナーや、時間を限定しないオンデマンドセミナーを用意しています。
開催セミナー一覧資料ダウンロード
デジタルマーケティングに関するお役立ち資料や、弊社サービス資料をダウンロードいただけます。
サービスの
お問い合わせ
センタードのサービスに関するご質問やお見積もり、ご発注など様々なお問い合わせはこちらからお気軽にお願いします。
お問い合わせフォーム