サイト種別別SEO

ポータル・比較サイトのSEO対策｜大量ページの品質を保つ設計

2026.09.05

ポータルサイトや比較サイトのSEOは、使う道具そのものはコラム記事のSEOと変わりません。タイトルを整え、内部リンクをつなぎ、構造化データを入れる。ところが、実際に運用してみると手応えがまるで違います。原因は施策の巧拙ではなく、サイトの成り立ちにあります。掲載データからページが自動生成されるサイトでは、ページは「書くもの」ではなく「湧いてくるもの」だからです。

地域が47、カテゴリが30、絞り込み条件が5つあれば、掛け合わせたURLの数は人間が数えられる規模を超えます。しかもその大半は、誰かが企画して作ったページではありません。仕様がそうなっているから存在するページです。この状態で「1ページずつ品質を上げる」という発想を持ち込むと、着手する前に手が止まります。

そこでSEOの主戦場は、1ページの質を上げることから、生成できるURLのうちどれを検索エンジンに見せるかを決めることへ移ります。この記事では、サイト内検索ページのインデックス制御、絞り込み（ファセット）の組み合わせ爆発、掲載件数が少ないページの扱い、掲載終了時のURL処理、ユーザー投稿の品質担保まで、設計の順番どおりに整理します。

この記事でわかること

結論

ポータル・比較サイトのSEOは、1ページをどれだけ磨くかではなく、自動生成できるURLのうちどれを検索エンジンに見せるかを決める設計作業です。線引きを先に決めないと、増やしたページ数がサイト全体の評価を下げます。

01主戦場が変わる「1ページの質」から「どのURLを出すか」へ。ページを作れることと出してよいことは別物で、判断基準を先に文書化しないと運用で必ず崩れます。
02サイト内検索は閉じるGoogleはスパムを流し込まれた検索結果ページをハッキング扱いでフラグすることがあると説明しています。robots.txtでクロールごと止めるのが原則です。
03絞り込みは層で切る条件1つまでは一覧として出し、2つ以上の掛け合わせは出さない。組み合わせは掛け算で増えるため、件数の上限ではなく「層」で線を引きます。
04ゼロ件ページの扱い一覧として成立しない件数のページは、URLを作らないのではなく検索結果に出さない設計にします。件数は変動するので再判定の仕組みが要ります。
05薄さの正体問題はテンプレートで作ったことではなく、そのページにしかない情報がないこと。差し込める一次情報を1つ以上持てるかが公開の線引きになります。
06消えたページの後始末掲載終了は原則404か410。統合先が明確なときだけ301です。一覧・サイトマップ・内部リンクからの除去までを1つの手順にまとめます。

ポータル・比較サイトのSEOが「1ページの質」の勝負ではない理由

まず、この記事が対象にするサイトの範囲をはっきりさせます。飲食店・不動産・求人・クリニック・スクール・サービス比較など、掲載対象のデータベースがあり、そのデータから一覧ページと詳細ページが自動的に組み上がるサイトです。編集部が1本ずつ企画して書くメディアサイトとは、SEO上の課題がほとんど重なりません。

ページが自動生成されると、何が変わるのか

手で書くサイトでは、ページが1枚増えるのは誰かが増やそうと決めたときだけです。だから「そのページは何のために作るのか」という問いが、公開の前に必ず1回はさしはさまれます。ところが自動生成のサイトでは、その問いを通過しないままURLが生まれます。掲載店が1軒増えれば詳細ページが1枚増え、そのお店が属する地域・カテゴリ・こだわり条件の一覧ページの中身も同時に変わります。並び替えのリンクをテンプレートに置けば、その瞬間にすべての一覧ページが並び替え違いのURLを持ちます。

つまり、企画の意思とURLの発生が切り離されているのがこの種のサイトの本質です。ここを踏まえずに施策を並べると、「タイトルタグの改善」「内部リンクの強化」といった打ち手が、数万URLに対して一律に適用されることになります。効くページにも効かないページにも同じコストがかかり、しかも効かないページのほうが圧倒的に多い、という状態になりがちです。

「作れるページ」と「出してよいページ」は同じではない

この構造の違いから導かれる原則は1つです。システムが生成できるURLの集合と、検索エンジンにインデックスさせたいURLの集合は、最初から別のものとして設計するということ。前者はエンジニアリングの都合で決まり、後者はSEOの意思で決まります。両者が一致しているサイトは、ほぼ確実に出しすぎです。

実務では、この線引きを口頭の了解にしておくと必ず崩れます。新しい絞り込み条件を追加する開発チケットに、SEO側の判断が乗らないからです。条件が1つ増えるだけで、その条件と既存条件の組み合わせがすべて新しいURLとして生まれます。「どの層までインデックスさせるか」を文書として持ち、機能追加のたびにその文書に照らす——運用として続くのはこの形だけです。

Googleの側にも処理コストという制約がある

もう一つ押さえておきたいのが、Google側の事情です。Googleは大規模サイト向けにクロールバジェットの管理に関するドキュメントを公開しており、そこではクロールバジェットが「クロール処理能力の上限」と「クロール需要」の2つで決まると定義されています。処理能力の上限はサイトの応答状況で上下し、需要の側はサイトが持つURLのうちどれだけが有用と見なされるかに左右されます。

このドキュメントは2026年に2点の追記があり、そのうちの1つが「クロール処理能力の上限は全クローラーで共有される」という明文化でした。あるクローラーの高い需要が、他のクローラーに使える処理能力を減らしうる、という説明です。詳しくはクロールバジェット文書への2点の追記を扱ったニュース記事で整理しています。

ドキュメントは同時に、クロールされたページが必ずインデックスされるわけではないことも明記しています。クロール効率の改善はインデックス登録の保証ではありません。ここを混同すると、「もっとクロールさせれば載る」という誤った方向に施策が進みます。ポータル・比較サイトでやるべきことは逆で、クロールさせる対象をこちらから絞り込み、残ったページに処理を集中させることです。

インデックスさせるページを「層」で決める

個別のURLごとに判断するのは不可能なので、URLを層に分けて層ごとに方針を決めます。ポータル・比較サイトのURLは、だいたい次の4層に整理できます。

4つの層と、それぞれの既定方針

層	URLの例	既定の方針
詳細ページ	掲載店・物件・求人・商品などの個票	原則インデックスさせる。サイトの一次情報が載る唯一の層
主要な一覧ページ	地域トップ、カテゴリトップ、地域×カテゴリ	選んでインデックスさせる。検索需要があり件数も足りる組み合わせだけ
絞り込み・並び替え	条件を重ねた一覧、ソート違い、表示件数違い	原則インデックスさせない。詳細ページへのリンクは通す
サイト内検索結果	検索ボックスから生成されるクエリ付きURL	原則クロールさせない。robots.txtで止める

層の切り方はサイトによって多少変わりますが、「一次情報が載る層」「検索需要に対応する層」「操作の途中経過の層」「利用者の入力で無限に増える層」の4つに分けるという考え方は共通して使えます。

URLの形で層を見分けられるようにしておく

制御しやすいURL設計の例を挙げます。パスで表現するものと、クエリパラメータで表現するものを最初に決めておくのが肝心です。

/tokyo/                          → 地域トップ（一覧・インデックスさせる）
/tokyo/cafe/                     → 地域×カテゴリ（一覧・インデックスさせる）
/tokyo/cafe/shop-1234/           → 詳細（インデックスさせる）
/tokyo/cafe/?open=now            → 絞り込み1つ（内容次第で判断）
/tokyo/cafe/?open=now&wifi=1      → 絞り込み2つ以上（インデックスさせない）
/tokyo/cafe/?sort=review         → 並び替え（インデックスさせない）
/search?q=...                    → サイト内検索（クロールさせない）

ポイントは、インデックスさせたい層はパスで、させたくない層はクエリパラメータで表すという原則です。この形にしておくと、robots.txtでもサーバーログの集計でもGoogle Search Consoleのフィルタでも、同じ基準で層を切り出せます。逆に、絞り込み条件までパスに含めてしまう設計にすると、後から「この階層だけ止める」という操作が難しくなります。

なお、URLをどう正規化するか、どのURLを代表として選ぶかという実装の詳細はcanonicalタグとURL正規化の解説に、ページ送りの実装はページネーションのSEO実装ガイドにまとめています。この記事では、それらを「どのURLに対して適用するか」という判断のほうに集中します。

サイト内検索ページを開けたままにするリスク

4層のうち、最も優先度が高く、しかも見落とされやすいのがサイト内検索の結果ページです。ほとんどのサイトに検索ボックスがあり、そのクエリがURLに載る実装になっています。ここを開けたままにしておくと、外部の第三者が自由にあなたのサイトのURLを作れる状態になります。

Googleは検索結果ページを「ハッキング」としてフラグすることがある

GoogleのJohn Mueller氏とMartin Splitt氏は、ポッドキャスト「Search Off the Record」で、スパム業者が検索ボックスを悪用して大量のスパム検索ページを生成したときに何が起きるかを説明しています。Mueller氏は、検索結果ページに自サイトと無関係な語が含まれ、しかもインデックス可能である場合に品質の問題になりうるとし、それが「他の人があなたを踏み台にスパムするためのベクター」に近いものになると述べています。

さらに重要なのは、Googleがこの種のページをあたかもハッキングされたページであるかのようにフラグすることがあるという点です。原因が外部からの侵入ではなくサイト自身の仕様であっても、Search Console上の見え方は「ハッキング」になりえます。侵入の痕跡を探しても何も出てこないため、原因の切り分けで時間を失いやすい種類の問題です。この一件の詳細はサイト内検索ページの放置がハッキング判定につながるという警告を扱ったニュース記事で整理しています。

Splitt氏は、検索ボックスの実装によってはサイトが無限の「クロール空間」に変わりうるとも述べています。Googleが検索ページをクロールしたことに反応して「もしかして」のような候補リンクが表示され、そこからさらにページが生成され続けるためです。両氏がrobots.txtでのブロックを勧める理由として挙げたのは、Googleは検索ページをクロールする必要がない・無限クロールを防げる・サーバー負荷を軽減できる・クロール予算の浪費を防げる、の4点でした。

robots.txtの書き方は「広く一般的に」

両氏は、自動生成される検索ボックスページのあらゆるバリエーションを捕まえられるよう、可能なかぎり広く一般的なルールを使うべきだとしています。実装ごとにパラメータ名が違うため、1つのパスだけを止めても抜け道が残るからです。

# サイト内検索の結果ページ（クエリがURLに載る実装）
User-agent: *
Disallow: /search
Disallow: /*?q=
Disallow: /*&q=
Disallow: /*?keyword=
Disallow: /*&keyword=

# 並び替え・表示件数（一覧の中身は同じで順序だけが違うURL）
Disallow: /*?sort=
Disallow: /*&sort=
Disallow: /*?per_page=
Disallow: /*&per_page=

# サイトマップの場所は明示しておく
Sitemap: https://example.com/sitemap.xml

書き方の詳細と記法の注意点はrobots.txtの書き方ガイドにまとめています。ここでは、ポータル・比較サイトで特に事故が起きやすい2つの落とし穴だけ取り上げます。

落とし穴1：Googlebot専用セクションを書くと「*」が無視される

robots.txtでは、より具体的なルールが勝ちます。「User-agent: Googlebot」というセクションが存在すると、Googlebotはそのセクションだけを使い、「User-agent: *」に書いたルールを一切読みません。実際にこれが原因で、robots.txtで拒否したはずのサイト内検索結果ページがインデックスされ続けた事例が報告されています。/search をブロックしていたのが「*」側だけだったため、Googlebotにはそのルールが適用されていなかった、という構図でした。

この事例はMueller氏が仕様として説明したもので、詳細はrobots.txtのGooglebot指定が「*」のルールを無効化する件のニュース記事にあります。Googlebot専用セクションを書くのであれば、「*」に書いたブロック指定をすべてGooglebotセクションにも複製するのが安全です。

落とし穴2：robots.txtとnoindexを同じURLに重ねない

もう一つは、robots.txtでクロールを止めたURLにnoindexを併記してしまうパターンです。robots.txtのDisallowはクロール（ページ内容の取得）を止める指示であり、インデックス登録を止める指示ではありません。そのURLが外部からリンクされていれば、Googleは中身を読まないままURLだけを検索結果に登録することがあります。そして中身を読まない以上、ページに書いたnoindexも、レスポンスヘッダーのX-Robots-Tagも、読み取られません。

この矛盾が実際に起きた例として、AIチャットの共有ページがrobots.txtでブロックされていながら検索結果に現れた一件があります。ページ側はnoindex相当のヘッダーを返していたにもかかわらず、クロールが止められていたためにその指示が届かなかった、という構図でした。Splitt氏は、この種の矛盾を避けるために両方のルールを同じページに設定することを避けるべきだと助言しています。詳細は「Disallowはnoindexの代わりにならない」という事例のニュース記事にまとめています。

したがって、手順の順序が重要になります。

まだインデックスされていないURL群 → robots.txtでクロールを止める。これが最も軽く、確実
すでにインデックスされているURL群 → 先にnoindexで検索結果から落とす。落ちきったのを確認してからrobots.txtでブロックする
その両方が混ざっている → 実装上の区別が付かないなら、まずnoindexに寄せる

いきなりrobots.txtで塞ぐと、インデックス済みのURLがnoindexを読み取ってもらえないまま検索結果に残り続けます。Search Consoleのページのインデックス作成レポートで対象URLがどのステータスにいるかを先に確認してから、順序を決めてください。

ファセット（絞り込み）の組み合わせ爆発をどう抑えるか

サイト内検索を閉じたら、次はファセットナビゲーションです。「エリア」「価格帯」「こだわり条件」「営業時間」「並び替え」といった絞り込みは、利用者にとって価値のある機能である一方、SEOから見ると最も厄介なURL生成装置になります。

組み合わせは足し算ではなく掛け算で増える

ここは統計の話ではなく単純な算術です。仮に、エリアの選択肢が10、カテゴリが8、こだわり条件が5つ（それぞれオン・オフの2状態）あるとします。エリアとカテゴリの組み合わせだけで10×8＝80通り、そこにこだわり条件のオン・オフを掛けると80×2の5乗＝2,560通りになります。並び替えが4種類あればさらに4倍で10,240通り、ページ送りが平均5ページあれば51,200通りです。実務ではこれより選択肢が多いのが普通です。

ここで理解しておきたいのは、この数はコンテンツの量ではなくURLの量にすぎないということです。掲載件数そのものは増えていません。同じ掲載データを違う切り口で並べ替えただけのURLが、指数関数的に増えているだけです。Googleの側から見れば、処理コストを払って取得したページのほとんどが、すでに知っている情報の並べ替えだった、という結果になります。

量産型のURLがなぜ失速するのかという論点は、AI生成コンテンツの文脈でも同じ構造で語られています。量産コンテンツとクロール経済圏を扱ったニュース記事では、数千のURLを新たに投入してもGoogleが自動的にクロール予算を増やしてくれるわけではなく、そのドメインの評価が処理コストに見合うかがまず判断される、という整理が紹介されています。ファセットによるURL増殖は、これとまったく同じ問題に突き当たります。

「条件1つまで」を既定線にする

絞り込みページを一切インデックスさせない、という判断もありえます。ただ、実際には「渋谷カフェ電源」のように、条件を1つ足した組み合わせに明確な検索需要があることは珍しくありません。そこで実務上使いやすいのが、条件を1つだけ選んだ状態までは一覧ページとして扱い、2つ以上重ねた状態は出さないという既定線です。

この線を引く根拠は3つあります。第一に、条件1つまでなら組み合わせ数が現実的な範囲に収まり、1つずつ検索需要を確認できること。第二に、条件を2つ以上重ねると該当件数が急速に減り、一覧として成立しなくなること。第三に、2つ以上の組み合わせに検索需要があるなら、それは絞り込みURLではなく企画されたページ（人が編集した特集ページ）として作るべきだからです。

例外として出したい組み合わせがあれば、既定線を動かすのではなく、ホワイトリストとして個別に指定します。「原則出さない・例外は明示的に許可する」という形にしておけば、条件が1つ追加されたときにURLが勝手に増えることはありません。逆に「原則出す・問題のあるものだけ止める」という形にすると、機能追加のたびに漏れが生まれます。

出さないページに何を書くか

インデックスさせない絞り込みページでも、そこから詳細ページへのリンクは通したいのが普通です。その場合に使うのがnoindexとfollowの組み合わせです。

<!-- 条件を1つだけ選んだ絞り込みページ：一覧として出す -->
<link rel="canonical" href="https://example.com/tokyo/cafe/power-outlet/">

<!-- 条件を2つ以上重ねたページ：自身は出さず、詳細ページへのリンクは通す -->
<meta name="robots" content="noindex,follow">
<link rel="canonical" href="https://example.com/tokyo/cafe/?open=now&amp;wifi=1">

ここで注意したいのが、noindexのページのcanonicalを別URLに向けないことです。「このページは出さない」と「このページの代表URLは別にある」は、Googleにとって矛盾したシグナルになります。noindexを付けるページのcanonicalは自分自身に向けるのが素直な形です。canonicalをどう設計するかはcanonicalタグの解説で扱っています。

また、robots.txtでクロールを止めたURLにnoindexを書いても届かないのは前章のとおりです。「クロールさせないURL」と「クロールはさせるがインデックスさせないURL」を、層の設計段階で分けておく必要があります。並び替えや表示件数のように中身が完全に同じURLはrobots.txtで、絞り込みのように中身が違って詳細ページへの導線になるURLはnoindexで、という切り分けが目安になります。

パラメータの正規化をサーバー側でやる

もう一つ、URL数を機械的に減らせる打ち手があります。同じ結果を返すのに文字列だけが違うURLを、サーバー側で1つに寄せることです。

パラメータの順序を固定する：?a=1&b=2 と ?b=2&a=1 は同じ結果を返すのに別URLです。決めた順序に並べ替えたURLへ寄せます
空値・既定値のパラメータを落とす：?sort= や ?page=1 のように、付いていても付いていなくても同じ結果になるパラメータは削除します
未知のパラメータを無視する：アクセス解析用のパラメータなど、絞り込みに関係しないものが付いたURLがクロールされないようにします
大文字・小文字と末尾スラッシュを統一する：どちらでも表示できる実装は、URLの重複源になります

これらはcanonicalタグでも吸収できますが、canonicalは「クロールされた後」に効くシグナルです。クロールコストそのものは発生します。内部リンクとして出力するURLを最初から正規化しておけば、そもそもクローラーが余計なURLを見つけません。順序としては、内部リンクの正規化が先、canonicalは保険、という関係になります。

掲載件数がゼロ・1件のページをどう扱うか

ポータル・比較サイトに固有で、かつ運用の中で最も頻繁に発生するのが「該当する掲載がないページ」です。地域とカテゴリの掛け合わせを網羅的に生成すれば、必ず該当ゼロの組み合わせが出ます。

ゼロ件ページは「作らない」より「出さない」

ゼロ件ページの扱いには2つの流儀があります。URLそのものを404にする方法と、URLは存在させつつ検索結果には出さない方法です。

結論から言えば、利用者がその組み合わせにたどり着く導線がサイト内にあるなら、404にすべきではありません。絞り込みUIで選べる組み合わせを選んだら404が返る、という挙動は利用者にとって不可解です。この場合は、ページとしては正常に返しつつ（HTTPステータスは200）、noindexを付けて検索結果には出さないのが素直です。

一方、外部からリンクされる可能性もサイト内の導線もない、システムが機械的に組み合わせただけのURLであれば、そもそも生成しないのが最善です。生成しないというのは、内部リンクとしてどこにも出力せず、サイトマップにも載せない、ということです。

いずれの場合も避けたいのが、ゼロ件なのに「該当0件」とだけ書かれたページを大量にインデックスさせることです。Googleはスパムに関するポリシーで、独自のコンテンツや付加価値のない薄いコンテンツを問題として扱うと明記しています。ゼロ件ページの量産は、その典型例に当たります。

件数の閾値と、その運用

ゼロ件だけでなく、1件・2件のページも「一覧として成立しているか」を考える必要があります。掲載が1件しかない一覧ページは、実質的にその1件の詳細ページの劣化コピーです。同じ情報がより整った形で詳細ページ側にある以上、一覧ページを検索結果に出す理由がありません。

掲載件数	推奨する挙動	理由
0件	200で返しnoindex。導線がなければURL自体を生成しない	一覧として何も提供していない
1〜2件	原則noindex。詳細ページへの導線は残す	詳細ページと情報が重複し、一覧の価値が出ない
3件以上	検索需要があればインデックス対象の候補にする	比較・選択という一覧本来の機能が働き始める

ここに挙げた3件という数字は、Googleが定めた基準ではありません。「比較として成立する最低ライン」をサイトごとに決めた運用上の閾値です。掲載対象の性質によって適切な線は変わります。物件のように選択肢が多いことが前提のジャンルなら閾値は高めに、専門性の高いサービスで掲載自体が希少なジャンルなら低めに設定することになります。自社の一覧ページを実際に見て、「利用者がこれを見て比較検討できるか」で判断してください。

件数は変動するので、判定を1回で終わらせない

見落とされがちなのが、掲載件数が時間とともに変わることです。公開時点で5件あったページが、掲載終了が続いて1件になることがあります。逆に、公開時点でゼロ件だった組み合わせに、後から掲載が増えることもあります。

したがって、インデックスさせるかどうかの判定はページ生成時に動的に行うのが正しい形です。テンプレート側で件数を数え、閾値未満ならnoindexを出力し、サイトマップの生成時にも同じ条件でURLを除外します。手作業のリストで管理すると、必ず現実とずれます。

同じ理由で、サイトマップは静的ファイルとして手で作るのではなく、掲載データから自動生成する仕組みにしておくべきです。サイトマップに載っているのに検索結果に出したくないページ、逆に出したいのに載っていないページは、いずれも運用の綻びのサインになります。サイトマップの作り方と送信手順はサイトマップの解説記事にまとめています。

「実質的に中身が薄いページ」を量産しないための線引き

ここまではURLの数を制御する話でした。ここからは、残したページの中身の話です。テンプレートから展開するページで最も問われるのが、この論点になります。

問題は「テンプレートで作ったこと」ではない

まず誤解を解いておきます。テンプレートを使ってページを作ること自体は、Googleが問題視している対象ではありません。GoogleのMueller氏は、AI生成コンテンツについて「すべてのAI生成コンテンツが悪いと言っているわけではない」と明言したうえで、利用者が見て「これは自分にとって独自で価値あるものが何もない」と感じることが問題だと説明しています。同氏がその状態を表現した言葉が「誰でも書けるし、何も伝わらない」でした。

この整理は、テンプレート展開のページにそのまま当てはまります。判定基準は「どう作ったか」ではなく「そのページにしかない情報があるか」です。地域名だけを差し替えた文章、掲載データをそのまま並べただけの一覧、他サイトの説明文を転載しただけの詳細ページは、この基準を満たしません。

Mueller氏はまた、技術的な理由が見当たらないのに多くのページがインデックスされないというパターンに気づいたら、個々のURLを技術的に直そうとするのではなく、一歩下がってサイト全体の品質を考える必要があるとも述べています。Googleのシステムがサイトの品質に強い懸念を持つと、クロールもインデックスも減らす挙動をとるためです。この点は「クロール済み-未インデックス」と品質の関係を扱ったニュース記事とサイト品質と未インデックスページの関係の記事で詳しく扱っています。

後者の記事で押さえておきたいのは、Mueller氏が「品質とはテキストだけの話ではなく、ページ上の体験全体だ」と繰り返している点です。文章量を増やすことは品質改善と同義ではありません。一覧ページであれば、比較のしやすさ・並び順の妥当性・広告の量といった要素も、ここで言う体験に含まれます。

差し込む一次情報を1つ以上持てるか

実務に落とすと、線引きはこう表現できます。そのページに、テンプレートの外から差し込める固有の情報が1つ以上あるか。なければ、そのページは公開しないか、より上位のページに統合します。

固有の情報として使えるのは、たとえば次のようなものです。

掲載事業者が自分で入力した説明文（他サイトからの転載でないことが担保できる場合）
そのページの対象範囲でしか出せない集計値（掲載件数の内訳、価格帯の分布、営業時間の傾向など、自社データから計算できるもの）
編集部が確認した一次情報（公式サイトで裏を取った事実、実際に問い合わせて確認した内容）
利用者からの投稿（後述の品質担保が前提）
その地域・カテゴリに固有の文脈（制度、慣習、季節性など、確認できる範囲の事実）

逆に、固有の情報として数えてはいけないものもあります。地域名を差し替えただけの定型文、他サイトの説明文の要約、そのページを見ても検証できない一般論。これらを何本並べても、ページの独自性は上がりません。

なお、低品質なまとめ記事がAI Overviewの引用元になっている事例も報告されています。ローカル結果のAI Overviewが自己宣伝的なリスティクルを引用していた件では、一覧に並ぶすべての事業者について、掲載企業のうち一社自身が書いた記事が主要な出典として使われていました。比較・一覧という形式そのものは今も引用されやすい形式です。だからこそ、その一覧が中立で、確認された情報にもとづいていることが、これまで以上に問われる局面に入っています。

当サイトでテンプレート展開をやったときに気をつけたこと

参考として、当サイトの運営経験を1つ挙げます。scale-basicsでは、都道府県・政令指定都市を対象に「地域名×SEO会社」という同型の記事を21本公開しています（東京のSEO対策会社の記事がその1本目です）。構成はテンプレート化されており、この記事で扱っているポータル・比較サイトの構造にかなり近いものになっています。

運用してみて、テンプレート展開で最も神経を使ったのは掲載する事業者の情報をどこから取るかでした。比較サイトやまとめ記事に出ている料金・実績をそのまま転記すると、古い値や不正確な値がそのまま流通します。そこで、掲載する料金や実績は各社の公式ドメインで確認できたものだけを書き、公式が公開していない項目は「公開していない」と明記する、という運用にしています。第三者のまとめから数値を持ってこないという一点だけで、記事の性格がかなり変わりました。

もう一つは、各ページに「そのページでしか成り立たない要素」を明示的に組み込んだことです。地域ごとに掲載企業が実際に違うこと、各社の所在地に対応した地図を置いたこと、会社情報を表形式で揃えたこと。テンプレートは骨格であって、中身まで共通化してしまうと成立しない、というのが実感です。

逆に、うまくいかなかった点も書いておきます。同型記事を一度に大量投入すると、公開後の確認作業が追いつきません。件数が多いほど、公開のペースを分け、公開後に各ページのインデックス状況を確認してから次を出すという進め方が現実的でした。ポータル・比較サイトで新しい層のページを開放するときも、同じ考え方が使えます。全層を一度に開けず、需要の大きい層から段階的に開け、Search Consoleの反応を見てから次に進むほうが安全です。

公開前に通すチェック

テンプレートから展開するページを新しく開放するときの確認項目を、この記事の内容から整理しておきます。

そのページに、テンプレート外から差し込める固有の情報が1つ以上あるか
掲載件数が閾値を満たしているか。満たさない場合の挙動がテンプレートに実装されているか
タイトルとメタディスクリプションが、機械的な文字列結合になっていないか
同じ層の他ページと比べて、実質的に読み替えただけの内容になっていないか
そのページに対応する検索需要が実在するか（キーワードの存在を確認したか）
サイトマップへの掲載条件と、noindexの出力条件が同じロジックで動いているか

Googleが「薄いコンテンツ」を理由に部分的な手動対策を出した事例では、サンプルURLが1つも提示されず、対象となったURLパターンだけが通知されたと報告されています（フォーラムサイトの手動対策事例）。対象が「パターン単位」で指定される以上、対策も個別ページではなくパターン単位で考える必要がある、というのがこの事例の教訓です。

一覧ページと詳細ページの内部リンク設計

出すページを決めたら、次はそれらをどうつなぐかです。ポータル・比較サイトの内部リンクは、一覧から詳細への一方通行になりがちで、そこに構造上の弱点が生まれます。

詳細ページへの入口を一覧だけにしない

掲載データが増えると、一覧のページ送りは深くなります。10ページ目、20ページ目にしか出てこない詳細ページは、トップから遠く、内部リンクもほとんど集まりません。しかも並び順が更新日時や評価順であれば、その位置は日々変わります。クローラーから見て「どこからも安定してリンクされていないページ」が大量に生まれるのがこの構造です。

対策は、一覧以外の入口を用意することです。

関連する掲載への相互リンク：詳細ページから、同じ地域・同じカテゴリの他の掲載へリンクする。ページ送りの深さと無関係に到達できる経路が生まれます
絞り込み一覧をリンクとして出す：詳細ページから「このエリアのカフェ一覧」「電源のあるカフェ一覧」へ戻す。上位の一覧ページにリンクが集まります
サイトマップで直接伝える：詳細ページのURLをサイトマップに載せることで、内部リンクの深さとは別の経路で存在を伝えられます

ただし、サイトマップは内部リンクの代わりにはなりません。存在を知らせることはできても、サイト内でどれだけ重要かというシグナルは内部リンクが担います。両方が必要です。内部リンクの設計そのものは内部リンク戦略の記事で扱っています。

ページ送りの深さを設計で減らす

ページ送りが深くなる問題は、リンクの張り方だけでは解決しません。1ページあたりの表示件数、絞り込みの粒度、並び替えの既定値といった設計側の要素が効きます。

たとえば地域の粒度を「都道府県」だけにすると、東京都のページに膨大な件数が集まり、ページ送りが深くなります。「都道府県＋市区町村」まで用意すれば、1つの一覧に載る件数が減り、ページ送りも浅くなります。この粒度の設計は、SEOの都合とUIの都合が一致しやすい領域です。

ページ送り自体の実装方法（無限スクロールとの比較、リンクの持たせ方など）はページネーションの記事にまとめています。

パンくずで階層を明示する

階層が深いサイトほど、パンくずリストの価値が上がります。「トップ > 東京都 > 渋谷区 > カフェ > 店舗名」という表示は、利用者に現在地を伝えるだけでなく、上位階層への内部リンクを全ページから供給します。詳細ページが何万枚あっても、そのすべてが上位の一覧ページへリンクを返す形になります。

構造化データでのマークアップも合わせて実装しておきます。実装方法はパンくずリストの記事と構造化データマークアップのガイドで扱っています。

掲載終了・データ削除時のURLの扱い

ポータル・比較サイトは、ページが増える一方ではありません。掲載終了、契約終了、商品の販売終了、求人の募集終了——URLが消えるイベントが日常的に起きます。ここの扱いを決めていないサイトは、時間の経過とともに壊れたURLと中身のないページを蓄積します。

404・410・301の使い分け

Googleのクロールバジェットのドキュメントは、恒久的に削除したページには404または410を返すよう明記しています。そして、404は「そのURLを再びクロールしない」という強いシグナルになると説明されています。一方、robots.txtでブロックしたURLはクロールキューに長く残り、ブロックが外れると再クロールされます。消えたページをrobots.txtで塞ぐのは、後始末として適切ではありません。

状況	返すべきもの	補足
掲載が終了し、代わりになるページがない	404 または 410	410は「恒久的に消えた」という明示。404で十分な場面が大半
掲載が別のURLに統合された	301	統合先が明確に対応する場合のみ。曖昧なら404
一時的に非公開（再開予定あり）	200＋noindex、または404	期間が読めないなら404が無難
消えたページを全部トップへ301	やってはいけない	対応関係のない転送はソフト404として扱われる

最後の行は、ポータル・比較サイトで最も多い事故です。「404を出したくないから」という理由で、消えた詳細ページをすべてトップページや一覧ページへ転送する実装です。転送先に元のページの内容がない以上、Googleはこれをソフト404として扱います。そしてクロールバジェットのドキュメントによれば、ソフト404のページはクロールされ続け、バジェットを浪費します。404を避けようとした結果、404より悪い状態を作ることになります。301と302の使い分けや実装方法はリダイレクトの解説記事にまとめています。

「掲載終了しました」ページを残す場合の条件

ジャンルによっては、掲載終了後もそのURLに価値が残ることがあります。求人の募集終了ページ、販売終了商品のページ、閉店した店舗のページなどです。利用者が過去の情報を探して訪れることがあり、外部からのリンクも残っています。

この場合に200で残すなら、条件が2つあります。第一に、終了していることがページ上で明確に分かること。第二に、そのページから次の行動につながる導線があること——同じ条件の現在の掲載一覧へのリンクなどです。この2つがないと、単に古い情報が残っているだけのページになり、サイト全体の品質評価に効いてきます。

そして、終了ページを残す場合でも次の処理は必要です。

一覧ページの検索対象から外す（利用者が終了済みの掲載を選べる状態にしない）
サイトマップから削除する（更新頻度の高いURLとして扱わない）
件数の集計から外す（終了分を含めて「〇件」と表示しない）
件数が閾値を割った一覧ページの扱いを再判定する

特に最後の項目は忘れられがちです。掲載終了が積み重なると、以前は10件あった一覧が2件になっていることがあります。前章で決めた閾値の判定を動的に行っていれば自動的に処理されますが、公開時に一度だけ判定する実装だと、ここで綻びます。

削除の反映を1つの手順にまとめる

掲載終了の処理は、複数の場所に影響します。詳細ページのHTTPステータス、一覧ページの内容、サイトマップ、内部リンク、件数表示、そして関連掲載のリンク。これらを別々の担当が別々のタイミングで処理していると、必ずどこかが取り残されます。

掲載データのステータスが「終了」に変わったときに、上記のすべてが自動的に反映される設計にしておくのが理想です。運用でカバーする場合も、チェックリストを1つにまとめ、掲載終了の処理をそのリスト単位で行うようにします。テクニカルSEO全般の点検項目はテクニカルSEOのチェックリストにまとめてありますので、そちらも運用の土台として使えます。

ユーザー投稿・口コミを扱う場合の品質担保

口コミやレビューを掲載するサイトでは、投稿されたコンテンツが独自性の源泉になります。同時に、管理を誤れば品質上の負債にもなります。この二面性を前提に設計します。

レビューの構造化データにはガイドラインがある

Googleはレビュースニペットの構造化データのガイドラインに、やらせのレビューや未開示の謝礼レビューを、ページ本文にも構造化データにも含めてはならないという記述を追加しています。禁止対象として挙げられているのは、製品やサービスの実際の利用経験に基づかないレビューと、金銭・割引・クーポン・無料の製品などの見返りと引き換えに書かれ、かつその見返りを明確かつ目立つ形で開示していないレビューです。

この明文化の詳細はレビュースニペットのガイドライン更新を扱ったニュース記事にまとめています。実務上の要点は、レビューの内容だけでなく、そのレビューをどう集めたかまでが適格性の判断対象になったことです。投稿キャンペーンで割引やクーポンを提供しているなら、その事実を明確に開示する必要があります。

投稿がゼロ・1件のページをどうするか

口コミを扱う場合、掲載件数の閾値と同じ問題が投稿数でも起きます。投稿が0件の詳細ページ、投稿が1件だけの一覧ページ。ここでの判断は、掲載件数の場合と少し異なります。

詳細ページについては、投稿が0件でもインデックスさせて構いません。掲載事業者の情報という一次情報がすでに載っているからです。ただし、投稿がないのに評価の構造化データを出力してはいけません。集計対象がない状態で評価値を出すのは、ガイドライン違反である以前に、事実と異なる表示になります。

一方、「口コミ一覧」のように投稿そのものを主役にした専用ページを別URLで持っている場合は、投稿数が少ない段階ではインデックスさせない判断が妥当です。詳細ページに口コミ欄が含まれているなら、そのページと内容が重複します。

投稿内のリンクと、スパム投稿への備え

投稿にURLを書ける仕様にしているなら、リンクの属性を必ず指定します。Googleはアウトバウンドリンクの修飾で、リンクの性質を伝える属性を用意しています。

<!-- 利用者の投稿に含まれる外部リンク -->
<a href="https://example.net/" rel="ugc nofollow">店舗の公式サイト</a>

<!-- 掲載企業が費用を払って設置しているリンク -->
<a href="https://example.org/" rel="sponsored">スポンサー企業のサイト</a>

属性の指定は、スパム投稿を防ぐ機能ではありません。防ぐ側の設計は別に必要です。投稿前の審査、投稿数の制限、リンクを含む投稿の扱い、通報の受け口。投稿フォームは、サイト内検索と同じく「外部の第三者があなたのサイトのコンテンツを書ける入口」である点を忘れないでください。前章で扱ったサイト内検索スパムと、投稿スパムは同じ性質の問題です。

フォーラムのように利用者の投稿が大半を占めるサイトが、薄いコンテンツを理由に部分的な手動対策を受けた事例もあります。投稿を集めること自体は価値ですが、集まった投稿が実質的な内容を持たないまま蓄積すると、その層全体が問題として扱われることがあります。投稿を増やす施策と、投稿の質を保つ仕組みは、必ずセットで用意するのが原則です。

運用でどう回すか：見る指標と手順

ここまでの設計を入れたら、あとは想定どおりに動いているかを確認し続ける段階に入ります。ポータル・比較サイトで見るべきものは、一般的なSEOの指標とは少し違います。

「送信したURL数」と「インデックスされたURL数」の差を見る

最初に見るのは、サイトマップに載せたURL数と、実際にインデックスされたURL数の関係です。Search Consoleのページのインデックス作成レポートで、この差と、その内訳のステータスを確認できます。

「クロール済み – 現在インデックス未登録」が多い：クロールはされたが載らなかった状態。技術的な原因が見当たらないなら、その層の内容を見直す合図です
「検出 – インデックス未登録」が多い：存在は知られたが訪問されていない状態。クロール需要が足りていないか、URLを出しすぎている可能性があります
「robots.txtによりブロック」に想定外のURLがある：ブロックの記述が広すぎて、出したい層まで巻き込んでいないかを確認します
「重複しています」系のステータス：正規化が効いていない層があるサインです

Mueller氏の説明では、これらのステータスは技術的な不具合として個別に修正する対象ではなく、大きなパターンとして品質を見直す合図として読むべきものです。1つのURLを直すのではなく、そのURLが属する層をどうするかを考える——これが層で設計することの実利です。

サーバーログでクローラーの動きを層ごとに見る

Search Consoleだけでは、クローラーがどの層にどれだけ時間を使っているかが分かりません。ここはサーバーログの出番です。URL設計の段階で層がパスやパラメータで見分けられるようにしておけば、ログを層ごとに集計するのは難しくありません。

見るべきは、インデックスさせたい層への訪問が、させたくない層に食われていないかです。robots.txtでブロックしたはずのパターンにクローラーが来ているなら、記述に漏れがあります。並び替えパラメータ付きのURLにアクセスが集中しているなら、内部リンクの正規化ができていません。

あわせて、5xxエラーとHTTP 429の発生状況も確認します。クロールバジェットのドキュメントは、この2つをクロール上限が下がる条件として名指ししています。応答時間の推移（レイテンシとTime to First Byte）も、上限の上下に効くと明記されています。大量のURLを持つサイトでは、サーバーの安定性がそのままクロール量に跳ね返ります。

サイトマップは「今出したいURL」の宣言として使う

サイトマップは、インデックスさせたいURLだけを載せる場所です。noindexを付けたURL、robots.txtでブロックしたURL、閾値未満の一覧ページは載せません。サイトマップの中身と、noindexの出力条件が同じロジックから生成されている状態を目指します。

クロールバジェットのドキュメントは、更新されたコンテンツがある場合にlastmodタグを含めることを推奨しています。ただし、内容が変わっていないのに日付だけを更新するような使い方は、シグナルとしての価値を失わせます。掲載件数の増減や掲載内容の更新といった実際の変更に連動させてください。

大量のURLを持つサイトでは、サイトマップを層ごとに分割しておくと運用が楽になります。詳細ページ用、一覧ページ用のように分けておけば、Search Consoleのサイトマップレポートで層ごとの登録状況を比較できるからです。分割の方法や送信手順はサイトマップの記事で扱っています。

まとめ

ポータル・比較サイトのSEOで最初にやるべきことは、施策を並べることではありません。システムが生成できるURLと、検索エンジンに見せるURLを別のものとして定義し、その線引きを文書として持つことです。着手の順番で整理します。

URLを4層に分ける：詳細ページ、主要な一覧、絞り込み・並び替え、サイト内検索。層がURLの形で見分けられるように設計する
サイト内検索を閉じる：robots.txtで広く一般的なルールを使ってクロールを止める。Googlebot専用セクションを書く場合は、ブロック指定を必ず複製する
絞り込みは条件1つまでを既定線にする：例外はホワイトリストで明示的に許可する。出さないページはnoindexとfollowの組み合わせで、canonicalは自分自身に向ける
件数の閾値を決め、動的に判定する：ゼロ件・1件のページは検索結果に出さない。件数は変動するので、判定を公開時の1回で終わらせない
差し込む一次情報を1つ以上持てるかで公開を判断する：テンプレートで作ったこと自体は問題ではなく、そのページにしかない情報の有無が線引きになる
掲載終了の後始末を1つの手順にまとめる：原則404か410、統合先が明確なときだけ301。全部トップへ転送するのはソフト404を量産するだけ
投稿を扱うなら、増やす施策と質を保つ仕組みをセットにする：レビューの構造化データには収集方法まで含めたガイドラインがある
層ごとに数字を見る：サイトマップの送信数とインデックス数の差、Search Consoleのステータス内訳、サーバーログのクローラー分布

ページ数が多いことは、それ自体では強みになりません。Mueller氏の言葉を借りれば、Googleに知られているページが無限にあることは良いことではないのです。出すページを絞り込み、残したページに一次情報を持たせる——この2つを同時にやり切れるかどうかが、ポータル・比較サイトのSEOの成否を分けます。

本記事は、Google 検索セントラルの公開ドキュメント（クロールバジェットの管理、スパムに関するポリシー、レビュースニペットの構造化データ、アウトバウンドリンクの修飾）と、当サイトが報じたニュース記事で確認できた範囲の情報にもとづいて構成しています。件数の閾値など「運用上の目安」として示した数値は、Googleが定めた基準ではなく、サイトごとに調整すべき設計判断です。掲載企業のテンプレート展開に関する記述は、当サイトが2026年に公開した地域別記事21本の運営経験にもとづきます。Googleのドキュメントおよびガイドラインは更新されることがあるため、実装前に一次情報の最新版をご確認ください。

体裁	PDF／A4縦・全109ページ
収録	図解21点、チェックリスト120項目、90日実行プラン、用語集56語