ディレクトリサイトを構築する

ディレクトリサイトおよびリスティングプラットフォームは、私が実質的な規模で配信してきたプログラマティックSEOプロジェクトの特定のカテゴリです。HostList.io には、カテゴリ、地域、価格帯にわたってインデックスされた約28,000のウェブホスティング企業があり、すべて構造化データモデルからプログラマティックに生成されています。Not Another Sunday には137,000のイギリスのパブ、バー、レストランがあります。どちらも同じアーキテクチャパターンで動作しています。クリーンなデータモデル、テンプレート化されたページレンダラー、厳密なインデックス可能性ゲート、プログラマティック内部リンクグラフです。

このガイドは、2026年の検索エンジンの精査に耐えられるディレクトリまたはリスティングプラットフォームを構築する方法、何を避けるべきか、そして実務において間違っている従来のアドバイスの部分についてのオペレーターの見方です。個人的に複数のディレクトリプラットフォームを配信し、Seahawk Media のクライアント関与で得た実績から。

ディレクトリサイトが成功するのは、3つのことが同時に当てはまる場合です。競合する、または類似する多数の企業を持つ細分化された市場、比較意図で検索するオーディエンス(最高、トップ、対比、最安)、および既にSERPを支配している単一の支配的なアグリゲーターがない場合です。

うまくいった例：ウェブホスティング企業（分散化、比較型、Google所有の単一アグリゲーターがない）、ロンドンのレストラン（分散化、検索意図が強い、既存のアグリゲーターが弱体化している）、カテゴリ別のニッチなソフトウェアツール（分散化、比較サイトの品質にばらつきがある）。

うまくいかなかった例：Google自体が支配的なアグリゲーターである場合（求人、フライト、一部の市場における住宅ローン）、エンティティの数が少なすぎて数千ページをサポートできない場合（たとえば、単一都市のトップティア法律事務所）、比較基準があまりに主観的でデータモデルにエンコードできない場合。

最初から厳密に正規化する

すべてのエンティティ（企業、場所、製品）は、安定したIDと変わらないスラッグを持つ単一の正規行を取得します。すべての属性（カテゴリ、価格帯、地域、機能）は、自由形式のテキストフィールドではなく、独自のテーブルまたは列挙型を取得します。多対多の関係は結合テーブルを取得します。初日にこれを間違えるコストは、数年間のスラッグ不安定性と破損したリダイレクトです。

スラッグは永遠

ディレクトリページがGoogleによってインデックスされると、スラッグは変わりません。スラッグオブレコードパターンを使用します：エンティティ名からの決定論的な生成、数値サフィックスによる衝突処理、および任意の履歴スラッグを現在のものにマップして永続的な301リダイレクトを行うルックアップテーブル。HostList.ioには、3年間変わらないスラッグ安定性ルールがあります。

スケーリングするスキーマ設計

Supabaseの場合：マスターレコードを含むentitiesテーブル、categoriesテーブル、attributesテーブル、多対多用の結合テーブル、ユニークなcomputed_slugを生成するテーブルです。RLSポリシーは公開行の公開読み取り、管理者のみの書き込みを許可します。ページレベルで照会するすべての列にインデックスを設定します。HostList.ioのスキーマは大体12のテーブルで構成されており、起動以降は構造的な変更は必要ありませんでした。

1つのテンプレート、複数の顔

ディレクトリサイトには、大まかに6つのページアーキタイプがあります。エンティティページ、カテゴリ一覧、カテゴリ横断比較、地域ページ、ホーム、検索です。それぞれが1つのテンプレートで数千ページをレンダリングします。ルールはシンプルです。テンプレートを十分に優れたものにして、個別ページが特別な扱いを受ける必要がないようにすること、そして特例を作りたい衝動に抵抗することです。

ファーストビューのユニークさ

各エンティティページは、ファーストビューの上に唯一のコンテンツを持つ必要があります。唯一のオープニング段落、唯一の重要事実、唯一の価格またはフィーチャーデータです。唯一のコンテンツはデータモデルから自動生成できます（HostList.ioはこれを、テンプレート化されたオープニングで会社名、創業年、主要市場、差別化要因を1つ補間することで実現しています）。ただし、それはそのエンティティのために書かれたように読める必要があります。空欄を埋めるテンプレートではなく。

大規模なスキーママークアップ

すべてのエンティティページは、Organization または LocalBusiness スキーマを出力します。名前、URL、住所（適用可能な場合）、aggregateRating（本当に利用可能な場合）、検証済みのソーシャルプロフィールへの sameAs リンクを含みます。すべてのカテゴリページとエンティティページに BreadcrumbList を配置します。すべてのカテゴリ一覧に ItemList を配置します。スキーマレイヤーは、Google と AI サーフェスの両方にとってディレクトリをマシンリーダブルにするものです。

Helpful Content Update はディレクトリサイトにとって単一最大の脅威であり、プログラマティックサイトでドメイン全体のランキング崩壊を引き起こす最も一般的な原因です。対策は、どのページがインデックス可能な価値があるかを決定するページごとのインデックス可能性ゲートです。

ページあたりの品質閾値

コンテンツ品質閾値を下回るページは、サイトの残りの部分がどのように構成されているかに関わらず、ページ自体に noindex を設定します。適用している品質閾値の例：ユニークコンテンツの最小単語数（HostList.ioでは300単語）、入力されているストラクチャドデータフィールドの最小数（ホスティング企業では12のうち8）、そのページを指す内部リンクの最小数（他のエンティティまたはカテゴリページからの3つの受信リンク）。

サイトマップはゲートの後に従う

サイトマップは、ゲートされたページを除外します。サイトマップはGoogleにインデックスしたいページを伝える最も信頼性の高いシグナルです。サイトマップから除外されているがクロール経由で到達可能なページは、クロール頻度が低く、ランク付けが弱くなります。サイトマップの規律は、インデックス対象の表面をクリーンに保ちます。

ロボットとnoindeｘは階層化されている

インデックス性の決定にrobots.txtを使用しません。robots.txtはクロール全体をブロックするため、Googleがnoindeｘヘッダーを受け入れる能力を削除します。正しいパターンは、クロールを許可し、メタロボットヘッダー経由でゲートされたページにnoindeｘを設定し、サイトマップから除外することです。

プログラマティックリンク、プログラマティックに

ディレクトリスケールでは、内部リンクは手作業でキュレーションするのではなく、生成する必要があります。各エンティティページは、親カテゴリ、兄弟エンティティ（同じカテゴリ、類似の属性）、該当する地域ページ、およびホームへのリンク先です。各カテゴリページは、子エンティティ、親カテゴリ、および横方向カテゴリにリンクします。グラフはビルド時に計算され、エンティティが追加または削除されるたびに更新されます。

アンカーテキストの多様性

内部アンカーテキストは変動する必要があります。8,000ページを同じアンカーテキストのカテゴリページにリンクすることは、強いネガティブシグナルです。アンカーテキストをテンプレートのセット全体で回転させます：「[カテゴリ]企業」、「最高の[カテゴリ]サービス」、「[地域]の[カテゴリ]」、「[エンティティ]の代替案」。回転は送信元ページごとに決定的に行われるため、グラフは再ビルド全体で安定しています。

段落ごとに3つ以下の内部リンク

内部リンクが多いことは問題ありません。ただしリンクの集中はページを自動生成したように見せてしまいます。段落ごとに3個まで、ページ全体で30個までの内部リンク数に制限し、残りはページ全体に分散させます。この規律は編集的なものであり、テンプレートレベルで適用されます。

定期的な再検証を伴う静的レンダリング

Next.jsの場合：ビルド時の静的生成、エンティティページに対する24時間の再検証ウィンドウを持つISR、管理画面を通じてエンティティが更新された際のオンデマンド再検証。Vercelは28,000ページを問題なく処理します。コストの変動要因はISR書き込みイベントであり、これを管理可能に保つため、コンテンツの細かい調整のたびではなく、エンティティの変更に限定して再検証をゲートします。

データベース接続プーリング

ページテンプレートからの直接的なSupabaseクエリはスケールしません。フルリビルド中に接続制限に達します。静的生成パターンを使用しています。ビルド時に数個の大きなクエリですべてのページを取得し、メモリ内データからページを生成します。ページレンダリングがデータベースに直接アクセスすることはありません。HostList.ioの28,000ページに対して、リビルド時間は10分以下に保たれています。

CDNとエッジキャッシング

オリジンの前には常にCloudflareがあります。無料ティアはディレクトリトラフィックを快適に処理します。有料ティアはトラフィックが必要とする場合、グローバルルーティングのためのArgoを追加します。CDNキャッシングにより、一般的なディレクトリトラフィックプロファイルで、オリジンの負荷は公開トラフィックの約5%に低下します。

運営しているすべてのディレクトリサイトについて、週次でチェックする3つのメトリクスがあります。

インデックス済みページと公開ページ

Search Console > Pages > インデックス済みをサイトマップ数と比較。健全：90%以上。80%未満：Googleがシグナル品質に懸念があり、ゲーティング閾値を見直す必要があります。70%未満：構造的問題。コンテンツが薄い、またはインテント重複の可能性が高い。

テンプレートアーキタイプ別の平均掲載順位

Search Consoleをエンティティ・カテゴリ・地域別にURLパターンでフィルタリングおよびセグメント化。どのテンプレートが機能していて、どのテンプレートがドメインを足引っ張っているかがわかります。HostList.ioではこのメトリクスを使用して、7日以内にテンプレート回帰を検出したことがあります。

インデックス済みページあたりのクリック数

総クリック数をインデックス済みページ数で割ったもの（週単位）。健全なディレクトリサイト：0.3～1.5。0.2未満：インデックスが広すぎて、トラフィックのないページがドメインを希薄化している。ゲーティングを厳しくしてください。

私が監査したディレクトリサイトを潰した5つのミス：

1. コンテンツ追加時に残らなかった手動キュレーション型の内部リンク。グラフは初日からプログラム的である必要があります。

2. エンティティ名が修正されたときに変更されたスラッグ。1つのスラッグ変更でも301なしで大幅なランキングシグナル喪失。10個のスラッグ変更は致命的になる可能性があります。

3. ユニークなコンテンツがないインデックス可能ページ。Helpful Content Updateはカテゴリページがすべて同じボイラープレートのように見えるディレクトリに容赦がありません。

4. 偽造または検証不可能な評価を含むAggregateRatingスキーマ。Googleはこれを検出し、グローバルにスキーマを過小評価します。AggregateRatingは評価が実在し、検証可能な場合にのみ使用してください。

5. ディレクトリを立ち上げプロジェクトではなく、継続的な運用の課題として扱わないこと。ディレクトリは継続的なメンテナンスが必要です。古いエンティティの削除、新しいエンティティの追加、外部リンク切れの削除、スキーマの同期を保つ必要があります。これがないと、ディレクトリは12～24ヶ月で劣化します。

2026年に成功するディレクトリサイトは、クリーンなデータモデル、規律あるテンプレートレンダラー、厳格なインデックス可能性ゲート、プログラム的な内部リンクグラフ、そして継続的な運用管理です。アーキテクチャは繰り返し可能です。変わるのはデータ品質と、どのエンティティとカテゴリがインデックス可能なサーフェスに値するかについての編集上の判断です。

初日にこのすべてを行う必要はありません。まだ構築していないものがどれかを知り、Googleが気づく前に次のものを修正する必要があります。

Seahawk Mediaではディレクトリおよびリスティングプラットフォームを18,000 USDから構築しています。HostList.ioのケーススタディは大規模なパターンを示しています。あなたの特定のディレクトリがどのようになるべきかについての相談は無料です。