您的客戶在晚上 9 點發來電郵：「我們能在下個季度新增日語嗎？」您的心沉了下去。Multisite 網路在 12 種語言下已經運行緩慢。WPML 上個月的更新破壞了您的波蘭語版面。共享的 wp_options 表已達 840 MB，您的預發佈環境需要 11 分鐘才能複製。您已經修補了這個架構三次，每次修復都讓下一次語言啟動變得更加困難。我們運行了完全相同的設置 — 91,000+ 頁面、30 種語言、企業級負載 — 並完全放棄了 Multisite 和 WPML。沒有外掛續約。沒有共享表。沒有跨語言混淆。新堆疊的部署速度更快，託管成本低 40%，無需恐懼即可擴展。以下是我們實際部署的架構、遷移過程中的問題，以及使其成功的四個關鍵決定。

我們停止用這種方式做事。今天，我們的生產系統在無 WordPress Multisite、無 WPML、無伴隨兩者的年度授權焦慮的情況下，為 30 種語言提供每個語言環境 118+ 頁面的服務 — 總共超過 91,000 個動態頁面。添加新語言大約需要 45 分鐘，成本約為 $22 的 API 令牌。

本文是完整的分解。架構、工具、成本，以及我們在多個企業項目中完善的遷移路徑。

目錄

為什麼 WordPress Multisite 在規模化時會崩潰

WordPress Multisite 在 2010 年為在單個安裝上運行多個博客而設計。它從未被設計用於真正的多語言企業部署。以下是當您對其推送時會發生的情況：

共享資料庫，共享問題。 Multisite 網路中的每個網站都與同一個 wp_ 資料庫共享前綴表（wp_2_posts、wp_3_posts 等）。跨網站內容共享是脆弱的。一個網站上的外掛更新可能會導致整個網路的級聯故障。我看到過單個格式不正確的遷移指令碼同時造成 12 個語言變體癱瘓。

管理複雜性增加。 每個子網站都有自己的管理儀表盤，但它們並不是真正隔離的。超級管理員看到一切。網站管理員看得太少。沒有乾淨的方式讓德語內容團隊只能訪問他們的內容，除非使用在每次主要 WordPress 更新時都會破損的自定義角色管理。

外掛相容性是個地雷區。 並非每個外掛都相容 Multisite。當您的西班牙語網站需要與 Multisite 不相容的表單外掛時，您只能在功能和穩定性之間進行選擇。將該決定乘以 10+ 種語言。

沒有真實的 API 優先架構。 是的，WP REST API 存在。但它並未被設計用於現代多語言網站所需的那種語言環境感知、邊緣部署、CDN 快取內容交付。您最終會加入層層快取和自定義端點，它們本身會成為維護負擔。

WPML 和 WordPress 多語言外掛的真實成本

讓我們談談數字，因為這是 WordPress 多語言故事變得不舒服的地方。

WPML 授權：$199/年用於多語言機構計劃。這是認真多語言工作的入場券。而且是按網站 — 或在 Multisite 中按網路，聽起來更好，直到您意識到您永遠被鎖定在他們的續約周期。

性能影響：頁面加載速度慢 20-40%。 我已經在多個客戶網站上對此進行了基準測試。WPML 在每個頁面加載時添加資料庫查詢來解析翻譯、切換語言和管理字符串翻譯。在內容豐富的頁面上，這是數十個額外的查詢。您的 LCP 分數會受損。您的用戶會注意到。

翻譯管理成本是真正的殺手。 專業翻譯機構的費用為 $0.10-$0.20 每詞。對於一個擁有 50,000 字內容跨 10 種語言的企業網站：

  • 低估計：50,000 × $0.10 × 10 = $50,000/年
  • 高估計：50,000 × $0.20 × 10 = $100,000/年

這只是初始翻譯。每次內容更新、每個新頁面、每篇博客文章 — 都需要通過翻譯管道進行一次。

有一個更好的方法。

現代架構：Next.js + next-intl + 無頭 CMS

以下是我們已在企業部署中構建和經過戰鬥測試的堆疊：

┌─────────────────────────────────────────────┐
│              邊緣 / CDN 層                    │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Next.js 應用程式                  │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (i18n 路由)       │      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│         無頭 CMS / Supabase                 │
│    ┌──────────┐  ┌──────────────────┐      │
│    │  內容    │  │  翻譯            │      │
│    │  模型    │  │  表 (i18n)       │      │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│        AI 翻譯管道                          │
│    (Claude API → 審核 → 發布)              │
└─────────────────────────────────────────────┘

關鍵洞察：將內容管理與翻譯管理分開呈現。每一層都可以獨立發展。無需接觸翻譯就可以交換 CMS。無需遷移內容就可以更改前端框架。無需接觸代碼就可以添加語言。

next-intl 配置

以下是我們的路由設置在實踐中的外觀：

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: [
    'en', 'es', 'fr', 'de', 'pt', 'it', 'nl', 'sv', 'no', 'da',
    'fi', 'pl', 'cs', 'ro', 'tr', 'ar', 'hi', 'ja', 'ko',
    'zh-CN', 'zh-TW', 'th', 'vi', 'id', 'ms', 'ru', 'uk'
  ],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

// src/middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(de|es|fr|ja|...)/:path*']
};

這為您提供了簡潔的 URL 結構：/en/services、/de/dienstleistungen、/ja/サービス。每個語言環境都獲得自己的靜態生成頁面，從邊緣提供。運行時沒有用於語言解析的資料庫查詢。

Supabase 翻譯表

我們在 Supabase 中存儲翻譯，具有簡單但有效的架構：

CREATE TABLE translations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  namespace TEXT NOT NULL,
  key TEXT NOT NULL,
  locale TEXT NOT NULL,
  value TEXT NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE(namespace, key, locale)
);

CREATE INDEX idx_translations_locale ON translations(locale);
CREATE INDEX idx_translations_namespace ON translations(namespace, locale);

該架構可以輕鬆處理 30 種語言 × 數千個翻譯鍵而不會出現問題。查詢很簡單、可快取且速度快。

設置翻譯管道

翻譯管道是該架構真正發揮作用的地方。以下是我們的工作流程：

  1. 內容用英語編寫在無頭 CMS 中
  2. 構建指令碼提取所有可翻譯的字符串到 JSON 文件中
  3. Claude API 翻譯每個 JSON 文件針對每個目標語言環境
  4. 審核步驟（可選，針對關鍵內容）允許人工編輯者批准翻譯
  5. 翻譯被提交到儲存庫或推送到 Supabase
  6. Next.js 重建通過 ISR 或完整重建受影響的頁面
// scripts/translate.ts
import Anthropic from '@anthropic-ai/sdk';
import { readFileSync, writeFileSync } from 'fs';

const anthropic = new Anthropic();

async function translateFile(sourcePath: string, targetLocale: string) {
  const source = JSON.parse(readFileSync(sourcePath, 'utf-8'));
  
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 4096,
    messages: [{
      role: 'user',
      content: `Translate the following JSON values (not keys) to ${targetLocale}. 
      Maintain the exact JSON structure. Use natural, professional language 
      appropriate for a corporate website. Preserve any HTML tags or 
      interpolation variables like {name}.
      
      ${JSON.stringify(source, null, 2)}`
    }]
  });
  
  const translated = JSON.parse(message.content[0].text);
  writeFileSync(
    sourcePath.replace('/en/', `/${targetLocale}/`),
    JSON.stringify(translated, null, 2)
  );
}

這是簡化版，但它抓住了核心思想。在生產中，我們批量請求、處理速率限制、驗證輸出結構並運行自動化質量檢查。

AI 翻譯：改變一切的經濟學

這是數學變得有趣的地方。

傳統翻譯我們的網站（118+ 頁面，每個語言環境約 50,000 字）：

  • 每個語言環境： $5,000-$10,000（機構費率）
  • 30 種語言環境： $150,000-$300,000
  • 年度更新： $50,000-$100,000

AI 翻譯與 Claude：

  • 每個語言環境： ~$22 API 令牌
  • 每個語言環境的時間： ~45 分鐘
  • 30 種語言環境： ~$660 總計，~22.5 小時
  • 添加新語言環境： 45 分鐘，$22

那不是打字錯誤。每個語言環境二十二美元。

現在，我想在這裡誠實。2026 年的 AI 翻譯並不適合所有用例。法律文件、醫療內容、高度細微的營銷文案 — 這些仍然受益於人工審核。但對於公司網站、產品描述、文檔和博客內容？質量非常好。我們請母語使用者審核我們的 AI 翻譯的日語、阿拉伯語和德語內容，反饋一致認為是「專業質量，偶爾有措辭偏好」。

真正的優勢不僅僅是成本 — 它是速度。當您發布新的英語頁面並希望它在 30 種語言中可用時，您看的是小時，不是週。沒有機構協調。沒有翻譯記憶管理。沒有來回的術語討論。

用於多語言內容的無頭 CMS 選項

您在這裡有選擇，正確的選擇取決於您的團隊和規模。以下是我們評估的內容：

平台 i18n 支持 自託管 定價 (2026) 最適合
Sanity 原生字段級 雲端 + 自託管 免費層，$15+/月專業版 結構化內容、實時協作
Payload CMS 原生，TypeScript 是 免費 / 開源軟體 想要完全控制的開發者團隊
Strapi 外掛型 i18n 是 免費 / 開源軟體 已在 Strapi 生態系中的團隊
Storyblok 原生字段級 僅雲端 $106+/月 視覺編輯、行銷團隊
Supabase（原始） 自訂架構 是 免費層，$25+/月 最大靈活性、開發者密集型團隊

對於我們的無頭 CMS 開發項目，我們通常為內容豐富的網站推薦 Sanity 或 Payload，為想要對翻譯管道完全控制的團隊推薦 直接使用 Supabase。

重要的區別：使用無頭方法，CMS 處理內容存儲和編輯工作流。翻譯管理存在於您的應用程式層。這種分離意味著您永遠不會被鎖定在 CMS 廠商對多語言內容應該如何工作的想法。

逐步：構建 30 語言網站

以下是我們遵循的多語言網站開發的實際過程：

步驟 1：定義您的語言環境策略

在編寫代碼之前，確定：

  • 您實際上需要哪些語言？（檢查您的分析）
  • 您會使用本地化 URL（/de/kontakt）還是子域（de.example.com）？
  • 您需要區域變體（en-US vs en-GB）還是只需要語言代碼？
  • 哪些內容被翻譯，哪些是特定語言環境的？

我們默認使用基於路徑的路由（/de/、/ja/），因為它對 SEO 更簡單，對單個域上的部署更容易，並自然與 Next.js 中間件一起工作。

步驟 2：使用 next-intl 設置 Next.js

安裝並配置：

npm install next-intl

結構化您的消息目錄：

messages/
├── en.json
├── de.json
├── ja.json
├── ar.json
└── ... (30 個語言環境文件)

每個文件都包含命名空間翻譯：

{
  "navigation": {
    "home": "Home",
    "about": "About Us",
    "services": "Services",
    "contact": "Contact"
  },
  "hero": {
    "title": "Enterprise Web Development",
    "subtitle": "Built for performance, designed for scale"
  }
}

步驟 3：構建翻譯管道

創建一個指令碼，其功能：

  1. 讀取您的英語源文件
  2. 將它們發送到 Claude API 進行翻譯
  3. 驗證輸出 JSON 結構
  4. 寫入語言環境文件
  5. 運行自動化質量檢查（缺失的鍵、破損的插補變量）

步驟 4：實施 hreflang 和 SEO

這是許多多語言實施失敗的地方。每個頁面都需要正確的 hreflang 標籤：

// src/components/LocaleHead.tsx
export function LocaleHead({ currentLocale, path }: Props) {
  const locales = routing.locales;
  
  return (
    <>
      {locales.map((locale) => (
        <link
          key={locale}
          rel="alternate"
          hrefLang={locale}
          href={`https://example.com/${locale}${path}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${path}`}
      />
    </>
  );
}

步驟 5：處理 RTL 語言

如果您支持阿拉伯語、希伯來語或其他 RTL 語言（我們支持阿拉伯語），您需要方向 CSS：

// src/app/[locale]/layout.tsx
export default function LocaleLayout({ children, params: { locale } }) {
  const direction = ['ar', 'he', 'fa'].includes(locale) ? 'rtl' : 'ltr';
  
  return (
    <html lang={locale} dir={direction}>
      <body className={direction === 'rtl' ? 'font-arabic' : 'font-sans'}>
        {children}
      </body>
    </html>
  );
}

Tailwind CSS v4 原生支持 rtl: 變體，這使方向造型易於管理。

步驟 6：部署和監控

使用 Vercel 上的 Next.js，每個語言環境的頁面都是靜態生成的，並從離用戶最近的邊緣節點提供。德語用戶訪問 /de/dienstleistungen 會在法蘭克福邊緣節點收到少於 100ms 的響應。沒有資料庫查詢。沒有 WPML 查詢。只是靜態 HTML。

遷移路徑：WordPress 到無頭多語言

如果您目前在 WordPress Multisite 上使用 WPML，以下是我們在多個客戶項目中完善的遷移路徑。您可以在我們的 WordPress 到 Next.js 遷移指南中找到更多詳細信息。

第 1-2 週：內容匯出和審計

  • 通過 WP REST API 匯出所有內容（包括 WPML 翻譯）
  • 將內容類型對應到無頭 CMS 模型
  • 識別孤立翻譯和內容差距
  • 文檔化所有 URL 模式用於 301 重定向

第 2-4 週：無頭 CMS 設置和內容匯入

  • 在您選擇的無頭 CMS 中配置內容模型
  • 匯入英語源內容
  • 設置 Supabase 翻譯表
  • 為所有目標語言環境運行 AI 翻譯管道

第 4-6 週：前端構建

  • 使用 next-intl 構建 Next.js 應用程式
  • 實施所有頁面範本
  • 配置 hreflang 標籤和網站地圖生成
  • 設置新內容的自動化翻譯管道

第 6-8 週：測試、重定向和啟動

  • 跨瀏覽器和跨語言環境測試
  • 從舊 URL 模式實施 301 重定向
  • 將更新的網站地圖提交到 Google Search Console
  • 監控啟動後的索引和流量模式

總時間線：4-8 週取決於內容量和複雜性。我們也處理了遵循類似模式的 TYPO3 到 Next.js 遷移。

成本比較：WordPress Multisite vs. 無頭多語言

以下是 3 年期間 10 種語言企業網站的誠實成本分解：

成本類別 WordPress Multisite + WPML Next.js + 無頭 + AI 翻譯
CMS 授權 (3 年) $0 (WP 免費) $0-$540 (Sanity 專業版) 或 $0 (Payload 開源軟體)
WPML 授權 (3 年) $597 $0
專業翻譯（初始） $50,000-$100,000 $220 (AI，10 個語言環境 × $22)
翻譯更新 (3 年) $30,000-$60,000 $500 (估計 AI 成本)
託管 (3 年) $3,600-$7,200 (託管 WP) $0-$720 (Vercel 免費層至專業版)
開發（初始構建） $30,000-$60,000 $40,000-$70,000
維護 (3 年) $18,000-$36,000 $6,000-$12,000
3 年總成本 $132,197-$263,797 $46,720-$83,460

無頭方法的開發成本在前期稍高 — 您在構建自訂基礎設施而不是配置外掛。但持續的節省是戲劇性的。沒有 WPML 續約。沒有翻譯機構發票。沒有 Multisite 維護煩惱。

對於有興趣探索該方法的組織，請查看我們的多語言公司網站解決方案或聯繫我們以討論您的特定需求。

性能基準

我們在我們的生產多語言網站上運行 Lighthouse 審計，並與等效的 WordPress Multisite + WPML 實施進行比較：

指標 WordPress + WPML Next.js + next-intl
LCP (最大內容繪製) 2.8-4.2s 0.8-1.2s
FID (第一次輸入延遲) 120-280ms 10-40ms
CLS (累積版面移位) 0.12-0.25 0.01-0.05
首字節時間 (TTFB) 800-1,400ms 50-150ms
Lighthouse 性能分數 45-65 95-100
每個語言環境的頁面 ~118 ~118
總索引頁面 ~1,180 (10 種語言) ~91,000+ (30 種語言)

僅 TTFB 差異就值得遷移。當您的頁面是靜態生成的並從邊緣 CDN 提供時，您不是在等待 PHP 啟動 WordPress、加載 WPML、查詢資料庫、解析翻譯和呈現範本。HTML 只是...存在。

對於使用 Astro 構建的網站，由於零 JavaScript（默認）呈現，數字甚至更具侵略性。

常見問題

AI 翻譯對企業網站足夠好嗎？ 對於大多數公司內容 — 是的。在 2026 年，Claude 和 GPT-4 為業務內容、產品描述和文檔生成母語使用者認為專業質量的翻譯。我們已在 30 種語言部署 AI 翻譯，包括日語、阿拉伯語、韓語以及簡體和繁體中文，獲得來自母語使用者審核者的正面反饋。法律、醫療或高度受管制的內容可能仍需人工審核，但即使那樣，AI + 人工審核也遠便宜於純人工翻譯。

向無頭多語言網站添加新語言的成本是多少？ 使用我們的管道，添加新語言大約成本 $22 的 Claude API 令牌，需要約 45 分鐘的工程時間。這涵蓋了翻譯所有頁面內容、導航、元資料和 UI 字符串。與 WPML 的按網站授權加上典型企業網站 $5,000-$10,000 的專業翻譯成本相比。

最佳的 WordPress Multisite 多語言替代品是什麼？ 對於企業部署，與 Next.js 和 next-intl 配對的無頭 CMS（Sanity、Payload 或 Strapi）提供最靈活和高效的架構。您獲得真正的內容/呈現分離、邊緣部署頁面以及獨立於您的 CMS 管理翻譯的能力。對於 50 頁以下的更簡單網站，Webflow 及其本地化功能可以工作，但您會在企業規模時很快遇到限制。

您如何為 30+ 種語言版本處理 SEO？ 每個頁面生成指向所有語言變體加 x-default 標籤的正確 hreflang 標籤。我們生成每個語言環境的 XML 網站地圖並將其提交給 Google Search Console。每個語言環境獲得自己的元標題、描述和 Open Graph 標籤集 — 全部通過 AI 管道翻譯。Google 已索引我們的 30 個語言變體中超過 91,000 頁。

您能在不損失 SEO 排名的情況下從 WordPress Multisite 遷移到無頭嗎？ 是的，但它需要仔細規劃。關鍵步驟是：從舊 URL 到新語言環境前綴 URL 的全面 301 重定向對應、從第一天起適當的 hreflang 實施，以及啟動後立即提交更新的網站地圖。我們通常看到 1-3 週的索引轉換期，然後由於更好的核心網頁生命週期分數而排名改善。我們的 WordPress 到 Next.js 遷移過程專門為此而設計。

2026 年最佳的 WPML 替代品是什麼？ Next.js 應用程式的 next-intl，或 Nuxt 應用程式的 nuxt-i18n。兩者都原生處理語言環境路由、消息格式和 SEO 元資料在框架層 — 沒有 WordPress 外掛的性能開銷。與 WPML 不同，沒有年度授權費、沒有資料庫開銷，沒有其他外掛的相容性問題。i18n 邏輯存在於您的應用程式代碼中，應該在那裡。

您如何在 30 種語言中管理翻譯質量？ 我們使用多層方法：AI 翻譯作為基礎層、自動化質量檢查（JSON 結構驗證、插補變量保留、長度比較），以及針對主頁標題和 CTA 等高可見性內容的可選人工審核。我們也維護每種語言的術語詞彙表，該詞彙表被傳遞給 AI 作為上下文，確保品牌術語、產品名稱和技術詞彙被一致處理。

對於頻繁內容更新的網站，此方法是否可行？ 絕對可行 — 實際上對於頻繁更新比 WPML 更好。當您發布或更新英語頁面時，翻譯管道可以通過 webhook 自動運行。新翻譯在幾分鐘內生成，而不是幾天。使用 Next.js 中的 ISR（增量靜態再生），更新頁面無需完整網站重建即可上線。我們有客戶每天發布博客文章，在一小時內出現 30 種語言，同一天完全被搜索引擎索引。