我最近審計了一個擁有 3,000 多篇文章的 WordPress 網站。客戶希望將他們的內容輸入到一個 AI 工具中以生成摘要並支持推薦引擎。應該很簡單，對吧？導出內容，輸入其中，完成。

但並非如此。每篇文章都是一團亂的 HTML——來自不再存在的插件的短代碼、來自經典編輯器的內聯樣式、分散如地雷的 Gutenberg 區塊注釋，以及使解析器窒息的編碼實體。數據庫中的「內容」字段根本不是內容。它是一套只有 WordPress 本身才能解釋的渲染指令集。AI 模型產生了垃圾。客戶大發雷霆。我不得不解釋一些更多團隊需要聽到的東西：你存儲內容的方式決定了你能用它做什麼，不僅是今天，而是對於你還沒想到的每個使用場景。

這是結構化內容與 HTML 塊的故事，為什麼它在 2025 年比以往任何時候都更重要，以及遷移路徑實際上是什麼樣的。

目錄

HTML 塊是什麼以及 WordPress 為什麼使用它們

在任何 WordPress 網站上打開 phpMyAdmin 並查看 wp_posts 表。找到 post_content 列。你看到的是一個包含所有內容的單個文本字段——標題、段落、圖像、嵌入、短代碼、區塊標記、內聯 CSS——全部混合在一個長字符串中。

以下是典型的 Gutenberg 文章在數據庫中的樣子：

<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">我們的服務</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>我們為企業提供<strong>高級諮詢</strong>。</p>
<!-- /wp:paragraph -->

<!-- wp:shortcode -->
[contact-form-7 id="1234" title="Contact"]
<!-- /wp:shortcode -->

<!-- wp:image {"id":5678,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large">
<img src="/wp-content/uploads/2024/03/hero.jpg" alt="" class="wp-image-5678"/>
</figure>
<!-- /wp:image -->

這是一個 HTML 塊。它是呈現和內容的混合。數據庫不知道「我們的服務」是標題，圖像是英雄圖像，或者聯繫表單是一個 CTA 組件。它全部就是……一個字段中的文本。

WordPress 這樣做是因為它在 2003 年被設計為博客平台。心智模型很簡單：一篇文章有一個標題和一個正文。正文是 HTML。你編寫它，WordPress 渲染它。該模型對博客非常有效。但對現代內容運營卻起相反作用。

Gutenberg 沒有實現的改進

Gutenberg（區塊編輯器）本應解決這個問題。公平地說，它增加了一些結構——那些 HTML 注釋將區塊類型和屬性編碼為 JSON。但這是關鍵的失敗：該結構存在於 HTML 塊內部。它不可查詢。它沒有類型。它沒有驗證。你不能要求數據庫「給我所有英雄圖像為 X 的文章」或「找到包含定價表區塊的每篇文章」。

區塊數據本質上是編碼為文本字段內注釋的元數據。那不是結構。那是一個黑客。

結構化內容的真實含義

結構化內容將某物是什麼與它看起來如何分離。你不是存儲一個 HTML 塊，而是定義一個具有離散、有類型字段的內容模型。

以下是相同內容作為 Sanity 等無頭 CMS 中的結構化數據：

{
  "_type": "servicePage",
  "title": "我們的服務",
  "heroImage": {
    "_type": "image",
    "asset": { "_ref": "image-abc123" },
    "alt": "團隊在項目上協作"
  },
  "sections": [
    {
      "_type": "textBlock",
      "heading": "高級諮詢",
      "body": [
        {
          "_type": "block",
          "children": [
            { "_type": "span", "text": "我們提供" },
            { "_type": "span", "text": "高級諮詢", "marks": ["strong"] },
            { "_type": "span", "text": "給企業。" }
          ]
        }
      ]
    },
    {
      "_type": "ctaForm",
      "formType": "contact",
      "placement": "inline"
    }
  ]
}

注意區別。每一份內容都有一個類型。圖像有明確的替代文本作為必填字段。富文本以可移植格式存儲——不是 HTML——可以呈現為任何輸出。CTA 表單是一個類型化引用，不是當你停用插件時會破壞的短代碼字符串。

這就是 Sanity、Contentful、Storyblok 和 Strapi 等無頭 CMS 平台提供的。也是它們存在的原因。

可移植文本的優勢

Sanity 的 Portable Text 格式（和其他無頭 CMS 中的類似方法）將富文本存儲為有類型對象的數組。這意味著你可以：

  • 將其呈現為 HTML 供網絡使用
  • 將其呈現為 Markdown 供文檔使用
  • 將其呈現為純文本供 AI 處理
  • 將其呈現為 JSX 供 React 組件
  • 將其呈現為 SSML 供語音助手

HTML 塊只給你一個輸出格式：HTML。甚至不是乾淨的 HTML——帶有所有怪癖的 WordPress 風格的 HTML。

為什麼 AI 無法讀取你的 WordPress 內容

這是在 2025 年變得緊急的部分。AI 驅動的工具——從 ChatGPT 和 Claude 到 Google 的 AI 概覽和內部 RAG（檢索增強生成）系統——都需要從語義上理解你的內容。他們需要知道東西是什麼，而不僅僅是它在瀏覽器中的外觀。

解析問題

當你試圖從 WordPress HTML 塊中提取有意義的內容時，你立即遇到這些問題：

  1. 短代碼在 WordPress 外解析為空。[gallery ids="1,2,3"] 沒有展開它的 PHP 函數是無意義的。
  2. 區塊注釋是非標準的。<!-- wp:columns --> 不是網絡標準。AI 解析器不知道如何處理它。
  3. 內聯樣式和類沒有語義意義。<div class="wp-block-group has-background"> 無法告訴你內容的目的。
  4. 嵌套 HTML 結構是模糊的。那個嵌套 div 是邊欄嗎？一個標註嗎？一個佈局容器嗎？沒有辦法以編程方式知道。
  5. 插件生成的標記是不可預測的。每個插件都注入自己的 HTML 模式，通常相互衝突。

這對 AI 概覽和 LLM 意味著什麼

Google 的 AI 概覽（搜索結果頂部 AI 生成的摘要）正在從易於解析和理解的頁面中提取內容。根據 Authoritas 在 2025 年初的研究，具有清晰內容層次結構和模式標記的頁面在 AI 概覽中被引用的次數比內容質量相同但結構不佳的頁面多 2-3 倍。

當內容乾淨時，LLM 處理你的內容會更好。句號。如果你的內容埋在標記湯中，信噪比就會下降。模型必須猜測什麼是內容，什麼是裝飾。有時它會猜錯。

RAG 系統和內部 AI 工具

許多公司在 2025 年正在構建內部 AI 工具，需要吸收自己的內容——知識庫、產品文檔、市場營銷副本。如果該內容存在於 WordPress 中，提取管道看起來像這樣：

  1. 查詢 WordPress REST API 或數據庫
  2. 取回 HTML 塊
  3. 剝離 HTML 標籤（失去所有結構）
  4. 或解析 HTML（混合噪聲和信號）
  5. 為嵌入分塊文本
  6. 祈禱最好的結果

使用來自無頭 CMS 的結構化內容，它是：

  1. 查詢 API
  2. 取回有類型的結構化 JSON
  3. 選擇正好你需要的字段
  4. 按內容類型乾淨分塊
  5. 生成高質量的嵌入

輸出質量的差異是戲劇性的。我已經看到 RAG 準確度僅通過將 HTML 提取的內容切換為結構化內容作為源就提高了 30-40%。

非結構化內容的真實成本

讓我們談談那些不會出現在發票上但絕對會隨著時間推移摧毀你預算的成本。

成本因素 WordPress HTML 塊 結構化內容（無頭 CMS）
跨渠道內容重用 手動複製粘貼、重新格式化 API 驅動，自動
AI/ML 內容處理 需要解析管道、容易出錯 直接 JSON 消費
重新設計/重新平台化工作 內容與主題耦合，高工作量 內容解耦，自由交換前端
多語言支持 插件相關，脆弱 內置，字段級本地化
內容治理 有限字段驗證 模式強制內容類型
移動應用內容 REST API 返回 HTML 字符串 乾淨 JSON，本機就緒
開發人員入職時間 主題 + 插件生態系統學習曲線 API 文檔 + 內容模式
內容遷移到新平台 痛苦的 HTML 解析 導出結構化 JSON

該表中的每一行都代表真實的小時數和真實的金錢。我參與過 WordPress 到無頭遷移的項目，其中 60% 的項目預算用於內容轉換——不是因為新系統很難，而是因為從舊 HTML 塊中提取含義是痛苦的。

無頭 CMS vs WordPress：誠實的比較

我不打算假裝 WordPress 在所有方面都很糟糕。它不是。讓我們誠實地談論每種方法在哪裡表現良好。

WordPress 仍然勝出的地方

  • 生態系統規模。60,000+ 插件。有適合所有東西的插件。質量差異很大，但廣度無與倫比。
  • 非技術編輯熟悉度。大多數內容編輯都使用過 WordPress。基本任務的學習曲線幾乎為零。
  • 一體化簡單性。對於基本的宣傳冊網站或博客，WordPress 比任何東西都更快地讓你從零發佈。
  • 進入成本。共享主機每月 5 美元，一個免費主題，你就開始了。

無頭 CMS 勝出的地方

  • 內容結構和建模。這是整篇文章的重點。無頭 CMS 讓你準確定義內容作為數據的外觀。
  • API 優先交付。內容流向網站、應用、信息亭、語音助手——任何可以發出 HTTP 請求的地方。
  • 性能。當與 Next.js 或 Astro 等框架配對時，你可以獲得靜態生成、邊緣緩存和亞秒級加載時間。
  • 安全性。前端沒有 PHP 執行。沒有 wp-login.php 可以暴力破解。攻擊面大幅縮小。
  • AI 就緒。結構化內容原生可由 AI 工具、搜索引擎和自動化管道消費。
  • 開發人員體驗。現代工具、TypeScript 支持、實時協作、內容版本控制。

大多數文章遺漏的細微差別

WordPress 可以通過 WPGraphQL 或 REST API 用作無頭 CMS。一些團隊這樣做。但你仍然存儲 HTML 塊——你只是通過 API 提供它們，而不是使用 PHP 渲染它們。根本問題沒有改變。你的內容仍然是無結構的。

帶有 ACF（高級自定義字段）的 WordPress 更接近結構化內容。你可以創建類型化和可查詢的自定義字段。但 ACF 是一個插入不是為其設計的系統的插件。內容建模 UX 很笨拙，複雜字段組的性能下降，你仍然依賴 WordPress 生態系統來託管、更新和安全。

隨著時間推移複合的 WordPress 限制

這些不是理論問題。這些是我在真實項目中看到的東西中斷。

插件依賴地獄

典型的 WordPress 網站使用 20-40 個插件。每一個都可以與其他衝突。每一個都需要更新。每一個都是潛在的安全漏洞。當插件被放棄時（這不斷發生），你的內容中的短代碼就會呈現為文字。

我去年審計了一個有 800 篇文章的網站，其中充滿了 [tabs] 短代碼。選項卡插件自 2021 年以來未進行更新。內容被死代碼綁架。

一體化架構稅你必須支付

WordPress 在一個 PHP 進程中處理路由、渲染、內容存儲、身份驗證、媒體管理和插件執行。這意味著：

  • 你無法獨立於管理界面擴展內容 API
  • 流量峰值會影響處理編輯器會話的同一服務器
  • 內容檢索的數據庫查詢與插件操作競爭
  • 你無法在不接觸 WordPress 服務器的情況下部署前端更改

現代無頭 CMS 架構完全分離這些問題。內容 API 獨立擴展。前端部署到邊緣網絡。編輯在不與公共流量共享資源的專用工作室中工作。

沒人談論的內容鎖定

這是骯髒的秘密：WordPress 內容在理論上可移植但在實踐中被鎖定。是的，你可以導出 XML。但該 XML 包含帶有短代碼、插件特定標記和 WordPress 內部引用的 HTML 塊。遷移到任何其他系統需要解析和轉換工作，該工作與內容量和複雜性呈線性關係。

無頭 CMS 中的結構化內容導出為 JSON。乾淨、有類型、可預測的 JSON。從 Sanity 遷移到 Contentful（反之亦然）需要映射內容類型，而不是解析 HTML。

遷移路徑：從塊到結構

如果你坐在一個 WordPress 網站上，這篇文章讓你感到不適，很好。讓我們談談做什麼。

步驟 1：審計你的內容

在你觸及任何東西之前，請瞭解你擁有什麼。對數據庫運行查詢：

-- 查找使用中的所有短代碼
SELECT DISTINCT
  REGEXP_SUBSTR(post_content, '\\[[a-zA-Z_-]+') AS shortcode,
  COUNT(*) AS usage_count
FROM wp_posts
WHERE post_status = 'publish'
  AND post_content REGEXP '\\[[a-zA-Z]'
GROUP BY shortcode
ORDER BY usage_count DESC;

記錄每個短代碼、每個自定義區塊、每個 ACF 字段組。此清單驅動你的內容模型設計。

步驟 2：首先設計你的內容模型

不要選擇 CMS 然後找出你的模型。根據你的內容需求設計模型，然後選擇最支持它的 CMS。

詢問這些問題：

  • 什麼是不同的內容類型？（博客文章、案例研究、產品頁面、團隊成員...）
  • 每種類型需要什麼字段？
  • 類型之間的關係是什麼？
  • 誰需要編輯什麼？
  • 這些內容需要出現在哪裡？（網絡、應用、電子郵件、AI 工具...）

步驟 3：構建轉換管道

這是困難工作所在。你需要將 HTML 塊轉換為結構化數據。有幫助的工具：

  • 自定義 Node.js 腳本使用 cheerio 或 unified/rehype 進行 HTML 解析
  • Sanity 的遷移工具用於導入結構化內容
  • Contentful 的遷移 CLI 用於程序化內容創建
  • OpenAI 或 Claude API 用於 AI 輔助內容分類（認真的——在遷移期間使用 AI 標籤和分類你的內容）
// 示例：將 WordPress HTML 轉換為可移植文本
import { htmlToBlocks } from '@sanity/block-tools'
import { Schema } from '@sanity/schema'

const defaultSchema = Schema.compile({ /* 你的模式 */ })
const blockContentType = defaultSchema
  .get('post')
  .fields.find(field => field.name === 'body').type

const blocks = htmlToBlocks(
  '<p>你的<strong>WordPress</strong> HTML 在這裡</p>',
  blockContentType
)

步驟 4：並行運行

不要進行大爆炸遷移。並行運行 WordPress 和新無頭 CMS。分批遷移內容。驗證每批。針對無頭 CMS API 構建新前端，同時舊網站保持開啟。

這是我們在 無頭 CMS 項目上採用的方法。這在前面的工作更多，但大幅降低風險。

步驟 5：重定向和停用

新網站上線並驗證後，設置 301 重定向、監控 404、關閉 WordPress。永遠保持數據庫備份——你永遠不知道何時需要參考舊內容。

選擇正確的無頭 CMS

市場已經成熟。以下是 2025 年主要參與者的堆棧情況：

CMS 內容建模 定價（起價） 最適合 AI 功能
Sanity 優秀——代碼定義的模式 免費層，然後 $99/月（增長） 自定義內容模型、開發人員團隊 Sanity AI 協助內置
Contentful 強——基於 UI 的建模 免費層，然後 $300/月（團隊） 企業內容運營 AI 內容生成附加
Storyblok 良好——視覺編輯焦點 免費層，然後 €106/月（業務） 需要視覺預覽的營銷團隊 AI 驅動的內容創建
Strapi 良好——自託管靈活性 免費（自託管），雲從 $29/月開始 想要完全控制的團隊 社區插件
Payload CMS 優秀——代碼優先、TypeScript 原生 免費（自託管），雲 2025 年開始 開發人員重型團隊、Next.js 項目 通過插件擴展

沒有通用的最佳選擇。這取決於你的團隊、你的內容複雜性和你的預算。如果你想幫助評估選項，我們已經為數十個團隊進行過此分析。

常見問題

什麼是結構化內容，為什麼對 SEO 很重要？ 結構化內容將信息存儲為有類型、帶標籤的數據字段，而不是原始 HTML。對於 SEO，這很重要，因為搜索引擎——尤其是 Google 的 AI 驅動系統——可以更準確地理解和引用結構化內容。由結構化內容構建的頁面傾向於有更乾淨的 HTML 輸出、適當的標題層次結構和更一致的模式標記，所有這些都是 2025 年的排名信號。

WordPress 可以用作無頭 CMS 嗎？ 從技術上講是的。WordPress 有一個 REST API，可以用 WPGraphQL 擴展。但核心問題仍然存在：你的內容仍然在數據庫中作為 HTML 塊存儲。使用 WordPress 無頭可以讓你訪問非結構化內容的 API。你獲得無頭架構的好處（前端靈活性、更好的性能），但沒有結構化內容的好處。對於一些團隊，那是可接受的權衡。對於大多數人，這不值得複雜性。

從 WordPress 遷移到無頭 CMS 需要多少成本？ 這取決於內容量和複雜性。擁有 50-100 頁乾淨內容的小網站可能需要 2-4 週的開發工作。具有數千篇文章、自定義文章類型、ACF 字段和短代碼密集內容的大型網站可能需要 2-4 個月。內容轉換工作——將 HTML 塊轉換為結構化數據——通常佔總工作量的 40-60%。檢查我們的定價頁面以了解無頭 CMS 項目的大概估計。

AI 概覽會降低我的 WordPress 網站的排名嗎？ 不直接——Google 不處罰 WordPress 網站。但 AI 概覽和類似功能更喜歡容易解析和理解的內容。具有乾淨、結構良好的 HTML（結構化內容自然產生）的網站往往被引用的頻率更高。一個包含插件生成的標記、內聯樣式和破損短代碼的雜亂 WordPress 頁面對任何 AI 系統來說都更難可靠地處理。

如果我停用插件，我的 WordPress 內容會發生什麼？ 來自該插件的任何短代碼都將呈現為文章中的文字。例如，如果你停用圖庫插件，你的訪客將在頁面上看到 [gallery ids="1,2,3"] 作為純文本。基於區塊的插件可能會留下破損的 HTML 或空容器。這是最常見的——也是最令人沮喪的——WordPress 內容問題之一。無頭 CMS 中的結構化內容沒有此問題，因為內容和呈現完全分離。

Gutenberg（WordPress 區塊編輯器）被認為是結構化內容嗎？ 這是走向結構的一步，但達不到要求。Gutenberg 區塊在文章內容塊內的 HTML 注釋中編碼類型信息。此元數據不存儲在單獨的數據庫字段中、不可通過 SQL 查詢、也不根據模式進行驗證。與經典編輯器相比，它的結構更多，但在根本上不同於 Sanity 或 Contentful 等無頭 CMS 實現的真正結構化內容。

哪個無頭 CMS 最適合 Next.js 項目？ Sanity 和 Payload CMS 是 2025 年 Next.js 開發的最強選項。Sanity 提供出色的實時預覽功能和成熟的生態系統。Payload CMS 特別有趣，因為它是 TypeScript 原生的，可以在 Next.js 應用本身內運行。Contentful 和 Storyblok 也有可靠的 Next.js 集成。「最佳」選擇取決於你是優先考慮內容建模靈活性、視覺編輯、自託管還是企業功能。

在不進行完整遷移的情況下如何使我的內容 AI 就緒？ 如果完整遷移現在不可行，你可以採取漸進步驟。使用 Yoast 或 RankMath 等插件向你的 WordPress 頁面添加 JSON-LD 結構化數據。清理短代碼使用——在可能的情況下用本機 Gutenberg 區塊替換它們。使用 ACF 和 WPGraphQL 創建內容 API 層，該層將關鍵字段公開為結構化數據。這些步驟不會給你真正的結構化內容，但它們會改善 AI 可讀性，同時你計劃適當的遷移。