我在過去五年間帶領過大約 40 次 CMS 遷移，我被問得最多的問題是：「這到底需要多長時間？」不是銷售版本。真實的答案。

事實是這樣的 -- 真實的答案幾乎總是比你想的要久，但比你最壞的恐懼要短。一個小型行銷網站？你要準備 3-6 週。一個中型商業網站，擁有部落格、電商和自訂整合？準備 2-4 個月。一個擁有 10,000+ 頁面、多個語言版本和舊系統的企業？做好 4-8 個月的準備。

但這些範圍沒有背景脈絡就毫無意義。讓我詳細說明每個階段會發生什麼、團隊在哪裡浪費時間，以及如何防止你的遷移成為那些拖延一年的恐怖故事。

目錄

CMS 遷移時間表：2026 年 WordPress 至 Next.js

為什麼在 2026 年從 WordPress 遷移到 Next.js？

讓我直言：並非每個 WordPress 網站都需要遷移。如果你運營一個個人部落格或一個運作正常的小型商業網站，WordPress 仍然完全足夠。但在 2026 年，團隊確實有真實且可衡量的原因要遷移到擁有無頭 CMS 的 Next.js：

  • 效能：使用靜態生成和邊緣渲染的 Next.js 網站在核心網頁指標上的得分始終在 90 分以上。WordPress 網站平均約為 50-65 分，無需進行大量最佳化工作。
  • 安全性：將前端與 CMS 分離可以消除最常見的 WordPress 攻擊載體。在 2025 年，Sucuri 報告稱 WordPress 佔感染 CMS 網站的 96.2%。
  • 開發人員體驗：基於 React 的元件架構意味著更快的迭代和更輕鬆的招聘。WordPress PHP 人才庫正在萎縮 -- Stack Overflow 的 2025 年調查顯示 PHP 下降到第 14 位的語言受歡迎度。
  • 可擴展性：部署在 Vercel 或 Cloudflare 上的邊緣 Next.js 網站可以處理流量激增，無需「再加一個伺服器」的做法。

如果你正在處理效能問題、安全顧慮或一個對觸碰你的 WordPress 程式碼庫感到厭倦的開發團隊，遷移就很有意義。我們在 Next.js 開發能力 頁面上詳細介紹了技術方法。

按網站規模劃分的遷移時間表概述

以下是誠實的分解。這些時間表假設有專門的團隊（不是與其他項目分享時間的人員）和相當有回應的利益相關者。

網站規模 頁數 典型複雜度 時間表 團隊規模
小型（行銷/宣傳） 5-50 低 -- 少數整合、標準內容 3-6 週 2-3 人
中型（商業） 50-500 中等 -- 部落格、表單、某些整合、多個樣板 8-16 週 3-5 人
大型（中端市場） 500-5,000 高 -- 電商、多作者、複雜工作流程 3-5 個月 4-7 人
企業 5,000+ 非常高 -- 多個語言版本、舊系統整合、合規性 4-8 個月 6-12 人

這些是構建時間表，不是日曆時間表。日曆時間總是更長，因為利益相關者審查、反饋迴圈，以及不可避免的兩週，在那期間行銷副總在設計核准階段放假。

第 1 階段：探索和稽核

持續時間：1-3 週

這是大多數機構急於求成、大多數遷移走歪的地方。探索不只是「看看 WordPress 網站然後列一個清單」。這是法醫工作。

實際發生的情況

  • 內容清單：編目每種內容類型、分類法、自訂欄位和媒體資產。我使用 Screaming Frog 來爬取現有網站並匯出完整的 URL 地圖。對於一個 2,000 頁的網站，僅此就需要整整一天才能妥善組織。
  • 外掛稽核：記錄每個活躍外掛及其功能。平均 WordPress 網站有 20-30 個外掛。每個都代表你要嘛需要複製、要嘛用 SaaS 工具替換、要嘛有意放棄的功能。
  • 整合對應：表單發送到 HubSpot？透過 WooCommerce 進行支付處理？透過 Google Tag Manager 和自訂事件進行分析？繪製完整的圖景。
  • SEO 基準：匯出所有中繼標題、描述、標準 URL、結構化資料和內部連結模式。你無法在遷移中損失 SEO 權益。
  • 利益相關者訪談：與實際使用 CMS 的人進行交談。內容編輯、行銷人員、管理部落格的任何人。他們的工作流程比技術架構更重要。

探索成果

  • 內容模型文件
  • 整合相依性地圖
  • SEO 遷移計畫
  • 風險登記（可能導致時間表爆炸的東西）
  • 初步架構建議

跳過或倉促進行探索是時間表爆炸的首要原因。我見過一個「快速 6 週遷移」變成 5 個月的難題，因為沒有人記錄 WordPress 網站有 47 個自訂 Gravity Forms，具有條件邏輯，將資料傳送到三個不同的 CRM。

CMS 遷移時間表：2026 年 WordPress 至 Next.js - 架構

第 2 階段：架構和規劃

持續時間：1-2 週

握著探索資料，你做出重大決定。

選擇你的無頭 CMS

Next.js 是你的前端框架，但你仍然需要一個內容管理後端。2026 年的首選：

CMS 最適合 定價（2026 年） 學習曲線
Sanity 複雜內容模型、即時協作 免費層級，然後 $99-$949/月 中等
Contentful 企業團隊、強大治理 $300/月及以上 中等
Storyblok 視覺編輯、行銷團隊 免費層級，然後 €106-€399/月 低
Payload CMS 開發人員優先、自託管控制 免費（開源）、雲端起價 $50/月 較高
WordPress（無頭） 想保持 WordPress 管理員的團隊 現有託管成本 低（熟悉的）

是的，你可以透過 WPGraphQL 或 REST API 將 WordPress 用作無頭 CMS。一些團隊這樣做是為了在獲得 Next.js 前端的同時保持內容編輯器在熟悉的環境中。這是一種有效的方法，儘管你繼承一些 WordPress 維護開銷。

我們幫助團隊評估這些選項作為我們 無頭 CMS 開發 工作的一部分。正確的選擇在很大程度上取決於你的編輯團隊的技術舒適度。

架構決定

  • 渲染策略：靜態網站生成（SSG）、漸進式靜態再生（ISR）還是伺服器端渲染（SSR）？2026 年大多數網站使用混合方法 -- 內容頁面使用 ISR，個性化或即時頁面使用 SSR。
  • 託管：Vercel 是 Next.js 的預設值，但 Netlify、Cloudflare Pages 和 AWS Amplify 都是可行的。Vercel 的 Pro 方案每個使用者每月 $20 可以涵蓋大多數團隊。
  • API 架構：你會使用 CMS 的原生 API、構建中間件層還是採用 tRPC 之類的類型安全 API 呼叫？
  • 驗證：如果你有閘門內容或成員區域，請提前規劃此內容。NextAuth.js（現在 Auth.js v5）可以處理大多數模式。

第 3 階段：內容建模和 CMS 設定

持續時間：1-3 週

這是你在新 CMS 中構建內容結構的地方。不要只是複製你的 WordPress 結構 -- 這是你修復多年累積內容債務的機會。

內容模型設計

WordPress 傾向於鼓勵平坦的內容模型：文章、頁面和透過 ACF 或 Meta Box 的大量自訂欄位。無頭 CMS 讓你能以結構化內容的方式思考。

// 示例：Sanity 中的部落格文章內容模型
export default defineType({
  name: 'blogPost',
  title: '部落格文章',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      type: 'string',
      validation: (Rule) => Rule.required().max(70),
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: { source: 'title' },
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
    defineField({
      name: 'body',
      type: 'portableText', // 富結構化內容
    }),
    defineField({
      name: 'seo',
      type: 'seoFields', // 可重用 SEO 物件
    }),
  ],
})

結構化內容意味著你的部落格文章內容不只是一大塊 HTML。它是你的前端可以以任何方式呈現的結構化區塊 -- 網頁、行動應用程式、電子郵件通訊，無論什麼。

CMS 配置

  • 設定角色和權限
  • 配置預覽功能（Next.js 中的即時預覽對編輯者採用至關重要）
  • 構建任何自訂輸入元件或驗證規則
  • 設定內容變更時觸發重建的 webhook

第 4 階段：前端構建

持續時間：2-8 週（最大的變數）

這是大多數日曆時間的去向。構建 Next.js 前端涉及：

設計和元件系統

如果你在遷移期間進行重新設計（我們約 70% 的客戶會這樣做），再加 2-4 週。如果你複製現有的設計，你可以更快地移動。

// 元件驅動架構示例
export default function BlogPost({ post }: { post: BlogPostType }) {
  return (
    <article>
      <PageHeader title={post.title} date={post.publishedAt} />
      <AuthorCard author={post.author} />
      <PortableText 
        value={post.body} 
        components={customComponents} 
      />
      <RelatedPosts posts={post.related} />
      <NewsletterSignup />
    </article>
  )
}

我強烈建議先構建元件庫，然後組合頁面。初期感覺更慢，但當你構建第 15 個頁面樣板時回報巨大。

關鍵構建工作

  • 每種內容類型的頁面樣板
  • 動態路由和全包路由
  • 導覽（包括巨型選單如果適用的話）
  • 搜尋功能（Algolia、Meilisearch 或 Next.js 內建）
  • 表單實現（取代 Gravity Forms、Contact Form 7 等）
  • 第三方整合（分析、聊天小工具、CRM 連線）
  • 影像最佳化（Next.js Image 元件搭配你 CMS 的影像 CDN）
  • Sitemap 生成
  • RSS 摘要
  • 301 重新導向對應

單單重新導向對應就可以在大型網站上花費數天。每個變更的 URL 都需要重新導向，否則你會浪費 SEO 權益。

第 5 階段：內容遷移

持續時間：1-4 週

內容遷移要嘛微不足道地簡單，要嘛惡夢般複雜。沒有中間地帶。

自動化遷移

對於結構化內容（部落格文章、產品、團隊成員），編寫遷移指令：

// 簡化的 WordPress 至 Sanity 遷移指令
import { createClient } from '@sanity/client'
import { wpClient } from './wordpress-api'

const sanity = createClient({
  projectId: 'your-project',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2026-01-01',
})

async function migratePosts() {
  const wpPosts = await wpClient.posts().perPage(100).get()
  
  for (const post of wpPosts) {
    await sanity.create({
      _type: 'blogPost',
      title: post.title.rendered,
      slug: { current: post.slug },
      // 將 WordPress HTML 轉換為 Portable Text
      body: htmlToPortableText(post.content.rendered),
      publishedAt: post.date,
    })
  }
}

htmlToPortableText 步驟是事情變得棘手的地方。WordPress 內容充滿了短代碼、內聯樣式和外掛特定的標記，這些不能清晰地對應到結構化內容。為清理預留時間。

手動內容工作

某些內容只需要人工注意：

  • 使用 Elementor、Divi 或 WPBakery 構建的複雜佈局頁面
  • 包含已停用外掛短代碼的內容
  • 需要重新最佳化或替代文字的媒體
  • 需要更新的內部連結

對於 500 頁網站，計劃 40-80 小時的手動內容工作。是的，真的。

第 6 階段：QA 和測試

持續時間：1-3 週

不要在這上面省事。我見過啟動因為 QA 被視為事後想法而延遲數月。

QA 檢查清單

  • 功能測試：每個表單、每個互動元素、每個動態功能
  • 跨瀏覽器測試：Chrome、Firefox、Safari、Edge。Safari 總有奇怪的東西。
  • 行動測試：真實裝置，不只是 Chrome DevTools。在實際 iPhone 和 Android 裝置上測試。
  • 內容驗證：現場檢查至少 20% 的遷移內容以排查格式問題
  • SEO 稽核：比較舊中繼標籤與新標籤。驗證結構化資料。測試所有重新導向。
  • 效能測試：Lighthouse 分數、現場核心網頁指標、使用 k6 之類工具的負載測試
  • 無障礙：WCAG 2.2 AA 合規性。運行 axe-core，但也要進行僅鍵盤導覽測試。
  • 分析驗證：確保所有事件上的追蹤正確啟動

重新導向測試

這值得自己特別說明。匯出舊網站中的每個 URL。將每個對應到其新 URL。測試每個單一重新導向。對於擁有數千個 URL 的企業網站，使用自動化測試：

# 使用 curl 測試重新導向
while IFS=, read -r old_url new_url; do
  status=$(curl -o /dev/null -s -w "%{http_code}" -L "$old_url")
  final=$(curl -o /dev/null -s -w "%{url_effective}" -L "$old_url")
  echo "$old_url -> $final (狀態：$status)"
done < redirects.csv

第 7 階段：啟動和啟動後

持續時間：1-2 週

啟動日

我傾向於在星期二或星期三早上啟動。絕不週五（你不想在週末偵錯）也絕不週一（人們仍在從週末趕上進度）。

啟動檢查清單：

  • DNS 變更（TTL 應在啟動前 48 小時降低）
  • SSL 憑證驗證
  • CDN 快取預熱
  • 監控前 4 小時的錯誤率
  • 在 Google Search Console 中驗證爬蟲錯誤
  • 檢查所有第三方整合是否啟動

啟動後（2 週）

  • 在 Google Search Console 中監控核心網頁指標
  • 監控 404 錯誤並新增缺少的重新導向
  • 在前一個月每天追蹤自然搜尋效能
  • 從內容編輯蒐集有關新 CMS 的回饋
  • 解決任何漏過 QA 的邊界情況

有機搜尋流量在重大遷移後暫時下降 5-15% 是正常的。如果你的重新導向和 SEO 得到妥善處理，應該在 2-4 週內恢復。如果沒有恢復，說明重新導向對應或內容奇偶性出了問題。

常見延誤及避免方法

經過數十次遷移後，這些是真實的時間表殺手：

構建期間的範圍蔓延：「當我們這樣做時，我們也能新增客戶入口網站嗎？」可以，但那是個別項目。範圍蔓延平均在遷移中增加 3-6 週。

利益相關者可用性：設計審查在某人的收件匣中坐了兩週。相應地預留日曆時間並為反饋輪設定清晰的 SLA。

外掛功能差距：那個神秘的 WordPress 外掛做著沒有人記錄的關鍵事情。探索應該抓住這一點，但有時事情會漏掉。

內容編輯者培訓：如果你的團隊無法使用新 CMS，你就沒有完成遷移。預留 1-2 天進行培訓和文件。

對內容遷移的完美主義：某些內容不值得遷移。2014 年零流量的部落格文章？放手吧。設定重新導向到部落格索引並繼續。

2026 年成本預期

讓我給你誠實的數字。2026 年這項工作的機構費率：

網站規模 時間表 估計成本（機構） 估計成本（自由工作者）
小型 3-6 週 $15,000-$35,000 $8,000-$18,000
中型 8-16 週 $40,000-$90,000 $25,000-$55,000
大型 3-5 個月 $80,000-$200,000 $50,000-$120,000
企業 4-8 個月 $150,000-$500,000+ 很少適合

這些範圍反映了我們在市場上看到的。差異巨大，因為「中型網站」可能意味著完全不同的東西。一個有簡單部落格和聯絡表單的 200 頁網站與有多語言內容、電商和會員門戶的 200 頁網站大不相同。

如果你想討論你的具體情況，我們的定價頁面 概述我們的參與模型，或者你可以 直接聯絡 以取得限定範圍的估計。

常見問題

一個簡單的 WordPress 至 Next.js 遷移需要多長時間？ 一個小型行銷網站（不到 50 頁），具有標準內容類型和最少整合，通常需要 3-6 週，從啟動到啟動。這假設一個 2-3 名開發人員的團隊在沒有重大設計變更的情況下工作。如果你也在進行重新設計，為設計階段再加 2-3 週。

我能否在不損失 SEO 排名的情況下將 WordPress 遷移到 Next.js？ 絕對可以，但需要仔細規劃。關鍵元素是：盡可能保持 URL 結構、為任何變更的 URL 實現 301 重新導向、保留所有中繼標籤和結構化資料，以及確保新網站與舊網站擁有內容奇偶性。有機搜尋流量暫時下降 5-15% 是正常的，應該在 2-4 週內恢復。最大風險因素是錯過重新導向 -- 一個失敗的重新導向對應可能會導致你網站一個部分的流量驟降。

我應該使用 WordPress 作為無頭 CMS 搭配 Next.js，還是完全切換到不同的 CMS？ 這取決於你的團隊。如果你的內容編輯對 WordPress 深感熟悉並抗拒變更，無頭 WordPress 搭配 WPGraphQL 是合理的折衷方案。你獲得 Next.js 前端好處，同時保持熟悉的管理介面。不過，你仍然要承擔 WordPress 的維護負擔（更新、安全補丁、託管）。如果你願意改變，專用無頭 CMS 如 Sanity、Contentful 或 Storyblok 提供更好的結構化內容、即時協作和更少的運營開銷。

CMS 遷移期間最大的風險是什麼？ 首三位是：因不良重新導向對應導致的 SEO 衰退（可修復但成本高），因不充分探索導致的時間表爆炸（通常是因為隱藏複雜性在構建中期浮現），以及編輯者採用失敗（你的團隊拒絕使用新 CMS，因為它太不同或沒有按照他們的工作流程構建）。所有三個都可以透過適當規劃預防。

在 2026 年從 WordPress 遷移到 Next.js 需要多少成本？ 機構成本範圍從小型宣傳網站的 $15,000 到擁有複雜整合的大型企業遷移的 $500,000+。中端市場商業網站的中值大約是專業機構的 $50,000-$90,000。自由工作者費率通常低 40-60%，但伴隨更高的可用性和項目管理風險。成本主要由獨特樣板的數量、整合複雜度和需要手動處理的內容量驅動。

我需要一次遷移所有內容嗎？ 不，實際上分階段遷移常常降低風險。一些團隊首先將行銷頁面移動到 Next.js，同時保持部落格在 WordPress 上，然後在第二階段遷移部落格。你可以使用反向代理規則來提供不同源的不同部分，但在相同網域下。這種方法增加一些架構複雜性，但讓你更快啟動並在全力投入前驗證方法。

重新平台化和重新設計之間的區別是什麼？ 重新平台化將你現有網站的設計和內容移動到新技術（WordPress 至 Next.js），進行最少視覺變更。重新設計改變外觀、感受，以及可能的資訊架構。在一個項目中結合兩者很普遍，但增加 30-50% 的時間表。如果預算或時間緊張，我建議先重新平台化，然後一旦你在新堆疊上後反覆重新設計。

我能否使用 Astro 而不是 Next.js 進行遷移？ 可以，對於內容豐富、互動性最少的網站，Astro 可以是絕佳選擇。Astro 預設不發送 JavaScript，並支援部分水合（「島嶼架構」），這意味著你的內容頁面加載速度難以置信地快。Next.js 在你需要大量客戶端互動、驗證或即時功能時更好。我們已完成對兩個框架的遷移，正確選擇完全取決於你的網站需求。