您的部署需要等待 40 分鐘，而 TYPO3 這周第三次重新生成快取。前端開發人員提交了另一張工單，詢問為什麼無法在不涉及 TypoScript 的情況下發布簡單的輪播。行銷部門希望在行動應用程式和電子郵件中看到相同的內容塊——TYPO3 並非為此而設計的。您已經運行了這個單體應用多年，也許長達十年，它一直為您服務得很好。但使 TYPO3 對複雜歐洲企業網站強大的架構——內容、範本和渲染之間的緊密耦合——現在正成為拖累每個衝刺週期的東西。React 元件閒置不用。API 優先的交付仍然是理論上的。您的內容被困在一個假設它只存在於一個網站上的系統中。問題不再是是否要遷移——而是如何移動 47,000 條內容記錄、保留 8 種語言的 URL 結構、在您的團隊發布功能時保持 SEO 完整。

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

目錄

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

團隊為何離開 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 的市場領導者。定價從每月約 $300 的 Team 方案開始，按比例縮放到自訂企業定價（根據使用情況，通常每月 $2,000-$10,000+）。它成熟、文檔良好，擁有出色的 SDK。內容建模靈活，Compose 功能處理 TYPO3 編輯者習慣的頁面生成用例。

Sanity 是我個人最喜歡的開發人員體驗。定價模型很慷慨——免費層處理許多小型項目，Team 方案每用戶每月 $15。Sanity Studio 完全可以用 React 自訂，因此您可以建立超越或匹配 TYPO3 後端提供的編輯體驗。GROQ 查詢語言需要一些習慣，但一旦掌握，它非常強大。

Storyblok 對於 TYPO3 遷移值得特別關注，因為它提供了一個對 TYPO3 後端用戶感到熟悉的視覺編輯器。定價從 Entry 方案的 €99/月開始。它在 DACH 區域特別受歡迎，該區域與 TYPO3 的用戶群有很大重疊。

開源替代品

Strapi（v5 在 2024 年發布）是領先的開源選項。您可以自託管或使用 Strapi Cloud（每個座位每月 $29 起）。它基於 Node.js，使用 PostgreSQL 或 MySQL 資料庫，提供快速增長的插件生態系統。

Directus 在任何 SQL 資料庫周圍包覆 API 和管理員面板。如果您想保留現有的資料庫結構並逐步遷移，這是一個很好的選擇。開源版本具有完整功能；雲端版本從 €99/月開始。

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

功能 Contentful Sanity Storyblok Strapi Directus
託管模式 SaaS SaaS + 自託管 SaaS 自託管 + 雲端 自託管 + 雲端
視覺編輯器 Compose（附加項） 可自訂 內置 插件 有限
多語言 優秀 良好 優秀 良好 良好
起始價格 $300/月 免費層 €99/月 免費 (OSS) 免費 (OSS)
TYPO3 編輯者熟悉度 中等 低 高 中等 中等
內容建模 靈活 非常靈活 基於元件 靈活 資料庫驅動
Webhooks/工作流程 是 是 是 是 是

我們通過 無頭 CMS 開發服務 與大多數平台合作。選擇通常取決於您的編輯是否需要視覺編輯體驗（Storyblok、Contentful Compose），還是開發人員靈活性是優先選項（Sanity、Strapi）。

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

內容建模：困難的部分

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

了解 TYPO3 的內容結構

在 TYPO3 中，內容被組織為：

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

這是一個以頁面為首的模型。內容存在於頁面的背景下。

無頭內容建模

無頭 CMS 平台使用以內容為優先的模型。您定義內容類型（如 Article、Author、Product），配置欄位，然後從對這些內容項目的參考組成頁面。頁面本身通常只是另一種內容類型。

轉換工作看起來像這樣：

TYPO3 頁面樹      →  具有 slug/階層欄位的頁面內容類型
tt_content (文本)  →  富文本元件/塊
tt_content (圖像)  →  具有資產參考的媒體元件
tx_news_domain_model_news →  文章/新聞內容類型
分類 (sys_category) →  標籤/分類內容類型
檔案參考         →  資產管理 (DAM)

實用建議

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

  1. 存在哪些內容類型？ 匯出您的 tt_content CTypes 並列出所有擴展記錄類型。
  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;

-- 按文件類型計算頁面
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(`Migrated: ${row.title}`);
  }
}

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

方法 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，並通過其 Islands Architecture 支援部分水合。我們看到 Astro 構建的 Lighthouse 分數一直達到 95+，這是對典型 TYPO3 前端性能的巨大改進。如果這對您感興趣，請查看我們的 Astro 開發服務。

Nuxt

如果您的團隊更喜歡 Vue 而不是 React，Nuxt 3 就是 Next.js 的等價物。堅實的選擇，優秀的開發者體驗，良好的生態系統。

框架 最適合 提供的 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，Server Actions 使表單處理很直接。

多語言和本地化

這是至關重要且經常被低估的。TYPO3 的翻譯處理——及其語言覆蓋、連接/自由模式和後備鏈的概念——是精密的。在選擇 CMS 之前映射您的確切翻譯要求。Storyblok 和 Contentful 良好處理語言設置。Sanity 對複雜多語言場景需要更多自訂設置。

遷移期間的 SEO 保護

本部分可能是最重要的。搞砸的遷移會摧毀您的有機流量。

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 Card 數據
  • 標準 URL
  • 多語言網站的 hreflang 標籤
  • 結構化數據 / JSON-LD 架構
  • XML Sitemap 生成

監控

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

測試和上線策略

我推薦分階段方法，而不是大爆炸式轉換。

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

在臨時域名上執行新的無頭網站。將內容與 TYPO3 網站進行奇偶比較。讓編輯測試內容工作流程。使用 Percy 或 Playwright 等工具執行自動化視覺迴歸測試。

第 2 階段：軟啟動

使用功能旗標或 CDN 級別的 A/B 測試將小百分比的流量路由到新網站。監控 Core Web Vitals、錯誤率和用戶行為。

第 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 個月。

遷移期間我會失去 SEO 排名嗎？ 如果做得正確，您不應該。關鍵因素是：為所有改變的 URL 實施正確的 301 重定向、遷移所有中繼資料、維護您的網站結構和內部連結，以及向 Google 提交更新的 Sitemap。遷移後排名暫時下降 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，而是從早期開始。選擇具有良好編輯體驗的 CMS（Storyblok 和 Contentful 往往獲得最好的編輯反饋）。建立特定於您設置的文檔和培訓材料。並誠實地解釋發生變化的原因——編輯通常會同意，當他們看到改進的預覽體驗和更快的發布工作流程時。