ディレクトリウェブサイト構築：CMSツールが10,000件のリスティングで失敗する理由
ディレクトリウェブサイトを構築する：CMS ツールが 10,000 件のリスティングで機能しなくなる理由
私は少なくとも十数回このシナリオを見てきました。誰かが Webflow または WordPress 上にディレクトリを構築し、500 件のリスティングで美しく機能し、2,000 件でもまだ問題なく、そして 8,000～10,000 件のエントリ付近のどこかで、全体が息をするのを始めます。検索は遅くなります。フィルターはタイムアウトします。ビルド時間は数分に延びます。1 ヶ月目で完璧に感じた CMS が、8 ヶ月目で必死に逃げようとするボトルネックになります。
根本的な問題は何か？CMS ツールはコンテンツ向けに設計されました。ブログ記事、ランディング ページ、おそらく数百 SKU の製品カタログです。ディレクトリ ウェブサイトは根本的に異なる獣です。複雑なフィルタリング、ファセット検索、地理情報クエリ、ユーザー生成コンテンツ、およびページビューごとのデータベース ヒット数を桁違いに乗算するページネーション パターンが必要です。ディレクトリをより多くの投稿を持つブログとして扱うことは、予想より速く追いつく建築上の誤りです。
これが起こる理由、2025 年の実際の技術的制限、および 10,000 件のリスティングを超えてスケーリングしたい場合に代わりに構築すべきものについて、正確に説明します。
目次
- ディレクトリはブログではありません
- 主要 CMS プラットフォームが壁にぶつかる場所
- 技術的現実：10K がブレークポイントである理由
- 実際に機能するもの：スケーリング用アーキテクチャ
- ディレクトリ ウェブサイトへのヘッドレス アプローチ
- コスト比較：CMS vs. ヘッドレス vs. カスタム
- 実世界のマイグレーション パス
- FAQ
ディレクトリはブログではありません
これは明らかなように聞こえますが、ほとんどのプロジェクトが計画段階で間違う場所です。ブログ投稿は単一のドキュメントです。スラッグで取得してレンダリングします。終わりです。ディレクトリ リスティング ページは全く異なることを行います。潜在的に数千のレコードをクエリし、複数のフィルター (カテゴリ、場所、価格帯、評価、可用性) を同時に適用し、結果をソートしてページネーションしてページをレンダリングします。通常、マップ マーカー、距離計算、および各フィルター オプションの集計カウントがあります。
ページビューあたりのデータベース操作の簡単な比較をここに示します：
| 操作 | ブログ投稿ページ | ディレクトリ リスティング ページ |
|---|---|---|
| プライマリ クエリ | 1 (スラッグで取得) | 1 (フィルタリング、ソート、ページネーション) |
| 関連クエリ | 2-3 (著者、カテゴリ、関連投稿) | 5-15 (フィルター カウント、地理計算、レビュー、可用性) |
| インデックス ルックアップ | 1-2 | 10-50+ (ファセットあたり) |
| スキャンされた行 | 1-5 | 100-10,000+ |
| 標準的な応答時間 | 5-50ms | 200-2,000ms (最適化されていない) |
| キャッシュ無効化の複雑性 | 低 (単一ドキュメント) | 高 (リスティングの変更により複数ページに影響) |
従来の CMS を使用している場合、これらの操作はすべて同じデータベース、同じクエリ エンジン、ホームページ、About ページ、および管理パネルも処理している同じサーバーを通じて行われます。500 件のリスティングでは問題になりません。10,000 件では大いに問題になります。
主要 CMS プラットフォームが壁にぶつかる場所
特定の内容と場所を見てみましょう。
Webflow
Webflow は、ビジネス プランで コレクションあたり 10,000 CMS アイテムのハード キャップ を強制します。これはソフト ガイドラインではありません。それは壁です。それに達して、別のリスティングを追加することはできません。Webflow チームは、このコミュニティ フォーラムで、このこの制限は「パフォーマンス上の理由」で存在し、変わらないことを確認しています。
しかし、ほとんどの人が見逃していることはここにあります。5,000～6,000 件のアイテムを超える複雑なコレクション リストとフィルターを使用すると、ビルド時間が 10 分を超えて伸び、ページの読み込みが遅くなり始めることに気付きます。Webflow の CMS はファセット検索用に構築されていません。「今開いており、ビーガンオプションがある 5 マイル以内のすべてのレストランを見せてください」というネイティブ クエリを行う方法はありません。
2026 年 3 月の時点で、Webflow のビジネス プランは (年間請求) で月額 $39 です。アドオンで 20,000 アイテムに引き上げたいですか？それは月額 $124 になります。アイテムを 2 倍にするための基本価格の 3 倍以上です。100K 以上のアイテムのエンタープライズ価格は年間 $15,000～$50,000 の範囲で始まります。
WordPress
WordPress にはハード アイテム キャップはありませんが、より悪い何かがあります。予測不可能な劣化です。Directorist または Business Directory Plugin などのディレクトリ プラグインを備えた標準的な WordPress インストールは、一般的な共有またはVPS ホスティングで 10,000 件のリスティング付近で問題が生じ始めます。原因は MySQL クエリ パフォーマンスです。
WordPress はすべてを保存します。投稿、カスタム フィールド、タクソノミー、メタデータは、ごくわずかなデータベース テーブルに保存されます。20 個のカスタム フィールドを持つディレクトリ リスティングは、リスティングあたり wp_postmeta に 20 行を意味します。10,000 件のリスティングで、それだけで postmeta に 200,000 行です。WordPress はこれらのテーブル全体で JOIN クエリを行うのが大好きです。WooCommerce またはpostmeta にデータを詰め込む他のプラグインを追加すると、本当に混乱します。
10K 件のリスティングでも正常に機能する WordPress ディレクトリ サイトを見てきました。ただし、重要な最適化後のみです：Redis オブジェクト キャッシング、Elasticsearch 検索、専用データベース サーバー、および慎重なクエリ最適化。その時点で、ホスティング インフラに月額 $200～500 を費やしていて、本質的にプラットフォームと協力するのではなくプラットフォームに対抗しています。
Airtable / Notion / Google Sheets を「バックエンド」として
このパターンは、インディー ハッカー コミュニティ内で頻繁に見かけます。Airtable をデータベースとして使用し、静的サイト ジェネレータまたは Webflow を通してパイプし、ディレクトリができました。それは機能します！そうでなくなるまで。
Airtable の API は、リクエストあたり最大 100 レコードを返します。彼らの無料プランは、ベースあたり 1,200 レコードでキャップされています。彼らのビジネス プラン ($20/ユーザー/月) でさえ、ベースあたり秒あたり 5 リクエストのレート制限に達します。10,000 件のリスティングでディレクトリ ページをレンダリングしようとしていて、単一ページが読み込まれる前に 100 の連続 API 呼び出しを行っています。それはディレクトリではありません。それは読み込みスピナーです。
技術的現実：10K がブレークポイントである理由
10,000 件のリスティングのしきい値は恣意的ではありません。一般的な CMS 構成の下でデータベースがどのように動作するかの段階転移を表しています。
クエリの複雑さが爆発する
10K リスティングでは、一般的なフィルター ディレクトリ クエリが次のことを行う必要があります：
- テーブル (またはインデックス) の潜在的に大きな部分をスキャンしてフィルターを適用する
- 残りのフィルター オプションの集計カウントを計算する (「ホテル (247)、レストラン (1,832)」)
- 結果を関連性、距離、または評価でソートする
- ページネーションして部分集合を返す
- 関連データ (画像、レビュー、カテゴリ) に参加する
適切にインデックスされた PostgreSQL データベースと適切なスキーマ設計では、これは 10～50ms で完了します。WordPress の wp_posts + wp_postmeta スキーマと EAV パターン クエリ？簡単に 500～2,000ms です。コンテンツ ページ用に設計された Webflow の内部データ層上？彼らがキャップを強制する理由です。
ビルド時間は開発者体験を殺す
静的サイト ジェネレーター (Webflow と多くのヘッドレス セットアップの両方が使用) は、すべてのリスティング、すべてのカテゴリ ページ、フィルター処理されたすべての組み合わせのページを構築する必要があります。10,000 件のリスティングで 50 個のカテゴリ ページがある場合、最低でも 10,050 以上の静的ページを生成しています。Webflow では、ビルドは 20 分を超える可能性があります。Next.js を getStaticPaths で使用すると、Incremental Static Regeneration (ISR) を使用していない限り、完全な再構築で 15～30 分待ちます。
// 素朴なアプローチ：ビルド時にすべての 10K ページをビルド
export async function getStaticPaths() {
const listings = await fetchAllListings(); // 10,000 items
return {
paths: listings.map(l => ({ params: { slug: l.slug } })),
fallback: false // すべてのページを事前にビルド
};
}
// スマートなアプローチ：オンデマンドでビルド
export async function getStaticPaths() {
// 最も閲覧数の多い上位 100 件のリスティングのみを事前ビルド
const topListings = await fetchTopListings(100);
return {
paths: topListings.map(l => ({ params: { slug: l.slug } })),
fallback: 'blocking' // 最初のリクエストで他をビルドしてからキャッシュ
};
}
検索が本当の問題になる
複数のフィールド (名前、説明、タグ、場所、カテゴリ) にわたる 10,000 以上のリスティング全体での全文検索は、ほとんどの CMS ツールが完全に失敗するところです。WordPress のデフォルト検索は LIKE %term% クエリです。リテラルにすべての行をスキャンします。Webflow のネイティブ フィルタリングは全文検索をサポートしていません。
実際のディレクトリ検索が必要です：
- ファジー マッチング (誰かが「piza」と入力したときに「pizza」を見つける)
- 加重関連性 (タイトル マッチは説明マッチより高くランク付けされます)
- ファセット カウント (カテゴリ/フィルターあたりの結果数)
- 地理距離ソート
- 200 ミリ秒未満の応答時間
このには検索エンジンが必要です。Elasticsearch、Meilisearch、Typesense、または Algolia。これらのいずれも従来の CMS に組み込まれていません。
実際に機能するもの：スケーリング用アーキテクチャ
10,000 件以上のリスティングを処理する必要があるディレクトリを構築している場合、初日から関心事を分離する必要があります。
適切なデータ レイヤー
リスティングは、特定のクエリ パターン用に設計されたスキーマを持つ適切なデータベースに属します。CMS コンテンツ モデルではなく、スプレッドシートではなく、メタデータが固定されている汎用 posts テーブルではありません。
-- 目的のビルド リスティング テーブル
CREATE TABLE listings (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name TEXT NOT NULL,
slug TEXT UNIQUE NOT NULL,
description TEXT,
category_id UUID REFERENCES categories(id),
location GEOGRAPHY(POINT, 4326), -- 地理的クエリのための PostGIS
price_range INT CHECK (price_range BETWEEN 1 AND 4),
rating DECIMAL(3,2),
is_verified BOOLEAN DEFAULT false,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
-- ディレクトリ クエリ パターン用の適切なインデックス
CREATE INDEX idx_listings_category ON listings(category_id);
CREATE INDEX idx_listings_location ON listings USING GIST(location);
CREATE INDEX idx_listings_rating ON listings(rating DESC);
CREATE INDEX idx_listings_search ON listings USING GIN(
to_tsvector('english', name || ' ' || COALESCE(description, ''))
);
PostgreSQL と PostGIS は 100,000 件以上のリスティングを問題なく処理します。Supabase はこれをボックスの外で、寛大な無料ティアと数百万行にスケーリングします。これは、私たちがヘッドレス CMS 開発プロジェクトで実装している種類のデータ アーキテクチャです。CMS は編集コンテンツを処理し、データベースはスケーリングで構造化データを処理します。
ストレージから検索を分離する
プライマリ データベースに検索を処理させないでください。リスティングを専用検索サービスに同期します：
| 検索サービス | 無料ティア | 10K 以上のレコードでの価格 | レイテンシ | 最適な用途 |
|---|---|---|---|---|
| Algolia | 10K 検索/月 | $1/1K リクエスト + $0.40/1K レコード | <50ms | 最大速度、ファセット |
| Typesense | セルフホスト (無料) | クラウド：$29.50/月 (最大 500K レコード) | <50ms | 予算に優しい、オープンソース |
| Meilisearch | セルフホスト (無料) | クラウド：$30/月 (100 万ドキュメント) | <50ms | シンプル なセットアップ、優れたデフォルト |
| Elasticsearch | セルフホスト (無料) | Elastic Cloud：~$95/月 | <100ms | 複雑なクエリ、成熟したエコシステム |
Typesense と Meilisearch は両方ともで 2025 年を通じて成熟しました。100K 件のリスティング未満のほとんどのディレクトリ プロジェクトでは、Typesense Cloud ($29.50/月) で、即座検索、ファセット、地理検索、およびタイプミス耐性を提供します。速度は遅すぎます。
ディレクトリ ウェブサイトへのヘッドレス アプローチ
10,000 件のリスティングを超えることを予期しているディレクトリの場合、推奨するアーキテクチャは次のとおりです：
- フロントエンド：パブリック向けサイト用の Next.js または Astro
- CMS：編集コンテンツ (ホームページ、概要、ブログ、ヘルプ記事) 用の Sanity、Contentful、または Payload
- データベース：リスティング データ用 PostgreSQL (Supabase または Neon 経由)
- 検索：検索とフィルタリング用の Typesense または Meilisearch
- 管理インターフェース：リスティング管理用のカスタム ダッシュボードまたは Retool
これは、私たちがクライアント向けに定期的に構築するスタックです。フロントエンド フレームワークはレンダリングとルーティングを処理します。CMS はエディターが管理する必要があるコンテンツを処理します。データベースは構造化された大量のリスティング データを処理します。検索エンジンはディレクトリが要求するクエリ パターンを処理します。
Next.js を使用すると、リスティング詳細ページ用の ISR (Incremental Static Regeneration) (オンデマンドでビルド、エッジでキャッシュ、変更時に再検証) とサーチ/フィルター ページ用のサーバー側レンダリング (常に新しい結果、高速応答) が得られます。Astro を使用すると、頻繁に変わらないリスティング用の高速な静的ページが得られ、検索とフィルタリングのインタラクティビティの島があります。
// Next.js App Router：リスティング ページの ISR
export async function generateStaticParams() {
// インスタント読み込み用にトップ リスティングのみを事前ビルド
const topListings = await db
.select({ slug: listings.slug })
.from(listings)
.orderBy(desc(listings.pageviews))
.limit(500);
return topListings.map(l => ({ slug: l.slug }));
}
export const revalidate = 3600; // 1 時間ごとに再検証
export default async function ListingPage({ params }) {
const listing = await db
.select()
.from(listings)
.where(eq(listings.slug, params.slug))
.limit(1);
if (!listing[0]) notFound();
return <ListingDetail listing={listing[0]} />;
}
なぜすべてに CMS を使用しないのか？
CMS プラットフォームはデータ操作ではなく編集ワークフロー用に最適化されているためです。CMS は、リッチ テキスト編集、ドラフト/公開ワークフロー、コンテンツ スケジューリング、ローカライゼーション、およびロール ベース アクセス許可を提供します。これらはブログ投稿とマーケティング ページに不可欠です。
ディレクトリ リスティングはこれを必要としません。一括インポート/エクスポート、構造化検証 (これは有効な電話番号ですか？)、重複排除、自動エンリッチメント (Google Places データを取得)、10,000 件のリスティング ウェブサイトを構築または同時に 500 件の書き込みを処理する機能を必要とします。これはコンテンツ操作ではなくデータベース操作です。
誤りは、コンテンツ管理とデータ管理を混同することです。これらは異なる問題であり、異なるソリューションがあります。
コスト比較：CMS vs. ヘッドレス vs. カスタム
25,000 件のリスティングでディレクトリを実行するための実際の月額コストを見てみましょう：
| コスト カテゴリ | Webflow (エンタープライズ) | WordPress (最適化) | ヘッドレス (Next.js + Supabase) | 完全なカスタム |
|---|---|---|---|---|
| ホスティング/プラットフォーム | $1,250-$4,166/月 | $100-300/月 (管理 WP) | $20/月 (Vercel Pro) | $200-500/月 (クラウド インフラ) |
| データベース | 含まれる (限定) | 含まれる (MySQL) | $25/月 (Supabase Pro) | $50-200/月 (管理 PG) |
| 検索 | ネイティブで利用不可 | $0-95/月 (Elasticsearch) | $29.50/月 (Typesense Cloud) | $95-300/月 (Elasticsearch) |
| CMS | 含まれる | 無料 (WP コア) | $0-99/月 (Sanity/Payload) | N/A |
| CDN/エッジ | 含まれる | $0-20/月 | 含まれる (Vercel) | $20-50/月 |
| 月額合計 | $1,250-$4,166 | $100-415 | $75-175 | $365-1,050 |
| ビルド コスト | $5K-15K | $3K-10K | $15K-40K | $50K-150K+ |
ヘッドレス アプローチの初期ビルド コストは、WordPress プラグインを一緒にスラップするよりも高いことは疑いなしです。しかし、継続的なコストは Webflow Enterprise より劇的に低く、アーキテクチャは実際に成長をサポートします。25K から 100K にリスティングに行くと、Supabase プランと検索ティアをバンプします。それだけです。再アーキテクチャなし、移行パニックなし。
特定のプロジェクトのコストを評価している場合、私たちの価格ページはエンゲージメント モデルを内訳にしているか、ディレクトリの要件について話し合うために直接連絡できます。
実世界のマイグレーション パス
既に CMS の限界に立ち往生している場合、実用的なマイグレーション シーケンスは次のとおりです：
フェーズ 1：データを抽出する (1-2 週目)
CMS からすべてをエクスポートします。Webflow の API と CSV エクスポートが機能します。WordPress には wp-cli export があります。リスティングをクリーンな CSV または JSON 形式で取得します。
フェーズ 2：新しいデータ レイヤーを設定する (2-3 週目) 適切なスキーマ設計で PostgreSQL にインポートします。Typesense を設定してデータを同期します。検索品質とクエリ パフォーマンスを確認します。
フェーズ 3：新しいフロントエンドを構築する (3-8 週目) 新しいバックエンドに対して検索、フィルタリング、リスティング詳細ページ、およびカテゴリ ページを再構築します。Next.js または Astro は、データ アーキテクチャ全体を変更している間、既存のデザインを複製できる場所です。
フェーズ 4：CMS を良いことに保つ (継続的) ホームページ コンテンツ、ブログ投稿、ヘルプ記事、および編集コンテンツに CMS を使用します。データベースがリスティングを処理します。彼らは平和に共存します。
フェーズ 5：リダイレクトして起動 (8-10 週目) 古い URL から 301 リダイレクトを設定し、Google Search Console で確認し、監視します。URL 構造が同じままの場合 (そうすべき)、SEO 資産を保持します。
FAQ
Webflow は本当に大規模なディレクトリ ウェブサイトを処理できますか？
Webflow は 5,000 件以下のリスティングを備えたディレクトリに適しています。5K から 10K の間、ビルド時間とページの読み込みのパフォーマンス ドラッグを感じます。10,000 でハード キャップに達します。ディレクトリが小さいままで、Webflow のビジュアル デザイン ツールの価値を感じるなら、それで大丈夫です。成長を予期している場合は、別のアーキテクチャで開始します。
10,000 以上のリスティングでディレクトリを構築する最も安い方法は？
WordPress を品質の高いホスティング (Cloudways または SpinupWP など) で Directorist 使用すると、月額約 $30～50 で動作し、適切なキャッシングと最適化で 10K～50K リスティングを処理できます。最も安いパスです。トレードオフは、継続的なメンテナンスの頭痛、プラグインの競合、および優れた検索エクスペリエンスではなく単なる平坦な検索エクスペリエンスです。
Supabase は大規模なディレクトリ データベースに十分ですか？
確かに。Supabase は PostGIS サポート、行レベル セキュリティ、およびリアルタイム サブスクリプション付きで PostgreSQL を実行します。月額 $25 のプロ プランは、問題なく数十万行を処理します。500K 件のリスティング未満のほとんどのディレクトリ プロジェクトでは、それは最高のバング フォア バックです。適切なリレーショナル データベース、まともな管理 UI、および組み込まれた API レイヤーを取得します。
大規模なディレクトリの検索とフィルタリングをどのように処理しますか？
検索用のプライマリ データベースを使用しないでください。リスティングを Typesense、Meilisearch、または Algolia に同期します。これらのサービスは、インスタント、ファセット、タイプミス耐性検索のために目的地構築されています。Typesense Cloud は月額 $29.50 で開始され、最大 500K レコードを処理します。検索エクスペリエンスは、CMS がネイティブに提供する何よりも劇的に優れています。
ディレクトリの静的サイト ジェネレーターまたはサーバー側レンダリングを使用する必要がありますか？
リスティング詳細ページでは、静的生成と ISR (Incremental Static Regeneration) を使用します。ページはオンデマンドでビルドおよびエッジでキャッシュします。検索とフィルター ページでは、サーバー側レンダリングを使用して、結果が常に新しく、応答が高速です。Next.js App Router は同じプロジェクトで両方のパターンをサポートします。Astro with server islands は、ディレクトリがより読み取り負荷の多い場合、別の強力なオプションです。
10,000 以上のリスティングをディレクトリにインポートするにはどうすればよいですか？
手動プロセスではなく、インポート パイプラインを構築します。CSV/JSON ソースを読み取り、各レコードを検証し、既存のエントリに対して重複排除し、バッチでデータベースに挿入するスクリプトを記述します。PostgreSQL の COPY コマンドまたは Supabase の一括挿入 API は、数秒で 10K レコードを処理できます。その後、検索インデックスへの同期をトリガーします。人々はこれを CMS 管理 UI で行おうとしています。しないでください。永遠に時間がかかり、おそらくタイムアウトします。
大規模なリスティングのあるディレクトリ ウェブサイト用の SEO とは？
ディレクトリ SEO には、適切な XML サイトマップ (サイトマップ ファイルあたり最大 50K URL に分割)、リスティングあたりの一意のメタ説明、構造化データ (LocalBusiness または Product スキーマ)、およびカテゴリとリスティング間の内部リンクが必要です。ヘッドレス アプローチは実際にここで役立ちます。メタ タグと スキーマ マークアップをページごとに完全に制御できるためです。CMS は多くの場合、スケール時にページごとにカスタマイズできる内容を制限します。
完全なカスタムではなくヘッドレスに進むことが有意である場合はいつですか？
完全なカスタム (CMS/admin レイヤーを含めて すべてをゼロから構築する) は、100K 件のリスティングを超え、複雑な マッチング アルゴリズムが必要な場合 (二者間マーケットプレイスなど) に意味があります。リアルタイム データ フィードや既存ツールが処理しない独自のビジネス ロジックが必要です。そのしきい値の下では、ヘッドレス アーキテクチャが、費用の 20% で利益の 90% をもたらします。私たちが見ているほとんどのディレクトリ プロジェクトは、完全なカスタムを必要としません。よく設計されたヘッドレス ビルドが必要です。