Contentful CMS 完整指南：功能、價格、GraphQL API 與程式碼範例 [2026]

Contentful CMS 完整指南：功能、價格、GraphQL API 與程式碼範例 [2026]

Contentful 是一個 API 優先的無頭 CMS，將你的內容儲存在中央枢纽，並透過 REST 和 GraphQL API 傳遞到任何前端——網頁、行動裝置、IoT、數位看板，無論你在做什麼。這份指南涵蓋了競品指南跳過的所有內容：實際的程式碼範例、真實的價格數字，以及誠實的限制分析。

我們在生產環境中使用 Sanity（Contentful 的直接競品），橫跨四個網站和十種語言，所以我們是從實務者的角度出發，而非供應商推銷。

快速摘要

Contentful 是什麼？

Contentful 是一個雲端原生、API 優先的無頭 CMS，或者用該公司現在的說法，是一個「可組合內容平台」。與 WordPress 等將內容管理與前端綁在一起的傳統系統不同，Contentful 將結構化內容集中儲存，並透過 API 傳遞到你需要的任何管道。

核心概念是分離式架構。你的內容存放在 Contentful 的雲端。你的前端——無論是 Next.js 網站、React Native 應用程式還是智慧顯示器——在建置時或執行時透過 Contentful 的 API 取得內容。內容本身不關心也不需要知道它最終會出現在哪裡。

Contentful 於 2013 年在柏林成立，已成長為最大的無頭 CMS 供應商之一。Spotify、Vodafone、Chanel 和 Atlassian 等品牌都在上面運行內容營運。它不是開源的，也沒有自架選項——純 SaaS，如果你有資料駐留的合規要求，這點很重要。

根據 Contentful 官方文件，該平台將自己定位為內容基礎設施——一個位於編輯團隊和數位體驗之間的內容枢纽。

Contentful 如何運作？

Contentful 遵循三層架構：你定義內容模型（Content Model，即 schema）、建立內容（Content，即 entries），然後透過 API 傳遞。內容與管道無關——同一篇部落格文章可以驅動你的網站、行動應用程式和電子報，無需任何重複。

一切都透過 API 流動。沒有內建的伺服器端渲染、沒有範本、沒有主題層。前端隨你怎麼建，Contentful 負責內容儲存和傳遞。

三種 API

Contentful 提供三種不同的 API，各有其用途和驗證方式：

• Content Delivery API（CDA）： 對已發佈內容的唯讀存取。由 Fastly CDN 支撐，快取請求快速且無限制。未快取請求的速率限制為每秒 55 次。
• Content Management API（CMA）： 用於以程式化方式建立和更新內容的讀寫存取。速率限制為每秒 10 次請求。這是你在遷移、批次匯入或 CI/CD 管線中會用到的 API。
• Content Preview API（CPA）： 與 CDA 相同，但提供草稿內容。非常適合在前端建立預覽模式——編輯可以在發佈前看到未發佈的變更。

三者都支援 REST 和 GraphQL。驗證透過 Bearer token 進行，delivery 和 management 使用不同的 token。

Environments 和 Spaces

把 Spaces 想成專案，Environments 想成內容的 git 分支。你可能有一個 master environment 用於生產環境，以及一個 staging environment 讓編輯可以在不影響線上內容的情況下工作。

Environments 支援別名（aliasing）——你可以將 master 別名指向新的 environment，實現零停機的內容升級。如果你正在選擇前端框架來搭配 Contentful，這個 environment 模型與 Vercel 或 Netlify 等平台的預覽部署搭配得很好。

Webhooks 讓你在內容變更時觸發建置、與外部系統同步或啟動工作流程。大多數團隊會將這些整合到 CI/CD 管線中，在每次發佈事件時重新建置靜態網站。

Contentful 的內容建模

內容建模是你定義內容結構的地方——決定存在哪些欄位、它們儲存什麼類型的資料、以及內容類型之間如何關聯的「schema」。根據我們的經驗，這是 Contentful 相較於更簡單的 CMS 選項真正出色的地方。

你本質上是在設計一個內容 schema，類似資料庫表格但更靈活。一個「Blog Post」內容類型可能有標題（短文字）、內文（豐富文字）、作者（對 Author 內容類型的關聯）和標籤（字串陣列）。你建立的每個 entry 都遵循這個結構。

欄位類型與驗證

Contentful 提供相當完整的欄位類型：

• 短文字（Symbol）： 標題、slug、標籤，最多 256 個字元
• 長文字（Text）： Markdown 或純文字，無字元限制
• 豐富文字（Rich Text）： 基於 JSON（非 HTML），讓你完全控制渲染
• 數字（Number）： 整數或小數
• 日期/時間（Date/Time）： ISO 8601 格式
• 布林值（Boolean）： 真/假切換
• 媒體（Asset）： 圖片、影片、文件，儲存在 Contentful 的資產管線中
• 關聯（Link）： 將 entry 連接到其他 entry 或資產
• JSON 物件： 自由格式的結構化資料
• 位置（Location）： 經緯度座標對

每個欄位都支援驗證：必填、唯一、正規表示式、大小限制和自訂驗證訊息。你也可以設定外觀選項，控制欄位在編輯器 UI 中的呈現方式。

關聯與連結的 Entry

關聯是你連接內容類型的方式。Blog Post 上的「Author」關聯連結到一個 Author entry。「Related Posts」欄位可以關聯多個 Blog Post entry。這形成了一個內容圖譜——entry 連結到 entry，可以在單一 API 呼叫中查詢。

以下是透過 Content Management API 建立時，Blog Post 內容類型定義的實際樣子：

{
  "name": "Blog Post",
  "fields": [
    { "id": "title", "type": "Symbol", "required": true },
    { "id": "slug", "type": "Symbol", "validations": [{ "unique": true }] },
    { "id": "body", "type": "RichText" },
    { "id": "author", "type": "Link", "linkType": "Entry" },
    { "id": "publishDate", "type": "Date" },
    { "id": "tags", "type": "Array", "items": { "type": "Symbol" } }
  ]
}

這是你會存放在版本控制中並透過遷移腳本套用的東西。沒有任何競品在他們的 Contentful 指南中展示這個——他們抽象地談論內容建模，卻不展示程式碼實際上長什麼樣子。

查詢內容：REST 和 GraphQL API

Contentful 提供 REST 和 GraphQL 兩種 API 來取得內容。REST 對簡單查詢來說很直覺。GraphQL 在你需要巢狀資料、單一請求中取得多種內容類型、或想避免過度擷取時更好用。兩者使用相同的驗證 token。

GraphQL endpoint 是從你的內容模型自動產生的。你建立的每個內容類型都會成為 schema 中可查詢的類型，內建篩選、排序和分頁。endpoint 位於：

https://graphql.contentful.com/content/v1/spaces/{SPACE_ID}

根據 Contentful 的 GraphQL 文件，每當你修改內容類型時，schema 會自動更新——不需要手動管理 schema。

GraphQL 查詢範例

以下是一個基本查詢，取得最新的十篇部落格文章及其作者：

query {
  blogPostCollection(limit: 10, order: publishDate_DESC) {
    items {
      title
      slug
      publishDate
      author {
        name
      }
    }
  }
}

需要按標籤篩選並取得德文內容嗎？加上 where 子句和 locale 參數：

query {
  blogPostCollection(
    where: { tags_contains_some: ["javascript"] }
    locale: "de"
  ) {
    items {
      title
      body {
        json
      }
    }
  }
}

有一件事要注意：GraphQL 查詢有複雜度限制。深度巢狀查詢搭配多個連結關聯可能會觸及上限。Contentful 根據查詢的節點數量和深度來計算複雜度。如果你要取得部落格文章及其作者、分類、相關文章，以及每篇相關文章的作者，複雜度會快速累積。

REST API 基礎

REST API 更簡單，但巢狀資料需要更多請求。基本的部落格文章取得會打到 https://cdn.contentful.com/spaces/{SPACE_ID}/entries?content_type=blogPost。你會得到一個 JSON，其中有一個扁平的 items 陣列和一個獨立的 includes 物件存放連結的 entry，你需要在客戶端自行解析。

如果你使用 TypeScript，Contentful 的 contentful.js SDK 會自動處理連結解析和型別產生。對於原始 fetch 呼叫，以下是查詢 GraphQL API 的最精簡 JavaScript：

const response = await fetch(
  `https://graphql.contentful.com/content/v1/spaces/${SPACE_ID}`,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${CDA_TOKEN}`,
    },
    body: JSON.stringify({ query }),
  }
);
const { data } = await response.json();

就是這樣。不需要 SDK、不需要建置步驟、不需要相依套件。這在 Node.js、Deno、Cloudflare Workers、瀏覽器——任何可以發 HTTP 請求的地方都能用。

值得了解的重要功能

Contentful 附帶廣泛的功能集，但並非每個功能都同等重要。以下是真正影響你日常體驗和架構決策的功能。

在地化（優勢與不足）

Contentful 的在地化模型在基礎設施層面相當扎實。你為 Space 定義語系（Enterprise 方案最多 100+ 個），每個欄位都可以儲存各語系的值。欄位層級的語系覆寫意味著你的德文標題可以與英文不同，同時共用同一張主視覺圖片。

不足之處在於翻譯管理。Contentful 給你儲存翻譯的欄位，但沒有產生翻譯的工作流程。沒有翻譯記憶、沒有術語表、沒有指派系統、沒有進度追蹤。你需要第三方整合——Phrase、Smartcat 或 Lokalise——來處理實際的翻譯流程。對於管理 10 種以上語言的團隊（我們在各網站管理 10 種語言），這個缺口會迅速造成高昂成本。

Environments 與分支

Environments 的運作方式就像內容模型和 entry 的 git 分支。建立一個 staging environment、進行 schema 變更、用內容測試，然後在準備好時升級到 master。別名讓你可以在不更改 API URL 的情況下切換 master 指向的 environment。

這對 schema 遷移非常實用。你可以在隔離的 environment 中測試新的內容類型、驗證前端是否正確處理，然後升級——全程不碰觸生產環境內容。我們見過的大多數團隊使用兩到三個 environments：production、staging，偶爾還有一個用於大型遷移的 feature branch。

其他值得一提的功能：

• 角色與權限： 精細的存取控制——限制編輯只能存取特定內容類型、封鎖初級角色的發佈權限、Enterprise 方案的自訂角色、SSO
• Webhooks： 在任何內容事件時觸發建置、Slack 通知或外部工作流程
• Rich Text： 基於 JSON，提供完整的渲染控制，但需要為每個前端框架撰寫自訂渲染器
• App Framework： 市集提供自訂欄位編輯器、側邊欄小工具和整合的擴充功能
• Image API： 即時調整大小、裁切、格式轉換（WebP、AVIF）和焦點裁切——不需要另外的圖片 CDN

Contentful 2026 年的新功能

Contentful 在 2025 年到 2026 年間推出了重大更新，而沒有任何競品指南涵蓋這些內容。如果你根據 2023 或 2024 年的資訊來評估 Contentful，你看到的是一個不完整的畫面。

AI Actions 與內容自動化

Contentful 推出了 AI Actions——在編輯器內直接由大型語言模型驅動的自動化內容工作流程。這些功能處理翻譯草稿、SEO 中繼資料產生、替代文字撰寫、語氣調整和內容摘要。你可以從編輯器側邊欄存取它們，它們會作用於你目前正在編輯的 entry。

根據 Diginomica 的報導，AI Actions 是 Contentful 更廣泛推動定位為完整數位體驗平台（DXP）的一部分，而非僅僅是無頭 CMS。這個功能對於自動化重複性編輯工作確實有用，不過翻譯輸出仍然需要人工審核——它是初稿，不是成品。

Contentful Studio（視覺化建構器）

Contentful Studio 於 2024 年春季正式 GA，並在 2025 年間大幅成熟。它是一個視覺化頁面建構器，讓非開發者可以透過拖放元件和即時預覽來組合頁面。如果你聽過「Contentful 沒有視覺化編輯」的批評，Studio 就是答案——雖然有一些附帶條件。

Studio 需要前端整合（你的元件需要向 Studio 的 SDK 註冊），而且它是付費附加功能，不包含在基本方案中。對於一直在 Contentful 結構化內容模型之上要求 WordPress 式頁面建構的團隊來說，現在這是一個真正的選項。Storyblok 在視覺優先的工作流程上仍然領先，但差距正在縮小。

Ninetailed 個人化

Contentful 於 2024 年收購了 Ninetailed，並將其更名為 Contentful Personalization。正如 CMS Critic 所報導，這讓你擁有原生的 A/B 測試、受眾分群和 AI 驅動的變體建議——全部可從編輯器中的 Optimization 分頁存取。

這值得注意，因為個人化在歷史上需要獨立的供應商（Optimizely、Dynamic Yield 等）。將其內建在 CMS 中降低了整合複雜度。但要注意：Ninetailed 是一個有獨立定價的獨立產品。它不是「Contentful 免費附帶的」。

Contentful 價格：實際費用

Contentful 提供四個方案，但大多數競品指南只列出名稱而不給你實際數字。以下是截至 2026 年 4 月的實際情況，基於 Contentful 的定價頁面：

免費方案對於原型開發和學習來說相當慷慨。你得到 10 位使用者、100K API 呼叫，以及足夠的頻寬來建立一個真正的專案。但一旦超出限制，成本會快速攀升。

需要編列預算的隱藏成本：

• Lite 方案的 API 超額費用： 超過每月 1M 次呼叫，你的帳單上就會出現超額項目
• 語系成本： 每個額外語系都計入你的 Space 限制——欄位層級 50 個語系會快速累積
• Contentful Studio： 視覺化建構器是付費附加功能，不包含在 Lite 甚至某些 Premium 方案中
• Ninetailed 個人化： 獨立產品、獨立合約、獨立定價
• 專業服務： 遷移協助、導入和培訓另行計費
• Rich Text 渲染器： 不是直接成本，但為你的框架建置自訂渲染器的開發時間是實實在在的

我們的誠實看法： Contentful 的免費方案對於評估和小型專案來說很扎實。但如果預算是主要考量，開源 CMS 替代方案如 Strapi 或 Payload 可以完全消除授權成本——你只需要支付主機費用。

Contentful vs Sanity vs Strapi：比較

這三個是在幾乎每次評估中都會出現的無頭 CMS 選項。我們在 Sanity 上建置過生產系統，所以我們 firsthand 了解它的優缺點。以下是誠實的比較：

Contentful 勝出的場景：擁有大型內容營運和嚴格治理需求的企業團隊。成熟的角色系統、SSO、稽核日誌，以及 Enterprise 方案的 99.99% SLA 很難被超越。

Sanity 勝出的場景：開發者體驗和 schema 靈活性。如果你偏好 schema-as-code、想要 GROQ 的查詢能力，並重視即時協作功能，Sanity 是更適合的選擇。閱讀我們的完整 Sanity CMS 指南深入了解。

Strapi 勝出的場景：成本。自架免費且無 API 呼叫限制。如果你有 DevOps 能力管理自己的基礎設施，且不需要企業級支援，Strapi 給你最高的性價比。

如需包含 Storyblok、Payload 和 Hygraph 的更廣泛比較，請參閱我們的完整無頭 CMS 比較。

選擇 Contentful 前你應該知道的限制

每個 CMS 都有取捨。以下是 Contentful 的限制，附帶具體數字——不是模糊帶過。我們在為自己的內容管線評估 Contentful 時就遇到了其中幾項。

速率限制是真實存在的。 CDA 允許每秒 55 次未快取請求。CDN 快取回應是無限制的，但如果你的應用程式繞過快取（例如每次請求都進行伺服器端渲染），你會很快觸及限制。CMA 更嚴格，每秒 10 次請求——這對遷移腳本和批次匯入有影響。

沒有內建視覺化編輯（除非額外付費）。 Contentful Studio 存在，但它是需要前端整合的付費附加功能。如果你的團隊期望基本產品中有 WordPress 式的頁面建構，請做好心理準備。Storyblok 在每個方案都包含視覺化編輯。

沒有翻譯管理。 你得到語系欄位，僅此而已。沒有翻譯工作流程、沒有指派系統、沒有翻譯記憶、沒有進度追蹤。對於一個將在地化作為主要賣點的平台，實際的翻譯體驗完全依賴 Phrase、Smartcat 或 Lokalise 等第三方工具。

所有前端相關事務都依賴開發者。 內容編輯可以建立和管理 entry。他們無法更改頁面版型、新增區塊、修改導覽，或以任何方式更新前端——除非有開發者介入。這是無頭架構的固有特性，但在 Contentful 中更為明顯，因為基本產品不包含頁面建構器。

規模化後價格難以預測。 API 呼叫超額、基於語系的限制、Studio 和 Personalization 的附加功能成本，以及專業服務，共同形成了一個難以預測的定價模型。我們交談過的多個團隊都對他們第一張超出免費方案後的帳單感到驚訝。

Rich Text 複雜度。 Contentful 的 Rich Text 是基於 JSON 而非 HTML。每個前端框架都需要自訂渲染器——React 用 @contentful/rich-text-react-renderer、原生 JS 用 rich-text-html-renderer 等。它給你完整的渲染控制，但開發工作量明顯大於基於 HTML 的競品。

供應商鎖定。 閉源、純 SaaS、無自架選項。你的內容可以透過 API 匯出，但你的內容模型、工作流程和整合都是 Contentful 專屬的。如果價格變動或功能被棄用，你的選擇有限。

誰應該（和不應該）使用 Contentful

Contentful 是一個強大的平台，但它不適合每個專案。以下是一個決策框架，幫助你自我評估。

適合使用 Contentful 的情況：

• 你是管理多管道內容（網頁、行動、IoT、數位看板）的企業團隊
• 你需要 50+ 語系和欄位層級覆寫的原生在地化
• 你想要一個成熟、經過實戰考驗的平台，配有專屬支援和 99.99% SLA
• 你的團隊包含熟悉 API 優先架構的開發者
• 你需要精細的角色、權限、稽核日誌和 SSO

不適合使用 Contentful 的情況：

• 你是預算有限的獨立開發者或小團隊——看看 Strapi 或 Payload
• 你想要基本產品中包含視覺化頁面建構器——看看 Storyblok
• 你偏好程式碼優先的 schema 定義和最大靈活性——看看 Sanity
• 你需要一個簡單的部落格 CMS——WordPress 或 Ghost 更便宜、設定更快
• 你因合規原因需要自架——看看 Strapi 或 Payload

如需更深入地了解所有這些替代方案，請查看我們的完整無頭 CMS 比較。

開始使用：Contentful 的前 15 分鐘

以下是一個實際的操作指南——不是理論，而是從零到透過 GraphQL 查詢內容的確切步驟，大約 15 分鐘。

步驟 1：註冊。 前往 contentful.com 建立免費帳號。不需要信用卡。

步驟 2：建立 Space。 Space 是你的專案容器。免費方案給你一個 Starter Space。取一個描述性的名稱。

步驟 3：定義內容類型。 前往 Content Model，點擊「Add content type」，建立一個「Article」類型。新增欄位：Title（短文字、必填）、Slug（短文字、唯一驗證）、Body（豐富文字）、Cover Image（媒體）和 Published Date（日期與時間）。

步驟 4：建立 Entry。 前往 Content，點擊「Add Article」，填入欄位。點擊 Publish。

步驟 5：取得 API 金鑰。 前往 Settings -> API Keys。建立一個新的 API key。你會得到 Space ID、Content Delivery API token 和 Content Preview API token。保存這些。

步驟 6：透過 GraphQL Playground 查詢。 在瀏覽器中開啟這個 URL（替換成你的憑證）：

https://graphql.contentful.com/content/v1/spaces/{SPACE_ID}/explore?access_token={CDA_TOKEN}

步驟 7：從你的應用程式取得資料。 使用上方 API 章節中的 JavaScript fetch 範例，換入你的 Space ID 和 CDA token，你就可以取得即時內容了。

專業提示： GraphQL Playground URL 在 Contentful UI 中不太明顯。你可以在 Settings -> API Keys -> GraphQL Playground URL 下找到它，或使用上方的範本手動組合。把它加入書籤——開發過程中你會不斷用到它。

常見問題

Contentful CMS 是什麼？如何運作？

Contentful 是一個 API 優先的無頭 CMS，將結構化內容儲存在雲端枢纽，並透過 REST 和 GraphQL API 傳遞。與 WordPress 不同，它沒有前端——你使用任何框架自行建置。內容編輯透過 Contentful 的網頁應用程式管理 entry，開發者則透過 API 取得這些內容。

Contentful 可以免費使用嗎？

可以，Contentful 提供免費的 Community 方案，包含 10 位使用者、每月 100K API 呼叫、50 GB CDN 頻寬和一個 Starter Space。這足以進行原型開發和小型專案。付費方案從 Lite 方案的 $300/月起，Premium 和 Enterprise 方案則為客製報價。

Contentful 中的內容建模是什麼？

內容建模是指定義具有欄位、驗證和關聯的結構化內容類型——就像設計資料庫 schema，但是為了內容。你建立「Blog Post」或「Product」等類型，包含特定欄位（標題、內文、圖片、分類），每個 entry 都遵循該結構。這是 Contentful 的基礎。

Contentful 與 WordPress 相比如何？

Contentful 是無頭的（僅 API，無內建前端），而 WordPress 將內容管理與基於主題的渲染綁在一起。Contentful 擅長多管道傳遞——相同內容可以服務網頁、行動和 IoT。WordPress 擅長簡單性——幾分鐘內就能有一個可運作的網站，不需要開發者。

Contentful 適合企業使用嗎？

是的，Contentful 是企業採用率最高的無頭 CMS 平台之一。Enterprise 方案包含 SSO、精細的角色存取控制、稽核日誌、專屬支援、99.99% SLA 和無限 API 呼叫。Spotify、Vodafone、Chanel 和 Atlassian 等公司都用它進行大規模內容營運。

Contentful 的缺點是什麼？

主要限制包括：基本產品中沒有內建視覺化編輯（Studio 是付費附加功能）、規模化後因 API 超額和附加功能成本導致價格不可預測、沒有翻譯管理工作流程、所有前端變更都依賴開發者、Rich Text JSON 需要自訂渲染器，以及無自架選項的供應商鎖定。

Contentful 支援 GraphQL 嗎？

是的，原生支援。每個 Contentful Space 都會根據你的內容類型自動產生 GraphQL schema。你可以進行篩選、分頁、排序和特定語系的查詢。endpoint 位於 graphql.contentful.com/content/v1/spaces/{SPACE_ID}，使用你的 Content Delivery API token 進行驗證。

Contentful 每月費用是多少？

免費方案 $0。Lite 為 $300/月，含 20 位使用者和 1M API 呼叫。Premium 約從 $2,000+/月起，客製定價。Enterprise 年費為五到六位數中段。注意隱藏成本：API 超額費用、Contentful Studio 附加功能費、Ninetailed 個人化定價，以及專業服務費用。

Contentful 能處理多語言嗎？

可以，Contentful 具有原生語系支援和欄位層級覆寫——每個欄位可以儲存不同語系的值。然而，沒有內建的翻譯工作流程、記憶或術語表。你需要 Phrase、Smartcat 或 Lokalise 等第三方整合來大規模管理實際的翻譯流程。

Contentful Studio 是什麼？

Contentful Studio 是一個視覺化頁面建構器附加功能，於 2024 年春季正式 GA。它讓非開發者可以使用拖放元件和即時預覽來組合頁面。它需要前端整合（你的元件必須向 Studio 的 SDK 註冊），且是付費附加功能，不包含在 Contentful 基本方案中。