建立目錄網站：為什麼 CMS 工具在 10,000 個列表時崩潰
為什麼 CMS 工具在 10,000 個列表時崩潰：目錄網站建構指南
我看過這種情況至少發生過十幾次。有人在 Webflow 或 WordPress 上建構一個目錄，在 500 個列表時運作完美，到 2,000 個時仍然沒問題，但在 8,000-10,000 個條目時，整個系統開始喘不過氣來。搜尋變得很慢。過濾器超時。建構時間延伸到幾分鐘。在第一個月時感覺完美的 CMS 在第八個月變成了你迫切想要逃脫的瓶頸。
核心問題是什麼？CMS 工具是為內容而設計的——部落格文章、登錄頁面，也許還有幾百個 SKU 的產品目錄。目錄網站是一種完全不同的獸類。它需要複雜的過濾、分面搜尋、地理位置查詢、使用者生成的內容，以及分頁模式，這些模式將每個頁面檢視的資料庫查詢數量增加了數個數量級。將目錄視為一個有更多文章的部落格是一個架構錯誤，它比你預期的更快就會追上你。
我將完整說明為什麼會發生這種情況、2025 年實際的技術限制是什麼，以及如果你想認真地擴展到 10,000 個以上的列表，你應該改為建構什麼。
目錄
目錄不是部落格
這聽起來很明顯，但這是大多數專案在規劃階段出錯的地方。部落格文章是一個單一文件。你透過 slug 取得它，渲染它，完成。目錄列表頁面做的事完全不同：它查詢可能數千筆記錄，同時應用多個過濾器（類別、位置、價格範圍、評級、可用性），對結果進行排序，進行分頁，並渲染頁面——通常還包括地圖標記、距離計算，以及每個過濾選項的彙總計數。
以下是每個頁面檢視的資料庫操作快速比較：
| 操作 | 部落格文章頁面 | 目錄列表頁面 |
|---|---|---|
| 主要查詢 | 1（透過 slug 取得） | 1（過濾、排序、分頁） |
| 相關查詢 | 2-3（作者、類別、相關文章） | 5-15（過濾計數、地理計算、評論、可用性） |
| 索引查詢 | 1-2 | 10-50+（每個過濾面向） |
| 掃描的行數 | 1-5 | 100-10,000+ |
| 典型回應時間 | 5-50ms | 200-2,000ms（未優化） |
| 快取失效複雜性 | 低（單個文件） | 高（任何列表變更都會影響多個頁面） |
當你使用傳統 CMS 時，這些操作中的每一個都要經過同一個資料庫、同一個查詢引擎，同一個也在服務你的首頁、關於頁面和管理面板的伺服器。在 500 個列表時，它沒關係。在 10,000 個時，它就很重要了。
主要 CMS 平台遇到的瓶頸
讓我們具體說明什麼會崩潰以及在哪裡崩潰。
Webflow
Webflow 在其 Business 方案上對每個集合強制執行 10,000 個 CMS 項目的硬上限。這不是一個軟性指導方針——這是一道牆。達到它，你就無法再添加另一個列表。Webflow 團隊已在其社區論壇中確認此限制存在是出於「效能考慮」，不會消失。
但這裡大多數人忽視的是：效能在你達到 10K 之前就開始下降。一旦你超過 5,000-6,000 個項目並使用複雜的集合列表和過濾器，你會注意到建構時間延伸超過 10 分鐘，頁面載入變得緩慢。Webflow 的 CMS 不是為分面搜尋而建構的。沒有辦法進行原生的「展示我所有在 5 英里內、現在開放且有素食選項的餐廳」查詢。
截至 2026 年 3 月，Webflow 的 Business 方案為 $39/月（年度計費）。想使用附加功能升級到 20,000 個項目？那將花費 $124/月——是基本價格的三倍多，項目數量增加一倍。100K+ 個項目的企業定價從 $15,000-$50,000/年開始。
WordPress
WordPress 沒有硬性項目上限，但它有更糟的東西：不可預測的降級。使用像 Directorist 或 Business Directory Plugin 這樣的目錄外掛的標準 WordPress 安裝將在典型的共享或 VPS 託管上在 10,000 個列表左右開始出現問題。罪魁禍首是 MySQL 查詢效能。
WordPress 將所有內容——文章、自訂欄位、分類法、中繼資料——存儲在少數幾個資料庫表中。一個有 20 個自訂欄位的目錄列表意味著 wp_postmeta 中每個列表有 20 行。在 10,000 個列表中，那就是 wp_postmeta 中單獨有 200,000 行，WordPress 喜歡在這些表上進行 JOIN 查詢。加上 WooCommerce 或任何其他也將資料填充到 postmeta 中的外掛，你就有了真正的混亂。
我看過在 10K 列表上運作良好的 WordPress 目錄網站——但只有在大量優化之後：Redis 物件快取、Elasticsearch 搜尋、專用資料庫伺服器，以及小心的查詢優化。此時，你在託管基礎設施上花費 $200-500/月，並且基本上在與平台對抗而不是與之合作。
Airtable / Notion / Google Sheets 作為「後端」
我在獨立駭客社群中經常看到這個模式。使用 Airtable 作為你的資料庫，透過靜態網站生成器或 Webflow 輸入它，你就有了一個目錄。它有效！直到它不這樣做。
Airtable 的 API 每個請求最多返回 100 條記錄。他們的免費方案限制為每個 base 1,200 條記錄。即使在他們的 Business 方案（$20/使用者/月）上，你也會遇到每個 base 每秒 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，除非你使用增量靜態再生成 (ISR)，否則完整重建需要 15-30 分鐘。
// 樸素的方法：在建構時建構所有 10K 頁面
export async function getStaticPaths() {
const listings = await fetchAllListings(); // 10,000 個項目
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"）
- 加權相關性（標題匹配比描述匹配排名更高）
- 分面計數（每個類別/過濾器有多少個結果）
- 地理距離排序
- 低於 200ms 的回應時間
你需要一個搜尋引擎來做這個。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/月（1M 個文件） | <50ms | 簡單設定、優良預設 |
| Elasticsearch | 自託管（免費） | Elastic 雲端：~$95/月 | <100ms | 複雜查詢、成熟的生態系 |
Typesense 和 Meilisearch 在 2025 年都有了顯著成熟。對於大多數預期列表數量低於 100K 的目錄專案，Typesense 雲端的 $29.50/月為你提供即時搜尋、分面、地理搜尋和容錯。它快得離譜。
目錄網站的無頭方案
以下是我對任何預期超過 10,000 個列表的目錄推薦的架構：
- 前端：Next.js 或 Astro 用於公開的網站
- CMS：Sanity、Contentful 或 Payload 用於編輯內容（首頁、關於、部落格、幫助文章）
- 資料庫：PostgreSQL（透過 Supabase 或 Neon）用於列表資料
- 搜尋：Typesense 或 Meilisearch 用於搜尋和過濾
- 管理介面：自訂儀表板或 Retool 用於列表管理
這是我們定期為客戶建構的堆棧類型。前端框架處理渲染和路由。CMS 處理編輯人員需要管理的內容。資料庫處理結構化、大量的列表資料。搜尋引擎處理目錄所需的查詢模式。
使用 Next.js，你可以為列表詳細頁面取得 ISR（增量靜態再生成）（按需建構、在邊緣快取、在變更時重新驗證）以及為搜尋/過濾頁面取得伺服器端渲染（結果總是新鮮的、快速回應）。使用 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; // 每小時重新驗證一次
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 資料），以及在你爬取資料來源時處理 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 雲端） | $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 企業要低得多，而架構實際上支援成長。當你從 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 權益。
常見問題
Webflow 真的可以處理大型目錄網站嗎？ Webflow 適用於 5,000 個以下列表的目錄。在 5K 到 10K 之間，你會感到建構時間和頁面載入的效能拖累。在 10,000 個時你達到硬上限。如果你的目錄會保持很小並且你重視 Webflow 的視覺設計工具，這很好。如果你期望成長，從不同的架構開始。
用 10,000+ 個列表建構目錄的最便宜方式是什麼？ WordPress 加上 Directorist 在質量託管上（如 Cloudways 或 SpinupWP）大約 $30-50/月，可以處理 10K-50K 個列表，具有適當的快取和優化。這是最便宜的路徑。權衡是持續的維護麻煩、外掛衝突，以及搜尋體驗只是還可以而不是很好。
Supabase 對目錄資料庫來說足夠好嗎？ 絕對是。Supabase 運作 PostgreSQL 和 PostGIS 支援、行級安全和即時訂閱。他們的 Pro 方案 $25/月 可以處理數十萬行而無問題。對於大多數列表數量低於 500K 的目錄專案，這是最划算的選擇。你獲得一個適當的關係型資料庫，具有體面的管理 UI 和內置的 API 層。
我如何為大型目錄處理搜尋和過濾？ 不要使用你的主要資料庫進行搜尋。將你的列表同步到 Typesense、Meilisearch 或 Algolia。這些服務是為即時、分面、容錯搜尋而目的建構的。Typesense 雲端從 $29.50/月開始，可以處理最多 500K 個記錄。搜尋體驗將比 CMS 原生提供的任何東西都好得多。
我應該為目錄使用靜態網站生成器還是伺服器端渲染？ 對於列表詳細頁面，使用靜態生成配合 ISR（增量靜態再生成）——頁面在首次訪問時建構並在邊緣快取。對於搜尋和過濾頁面，使用伺服器端渲染以便結果總是新鮮的。Next.js App Router 在同一專案中支援兩種模式。Astro 配合伺服器島嶼是另一個強大的選項，如果你的目錄更多是讀取繁重。
我如何將 10,000+ 個列表匯入到我的目錄？
建構一個匯入管道，不是一個手動流程。寫一個讀取你的 CSV/JSON 來源的指令，驗證每條記錄，針對現有條目進行重複資料刪除，並批量插入到你的資料庫。PostgreSQL 的 COPY 命令或 Supabase 的批量插入 API 可以在幾秒內處理 10K 筆記錄。然後觸發同步到你的搜尋索引。我看過人們試圖透過 CMS 管理 UI 做這個——不要。它會花很長時間，可能會超時。
目錄網站與數千個頁面的 SEO 呢？ 目錄 SEO 需要適當的 XML 站點地圖（每個站點地圖檔案最多分成 50K 個 URL 的塊）、每個列表的唯一中繼描述、結構化資料（LocalBusiness 或 Product 架構），以及類別和列表之間的內部連結。無頭方法實際上在這裡有幫助，因為你對每個中繼標籤和架構標記有完全控制。CMS 通常限制你可以在規模時的每頁自訂。
什麼時候有意義要去完全自訂而不是無頭？ 完全自訂（從頭開始建構所有內容，包括 CMS/管理層）當你超過 100K 個列表時有意義，需要複雜的配對演算法（像一個雙邊市場），需要即時資料饋送，或有沒有現有工具處理的獨特業務邏輯。在那個閾值以下，一個無頭架構加上一個適當的資料庫為你提供 90% 的益處，花費 20% 的成本。大多數我們看到的目錄專案不需要完全自訂——他們需要一個設計良好的無頭建構。