TYPO3 到無頭 CMS 遷移：實用開發者指南

如果你在 TYPO3 上花過相當多的時間工作，你就知道它是一頭野獸。不是壞的那種——它非常強大，特別是對於具有複雜內容結構、多語言設置和細粒度權限的大型歐洲企業網站。但運行 TYPO3 安裝的團隊中越來越多人意識到：單體架構正在阻礙他們。前端開發人員想使用 React 或 Vue。市場行銷團隊想要全通路內容交付。DevOps 想要更簡單的部署。每個人都想要更好的效能。

這就是無頭 CMS 遷移的用武之地。我多次經歷過這個過程——將組織從 TYPO3 遷移到無頭架構——我會坦誠相告：它永遠不像供應商行銷頁面所宣傳的那麼簡單。但當條件合適時，這絕對值得做。本指南涵蓋了從 TYPO3 遷移到無頭 CMS 時涉及的真實決策、陷阱和策略。

目錄

• 為什麼團隊離開 TYPO3
• 遷移何時真正有意義
• 選擇你的無頭 CMS
• 內容建模：困難的部分
• 數據遷移策略
• 前端架構決策
• 處理 TYPO3 特定功能
• 遷移期間的搜尋引擎最佳化保護
• 測試和上線策略
• 真實遷移時間表和成本
• 常見問題

為什麼團隊離開 TYPO3

讓我明確說明：TYPO3 不是壞軟體。它成熟、維護良好，擁有一個專注的社群，特別是在德國、奧地利和瑞士。但它帶有某些架構限制，在規模擴大時會變得痛苦。

開發人員體驗摩擦

TYPO3 的樣板系統（Fluid）很強大但很小眾。尋找懂 Fluid、TypoScript 和 Extbase/TYPO3 擴展框架的開發人員變得越來越困難。學習曲線陡峭，年輕開發人員壓倒性地傾向於使用 JavaScript 框架。我見過招聘時間翻倍的情況，因為團隊找不到精通 TYPO3 的開發人員。

效能限制

TYPO3 通過 PHP 進行伺服器端頁面渲染。雖然快取有幫助，但你在本質上受到單體請求週期的限制。靜態網站生成和邊緣渲染——現代框架擅長的東西——對 TYPO3 的架構並非原生支援。TYPO3 Headless 擴展（EXT:headless）存在，並將 TYPO3 轉變為 API，但此時你維護的是一個做的工作越來越少的 PHP 後端。

內容重複使用的挑戰

TYPO3 的內容模型是以頁面為中心的。內容元素存在於頁面上。如果你需要同時向行動應用程式、數位資訊亭、電子郵件系統和網站交付內容，TYPO3 的模型在每一步都會與你作對。無頭 CMS 平台從一開始就將內容視為結構化數據，使多通路交付變得自然而非勉強。

總體擁有成本

運行 TYPO3 意味著維護 PHP 伺服器、管理 TYPO3 核心更新（在主要版本之間可能很複雜）以及保持擴展相容性。無頭 SaaS CMS 消除了大部分基礎設施開銷。即使是自託管無頭選項（如 Strapi 或 Directus）通常需要更少的營運工作。

遷移何時真正有意義

並非每個 TYPO3 網站都需要變成無頭的。以下是我誠實的評估：

場景	遷移？	為什麼
簡單宣傳網站，50 頁，一種語言	可能不需要	過度設計。TYPO3 在這裡運作良好。
多語言企業網站有行動應用程式	是	無頭對全通路交付閃閃發光
複雜產品數據的電子商務	是	更好的前端靈活性、API 優先集成
具有重型 TYPO3 擴展的網站（新聞、事件、表單）	也許	先審查擴展依賴項
帶有 TYPO3 後端工作流的內部入口網站	謹慎	你可能會失去難以替換的工作流功能
團隊無法聘請 TYPO3 開發人員	是	可持續性比功能更重要

當你已經計劃重新設計或平台升級時，遷移最有意義。純粹出於技術原因進行遷移——沒有業務觸發——通常難以獲得預算批准。

選擇你的無頭 CMS

這是團隊卡住的地方。有數十個無頭 CMS 選項，正確的選擇在很大程度上取決於你的具體情況。

企業級選項

Contentful 仍然是企業無頭 CMS 的市場領導者。定價從 Team 計劃的約 300 美元/月開始，升級到自訂企業定價（通常根據使用情況為 2,000-10,000 美元+/月）。它成熟、文檔完善，擁有出色的 SDK。內容建模很靈活，Compose 功能處理 TYPO3 編輯者習慣的頁面構建用例。

Sanity 是我個人對開發人員體驗最喜歡的。定價模式很寬鬆——免費層處理許多小項目，Team 計劃為 15 美元/用戶/月，非常合理。Sanity Studio 可以用 React 完全自訂，因此你可以構建與 TYPO3 後端相匹配或超越的編輯體驗。GROQ 查詢語言需要一些時間適應，但一旦熟悉，它就非常強大。

Storyblok 值得特別關注 TYPO3 遷移，因為它提供了一個視覺編輯器，感覺像 TYPO3 後端用戶熟悉的。定價從 Entry 計劃的 €99/月開始。它在與 TYPO3 用戶群大量重疊的 DACH 地區特別受歡迎。

開源替代方案

Strapi（2024 年發佈 v5）是領先的開源選項。你可以自託管或使用 Strapi Cloud（每個座位每月 29 美元起）。它基於 Node.js，使用 PostgreSQL 或 MySQL 數據庫，提供快速增長的外掛生態系統。

Directus 用 API 和管理面板包裝任何 SQL 數據庫。如果你想保留現有數據庫結構並逐漸遷移，這是一個絕佳選擇。開源版本功能完整；雲版本從 99 美元/月開始。

比較表：TYPO3 遷移無頭 CMS 選項

功能	Contentful	Sanity	Storyblok	Strapi	Directus
託管模型	SaaS	SaaS + 自託管	SaaS	自託管 + 雲	自託管 + 雲
視覺編輯器	Compose（附加功能）	可自訂	內置	外掛	有限
多語言	優秀	良好	優秀	良好	良好
起始價格	$300/月	免費層	€99/月	免費（OSS）	免費（OSS）
TYPO3 編輯者熟悉度	中等	低	高	中等	中等
內容建模	靈活	非常靈活	基於組件	靈活	基於數據庫
網頁掛鉤/工作流	是	是	是	是	是

我們通過我們的無頭 CMS 開發服務與大多數這些平台合作。選擇通常歸結為編輯者是否需要視覺編輯體驗（Storyblok、Contentful Compose）或開發人員靈活性是否是優先事項（Sanity、Strapi）。

內容建模：困難的部分

這是大多數遷移出現問題的地方。TYPO3 的內容模型從根本上不同於無頭 CMS 內容模型，你不能直接將一個映射到另一個。

了解 TYPO3 的內容結構

在 TYPO3 中，內容組織為：

• 頁面（頁面樹）具有屬性和中繼數據
• 內容元素（tt_content）位於頁面上的列中
• 擴展添加自訂記錄類型（新聞、事件等）
• 分類和文件參考通過 sys_file_reference 表連結
• TypoScript 配置影響渲染和數據流

這是一個以頁面為先的模型。內容存在於頁面的上下文中。

無頭內容建模

無頭 CMS 平台使用內容優先模型。你定義內容類型（如文章、作者、產品）及其字段，然後從對這些內容項的參考組成頁面。頁面本身通常只是另一個內容類型。

翻譯工作看起來像這樣：

TYPO3 頁面樹          →  頁面內容類型，具有 slug/層級字段
tt_content（文本）        →  富文本組件/區塊
tt_content（圖像）       →  帶有資產參考的媒體組件
tx_news_domain_model_news →  文章/新聞內容類型
分類（sys_category） →  標籤/分類內容類型
文件參考          →  資產管理（DAM）

實踐建議

不要試圖在無頭 CMS 中複製 TYPO3 的內容模型。這是重新思考和改進內容架構的機會。首先從審計開始：

1. 存在哪些內容類型？ 匯出 tt_content CType 並列出所有擴展記錄類型。
2. 實際使用哪些字段？ TYPO3 表有數十個字段。大多數內容只使用少數幾個。
3. 關係是什麼？ 繪製內容如何參考其他內容的地圖。
4. 翻譯設置是什麼？ TYPO3 支持連接和自由翻譯模式——你的無頭 CMS 需要處理你使用的任何一種。

-- 有用的 TYPO3 審計查詢
-- 按類型計算內容元素
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- 按 doktype 計算頁面
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- 查找所有使用中的語言
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

數據遷移策略

一旦你在目標 CMS 中定義了內容模型，你需要實際移動數據。有三種主要方法。

方法 1：基於腳本的匯出/匯入

編寫直接查詢 TYPO3 數據庫的腳本，轉換數據，並通過其管理 API 將其推送到無頭 CMS。這是最常見的方法，給你最多的控制權。

// 示例：將 TYPO3 新聞記錄遷移到 Contentful
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');

async function migrateNews() {
  const db = await mysql.createConnection({
    host: 'localhost',
    database: 'typo3_db',
    user: 'root',
    password: 'password'
  });

  const client = contentful.createClient({
    accessToken: 'your-management-token'
  });

  const space = await client.getSpace('your-space-id');
  const env = await space.getEnvironment('master');

  const [rows] = await db.execute(`
    SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
           n.path_segment, p.slug as category_slug
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
    LEFT JOIN sys_category c ON c.uid = mm.uid_local
    WHERE n.deleted = 0 AND n.hidden = 0
  `);

  for (const row of rows) {
    const entry = await env.createEntry('article', {
      fields: {
        title: { 'en-US': row.title },
        teaser: { 'en-US': row.teaser },
        body: { 'en-US': convertRteToRichText(row.bodytext) },
        publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
        slug: { 'en-US': row.path_segment }
      }
    });
    await entry.publish();
    console.log(`已遷移：${row.title}`);
  }
}

convertRteToRichText 函數是事情變得混亂的地方。TYPO3 的 RTE 輸出是 HTML（通常帶有內部連結的自訂標籤，如 <link>）。轉換為結構化富文本格式因 CMS 而異——Contentful 使用自己的富文本 JSON，Sanity 使用可移植文本等。

方法 2：TYPO3 Headless 擴展作為橋接

在現有 TYPO3 實例上安裝 EXT:headless 擴展。這將 TYPO3 轉變為 JSON API，然後你可以從遷移腳本使用它，甚至可以在為新前端構建時臨時使用它作為無頭後端。

這種方法有一個很好的優勢：你可以首先針對 TYPO3 的無頭 API 運行新前端，然後稍後將後端切換到適當的無頭 CMS。它將遷移分為兩個階段。

方法 3：手動重建

對於較小的網站（100 頁以下），有時在新 CMS 中手動重建內容更快。特別是如果你也在重新構造和重寫內容——你可能應該這樣做。

前端架構決策

有了無頭 CMS，你需要一個單獨的前端。這是真正的效能收益發生的地方。

Next.js

最受歡迎的選擇。伺服器端渲染、靜態生成、增量靜態再生——Next.js 處理你可能需要的所有渲染策略。App Router（自 Next.js 13.4 以來穩定）與 React 伺服器組件特別適合於內容密集型網站。我們通過我們的 Next.js 開發實踐做很多這樣的工作。

Astro

對於不需要太多互動的內容密集型網站，Astro 是驚人的。默認情況下不發送任何 JavaScript，並通過其島嶼架構支持部分水化。我們已經看到 Astro 構建始終達到 95+ 的 Lighthouse 分數，這是對典型 TYPO3 前端效能的顯著改進。如果這引起你的興趣，請查看我們的 Astro 開發服務。

Nuxt

如果你的團隊更喜歡 Vue 而不是 React，Nuxt 3 是 Next.js 的等價物。堅實的選擇、出色的 DX、良好的生態系統。

框架	最適合	發送的 JS	學習曲線	CMS 集成
Next.js	動態應用程式、電子商務、儀表板	中-高	中等	優秀
Astro	內容網站、部落格、行銷	最少	低	優秀
Nuxt 3	Vue 團隊、內容 + 應用程式	中等	中等	良好
SvelteKit	想要簡單性的小團隊	低	低-中等	不斷增長

處理 TYPO3 特定功能

某些 TYPO3 功能在無頭世界中沒有直接等價物。以下是處理常見功能的方法。

工作區和版本控制

TYPO3 的工作區系統讓編輯者在發佈前針對多個頁面進行更改。大多數無頭 CMS 平台提供環境或發佈排程，部分複製此功能。Contentful 有環境和排程發佈。Sanity 有版本（最近推出）。開箱即用的都不如 TYPO3 工作區那麼複雜，因此如果你的編輯者嚴重依賴工作區，請計劃進行工作流調整。

後端用戶權限

TYPO3 的權限系統極其細粒度——頁面級、內容元素級、字段級訪問控制。無頭 CMS 平台在這裡差異很大。Contentful 的角色系統不錯但粒度較低。Sanity 的更靈活但需要自訂配置。Strapi 的基於角色的訪問很好。審計你當前的權限矩陣，並驗證目標 CMS 在提交前能否處理它。

表單處理

TYPO3 的表單框架（EXT:form）從 YAML 配置生成表單。在無頭設置中，你需要一個表單服務。選項包括 Formspree、Basin 或使用無伺服器函數構建自己的。如果你使用 Next.js，伺服器操作使表單處理變得簡單。

多語言和本地化

這很關鍵，通常被低估。TYPO3 的翻譯處理——具有語言覆蓋概念、連接/自由模式和後備鏈——非常複雜。在選擇 CMS 之前，繪製你的確切翻譯要求。Storyblok 和 Contentful 很好地處理區域設置管理。Sanity 需要為複雜的多語言場景進行更多自訂設置。

遷移期間的搜尋引擎最佳化保護

這一部分可能是最重要的。一次失敗的遷移可能會摧毀你的有機流量。

URL 映射

匯出你的 TYPO3 網站的每個 URL。每一個。使用 Screaming Frog 或 wget --spider 等爬蟲來構建完整的 URL 列表。然後創建重定向地圖：

/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf

對所有更改的 URL 實現 301 重定向。在 Next.js 中，這進入 next.config.js：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path/:slug*',
        destination: '/new-path/:slug*',
        permanent: true,
      },
      // ... 還有幾百個，最好從 JSON 文件加載
    ];
  },
};

對於大型重定向列表（500+），考慮在邊緣處理重定向（Vercel Edge Middleware、Cloudflare Workers 或 nginx）而不是在應用程式配置中。

中繼數據遷移

TYPO3 將 SEO 中繼數據存儲在頁面表中（seo_title、description、og_image 等），可能在擴展中（如 EXT:cs_seo 或 EXT:seo_basics）。提取所有這些數據並將其遷移到無頭 CMS 內容模型。別忘了：

• 頁面標題和中繼描述
• Open Graph 和 Twitter 卡片數據
• 規範 URL
• 用於多語言網站的 hreflang 標籤
• 結構化數據 / JSON-LD 架構
• XML 網站地圖生成

監視

在遷移前為新域/子域設置 Google Search Console。上線後，在前兩週內每天監視覆蓋率報告。注意爬蟲錯誤、掉落的頁面和索引問題。準備回滾計劃。

測試和上線策略

我建議分階段方法而不是大爆炸式轉換。

階段 1：並行運行（2-4 週）

在預備域上運行新無頭網站。將內容平衡與 TYPO3 網站進行比較。讓編輯測試內容工作流。使用 Percy 或 Playwright 等工具運行自動化視覺回歸測試。

階段 2：軟啟動

使用 CDN 級別的功能標誌或 A/B 測試將一小部分流量路由到新網站。監視核心網頁指標、錯誤率和用戶行為。

階段 3：完全轉換

切換 DNS 或反向代理配置。啟動所有重定向。在前 48 小時內積極監視。保持 TYPO3 實例運行（只讀）至少 30 天作為參考。

階段 4：停用

確信遷移穩定後，關閉 TYPO3 基礎設施。存檔數據庫和 fileadmin 目錄。當有人詢問舊內容時，你會感謝自己。

真實遷移時間表和成本

讓我們誠實談論成本。我見過太多團隊低估遷移項目。

項目大小	頁數	時間表	估計成本
小	50-200	6-10 週	$15,000-$35,000
中等	200-1,000	12-20 週	$40,000-$90,000
大	1,000-5,000	20-36 週	$80,000-$200,000
企業	5,000+	6-12 個月	$150,000-$500,000+

這些數字包括內容建模、遷移腳本編寫、前端開發、測試和啟動支持。它們不包括 CMS 許可成本，這因平台而異。

最大的成本驅動因素是：

1. 內容類型的數量和複雜性——不是原始頁面計數
2. 需要構建等效功能的自訂 TYPO3 擴展
3. 多語言設置複雜性
4. 集成要求（搜尋、電子商務、認證）
5. 編輯培訓和變更管理

如果你想討論遷移對你的特定設置可能是什麼樣子，聯繫我們或查看我們的定價頁面了解參與模式。

常見問題

我可以使用 TYPO3 作為無頭 CMS 而不是遷移到新的嗎？ 是的，EXT:headless 擴展（以前稱為"headless"）將 TYPO3 轉變為 JSON API。這可以是一個很好的中間步驟。但是，你仍然維護著一個 TYPO3 後端及其所有運營開銷。作為橋接策略很有意義，但如果你的目標是減少 TYPO3 依賴性，通常不是長期答案。

典型的 TYPO3 到無頭 CMS 遷移需要多長時間？ 對於中等規模的網站（200-1,000 頁），預計從啟動到啟動需要 3-5 個月。內容建模和遷移腳本編寫階段通常比團隊預期的花費更長。一旦定義了內容模型，前端開發通常可以並行運行。具有多種語言和複雜集成的企業遷移可能需要 6-12 個月。

在遷移期間我會失去搜尋引擎排名嗎？ 如果你做得正確，不應該。關鍵因素是：為所有更改的 URL 實現適當的 301 重定向，遷移所有中繼數據，維護網站結構和內部連結，以及將更新的網站地圖提交給 Google。遷移後排名暫時下降 2-4 週是正常的，通常會恢復。永久損失通常表示遺漏的重定向或丟失的內容。

哪個無頭 CMS 最適合替換 TYPO3？ 這取決於你的優先事項。Storyblok 通常是 TYPO3 編輯最順利的過渡，因為其視覺編輯功能。Contentful 是最安全的企業選擇，生態系統最成熟。Sanity 提供最多的開發人員靈活性。Strapi 是如果你需要開源和自託管的最佳選項。沒有單一的最佳答案——這取決於你的團隊、預算和要求。

遷移後我的 TYPO3 擴展會發生什麼？ 每個擴展都需要單獨評估。常見擴展（如 EXT:news、EXT:cal 和 EXT:powermail）需要在新堆棧中提供等效功能。新聞/部落格功能易於使用任何無頭 CMS 複製。日曆和事件功能可能需要第三方服務。表單需要新的解決方案（表單構建器、無伺服器函數或 Formspree 之類的服務）。自訂擴展需要最多分析。

在遷移期間如何處理 TYPO3 的 fileadmin 資產？ 你需要將所有資產（圖像、PDF、視頻）遷移到新 CMS 的資產管理系統或單獨的 DAM/CDN。編寫腳本從 fileadmin 下載，通過其 API 上傳到新平台，並將舊文件參考映射到新資產 ID。別忘了處理已處理/調整大小的圖像——大多數無頭 CMS 平台會自動處理圖像轉換，因此你通常只需要遷移原始文件。

我可以增量遷移還是必須一次完成？ 增量遷移對大型網站是可能的，有時是可取的。你可以使用反向代理將某些 URL 路徑路由到新無頭前端，同時在 TYPO3 上保留其他路徑。這讓你可以按部分遷移。權衡是同時管理兩個系統的增加複雜性，以及在兩個系統之間維護一致的導航和設計。

我應該如何處理抵制變更的 TYPO3 後端用戶？ 變更管理確實是一半的戰鬥。從編輯期開始，尤其是在內容建模階段，而不是在構建所有內容後。選擇具有良好編輯體驗的 CMS（Storyblok 和 Contentful 傾向於獲得最佳編輯反饋）。創建針對你的設置的文檔和培訓材料。誠實對待正在改變的內容和原因——當編輯者看到改進的預覽體驗和更快的發佈工作流時，他們通常會同意。