薄いコンテンツペナルティを受けずに28,000ページを超えるディレクトリサイト。

構造化データソースがあれば、ほぼどんなディレクトリ形態でも構築できます。過去2年間に納品してきたパターンは、大きく4つの類型に分かれており、ほとんどのクライアント案件はそのいずれかの変種です。

業界ディレクトリは、特定の業界内の企業を、カテゴリー、地域、規模、機能セットで分類して掲載します。HostList.ioはその典型例で、自分で運営しています。約28,000のウェブホスティング企業を、ホスティングタイプ、地域、価格帯、ユースケースで分割しています。購入者はプロバイダーを見つけ、プロバイダーはトラフィックを獲得し、ディレクトリ自体はスポンサー枠、アフィリエイトリンク、あるいは有料プレミアムリストなど、業界に適した方法でマネタイズします。

ローカルディレクトリと地域ディレクトリが2番目のパターンです。レストランガイド、パブガイド、歯科医ディレクトリ、工事業者ディレクトリ。各掲載にはLocalBusinessスキーマが付与されており、データ利用権がある場合は地理座標、営業時間、評価が含まれます。「マンチェスターの最高のイタリアンレストラン」や「ストーク・ニューイントンのパブ」といったプログラマティック生成のシティ・カテゴリーページが、これらのサイトのロングテールSEO流入の大部分を占めます。

ツール・ソフトウェアディレクトリは、ソフトウェア製品をカテゴリー内に掲載します。CRMツール、プロジェクト管理アプリ、ノーコードプラットフォーム、AIツール。これらのトラフィックエンジンは、比較ページ（NotionとLinearとClickUpの比較など）と機能マトリックスページです。検索者はすでに製品名を知っており、決め手が欲しいだけです。

人物・サービスディレクトリが4番目のパターンです。エージェンシー、フリーランサー、コンサルタント、フォトグラファー、弁護士。このパターンの課題は、ほとんどの人物ディレクトリは掲載情報が古くなり、誰も更新しなくなるため失敗することです。プロジェクト開始時からセルフサービスのプロフィール編集機能と有効期限ワークフローを組み込んでおり、後から対応する方式は取りません。

HostList.ioは、ウェブホスティング業界全体をカタログ化するために、個人で構築したディレクトリです。約28,000のホスティング企業ページが2024年春より運用されており、クライアント向けディレクトリ構築に現在使用しているNext.js、Supabase、Vercelスタックと同じ構成です。

HostList.ioがすることは、検証可能なすべてのウェブホスティング企業をカタログ化し、タイプ（共有、VPS、マネージドWordPress、クラウド、デディケーテッド、リセラー）、地域、価格帯、ユースケースで分類することです。特定のホスト間の比較ページ、各セグメントのカテゴリーページ、28,000行のデータセットをクエリレイテンシーなしで処理する検索・フィルターUI、各掲載のスキーママークアップ、そしてURL数がすでに単一のsitemap.xmlで保持できる上限を超えているためのストリーミングサイトマップがあります。

ほぼすべてのクライアント向けディレクトリ構築は、HostList.ioの運用から得られた3つの教訓に形作られています。第1に、データ品質がすべてです。エンティティ名を超えた3つのユニークなデータポイントを持つページはGoogleアップデートを生き残りますが、名前と汎用的な説明だけのページはインデックス削除されます。第2に、このスケールではバックリンクより内部リンクが重要です。掲載、カテゴリー、比較ページ間のリンクグラフが、ページがインデックスを保つのに十分なクロール頻度でクロールされるかを決定します。第3に、プログラマティックは怠け心ではありません。すべてのページに存在理由が必要です。「データベースに行がある」では理由になりません。

約15％のデータベースレコードはインデックスから外しました。ユニークデータのしきい値に達していないためです。掲載が5つ未満の強力なエントリーを持つカテゴリーページはカットしました。スキーマが正しくても、薄く見えるためです。名前付き競合社間の比較ページを別のページタイプとして追加しました。そのテンプレートはサイト上で最も高いコンバージョンを生み出したトラフィックのいくつかになりました。同じプレイブックは現在、クライアント向けに納品するすべてのディレクトリの標準になっています。

多くのディレクトリが失敗しており、失敗パターンは予測可能なほど明らかなので、ほとんどの場合、最初の電話通話で案件がどの失敗パターンに向かっているか判断できます。

シンコンテンツの検索削除が最も一般的な失敗だ。あるディレクトリが5000件のリスティングで立ち上がり、そのうち半分は名前と1行の説明しかなく、Googleは最初の1500件をインデックスしてから止まる。そのサイトは手をかけていないスクレイプに見える。6ヶ月後、インデックスされたページの大半がコアアップデートで削除される。修正はデータ収集の段階で行う必要がある — すべての行がサイトマップの対象になる前に3つのユニークなデータポイントが必要で、「後で埋めるから」では駄目だ。

古いデータのドリフトが2番目のパターンだ。2023年に正確なビジネスをリストしていたディレクトリが、2026年には半ば廃業しているビジネスをリストしている。誰も行を更新しないため、連絡先情報が古くなり、ウェブサイトはパーキングページに解決され、ディレクトリはGoogleと人間の訪問者の両方から信頼シグナルを失う。クラウドソースの編集フローを構築して、リストされたビジネスがプロフィールを請求・編集できるようにするか、自動化された鮮度チェックで死んだリスティングを無効化するか、またはその両方を行う。鮮度レイヤーがないと、元のデータがどんなに良かったとしてもディレクトリは関連性を失う。

防御線がないのが3番目のパターンだ。3つの競合ディレクトリが同じバーティカルを同様のデータでカバーしている。どれもユニークなデータを持っていないため、どれにも存在する防御可能な理由がない。検索シェアが分断され、どれもランクしない。修正はエディトリアルレイヤーだ — 元データだけでは提供できない、オリジナル分析、スコアリング、推奨事項、比較フレームワークだ。HostListはホスティングリスト自体が特に防御可能ではないため、ホスティングリストではなくスコアリングルーブリックで競争する。

フィルターによるインデックスブロートが4番目のパターンだ。8つのフィルター次元を持つディレクトリは理論的には数百万のURL組み合わせを生成できる。すべての組み合わせがインデックス可能だと、Googleにシンコンテンツページを大量に送り込み、強力なものを希薄化する。シンフィルター組み合わせをインデックスからブロックする — 3件未満のリスティングを持つものはnoindexa、ソート順序やページ2以降のような実際のクエリインテントがないものはnoindex、実際の検索にマップする正規フィルター組み合わせだけがインデックス可能なままだ。

ディレクトリのリファレンスアーキテクチャは5つのレイヤーで配信される。各プロジェクトは細部をフレックスするが、スパインはビルド全体で繰り返される。

データレイヤーはSupabaseまたはセルフホストされたPostgresで、すべてのファセット列に適切なインデックスがある。エンティティタイプごとに専用のリスティング表がある — 企業、製品、ロケーション、人物 — 、コンテンツの横に品質ゲート列がある（ユニークネススコア、完全性パーセンテージ、最終検証タイムスタンプ）。サイトマップ適格性ビューは品質閾値以下の行を自動的にフィルターする。

ページテンプレートは、リスティング詳細ページ（完全なデータ、関連リスティング、スキーマ、パンくず）、カテゴリページ（フィルターUIと ItemList スキーマ付きのページネーション付きリスト）、指定されたエンティティ間の比較ページ、地理が重要な場所ページ（マップ埋め込みとジオスキーマ付き）、および元のエディトリアルウェイトを担う about とメソッドロジーページに分かれている — 元データは提供できない。

検索とフィルターは約10000件のリスティングまで Postgres フルテキスト検索を使用し、その後は低いクエリレイテンシー要件を持つより大きなディレクトリ用に Algolia または Meilisearch を使用する。サーバーレンダリングされたフィルターURLはすべてのフィルター組み合わせに正規を与え、シンまたは重複する組み合わせの noindex はインデックスブロートを防ぐ。サブミッションとモデレーションは、公開サブミッションフォーム（モデルがクラウドで供給される）、品質ゲートスコアがモデレーター評価用に表示される管理キュー、特定の理由を持つテンプレート化された却下メール、およびリストされたエンティティが自分のプロフィールを請求・更新するセルフサービス編集フローを取得する。

SEO スキャフォルディングはディレクトリが生き残るかどうかを決めるレイヤーだ。チャンクパーテンプレートパターンを持つストリーミングサイトマップ、すべてのリスティングに適切な schema.org Organization または Product または Place または Service または LocalBusiness 、カテゴリページの CollectionPage と ItemList 、どこでも BreadcrumbList 、単一の真実のソース（テンプレートではなくデータベース）から発行された正規URL、および H1 が欠落している、メタ説明が大きすぎる、または JSON-LD が無効なビルドで失敗する build-time SEO linter 。

マネタイゼーションはフィーチャーされたリスティング（ブール値フラグが行をカテゴリページの最上部に昇格させる）、スポンサー付きカテゴリプレースメント（ブランドが請求期間のカテゴリの上部を所有する）、適切な rel="sponsored" 属性を持つアフィリエイトリンクトラッキング、およびリストされたエンティティがより良いプレースメント、より多くのリッチデータフィールド、および分析アクセスを取得するための有料プレミアムティアを通じて行われる。

ディレクトリプロジェクトにおいて最も重要な変数は、データソース自体です。ほとんどのエンゲージメントは一つの質問への答えで成功するか失敗するかが決まります。初日のデータはどこから取得し、ローンチ後はどのように最新の状態を保つのか、という質問です。

手動編集は、チームがすべてのリスティングを作成します。遅く、高くつきますが、防御可能です。1,000件未満のリスティングに適しています。成功した例として見てきたもの：ハイエンドホテルガイド、キュレーションされたエージェンシーディレクトリ、掲載されること自体が価値であるニッチな編集サイト。

構造化インポートは、信頼できるところからCSVまたはデータベースエクスポートを取得し、当社がクリーニング、重複排除、エンリッチメント、取り込みを行います。1,000件から10万件のリスティングに適しています。例：公開データがある業界ディレクトリ、政府登録のインポート、企業登記風のエクスポート。

自動スクレイピングまたはAPIは、サードパーティのAPIまたは適切なスクレイピングパイプラインからリスティングが取り込まれます。法的かつ倫理的にはソースに依存します。データが既知の正規の場所に存在する、1万件から数百万件のリスティングに適しています。例：GitHubから取得した開発者ツールディレクトリ、企業サイト自体の公開レビューからスクレイピングされたホスティングレビュー。

ユーザー投稿は、リスティング対象の人々からリスティングが提供されます。ローンチは安く、モデレーションは高くつきます。編集シードデータの上に追加する層として最適であり、唯一のソースとしては最適ではありません。ハイブリッドパターン（編集シード＋構造化インポート＋年次編集レビュー）は、HostListが実行していて、ほとんどの実際のディレクトリが計画しているかどうかに関わらず最終的に採用しているものです。

最初の呼び出しで、どの組み合わせがあなたのデータ実態と一致するかを尋ねます。明確な答えがない場合、データの質問自体が最初のフェーズの仕事になり、構築はその後です。

営業資料の野心的な価格設定ではなく、最近の実際のエンゲージメントに基づいた正直な範囲です。1,000件未満のリスティングを持つ小規模な編集ディレクトリは、6～9週間で18,000～35,000米ドル。構造化データインポートを伴う1～10万件のリスティングの中規模ディレクトリは、10～14週間で30,000～60,000米ドル。10～100万件のリスティングの大規模ディレクトリ、プログラマティックスケールは、12～18週間で50,000～90,000米ドル。マーケットプレイス型（両面、予約またはトランザクション付き）は、14～22週間で60,000～150,000米ドル。

すべての範囲にはSEOスキャフォールディング（スキーマ、サイトマップ、リンター）、検索・フィルターレイヤー、基本的な管理ダッシュボードが含まれます。データ取得自体（手動編集、スクレイピングインフラストラクチャ、サードパーティAPI費用）、オリジナルのブランドおよび設計作業、または有料トラフィック取得は含まれません。ローンチ後の継続的な運用のためのケアプランは、月間500～3,000米ドルです。