WordPress Multisite 遷移至 Next.js

WordPress Multisite 在 2012 年是個好主意

WordPress Multisite 在 2012 年是有道理的。在 2026 年，你添加的每個子站台都會讓你最終必須進行的遷移變得更加困難。帶前綴的表格會增長。序列化的資料會累積。域名映射外掛會添加另一個依賴項。Multisite 上的每一年都是你在遷移期間需要償還的技術債。

問題不在於你是否會遷移。而在於你什麼時候會遷移。

我們遷移過有 5 個子站台的 Multisite 網絡，也遷移過有 80 多個子站台的網絡。技術模式每次都是一樣的：提取帶前綴的表格、反序列化多年累積的選項資料、將共享使用者映射到現代驗證系統，以及構建一個實際可擴展的多租戶架構。差異是規模，而不是複雜性。

為什麼要離開 WordPress Multisite

Multisite 網絡會累積特定類別的技術債務，隨著時間推移會複利增長。

帶前綴的表格蔓延

每個子站台都會創建自己的表格集合：wp_2_posts、wp_2_postmeta、wp_2_options、wp_3_posts 等等。一個 25 個站台的網絡有 250 多個表格。跨子站台查詢需要對所有表格進行聯合。沒有原生的跨站點搜尋、沒有統一的內容 API、沒有不使用自訂 SQL 的聚合方式。

序列化資料無處不在

WordPress 將複雜資料儲存為 PHP 序列化字符串。ACF 欄位組、小工具配置、站點 URL、外掛設定 — 全部序列化。這些字符串編碼字符串長度（s:23:"https://old-domain.com"），這意味著你不能對 URL 進行簡單的查詢和替換，而不會破壞序列化。每次涉及序列化資料的遷移都需要適當的反序列化、轉換和重新序列化。沒有捷徑。

共享使用者、分散的角色

wp_users 表是全網絡的。一個使用者可以是子站台 2 的管理員、子站台 5 的編輯和子站台 12 的訂閱者。這些角色作為序列化陣列存在於 wp_usermeta 中，鍵值如 wp_2_capabilities。將其提取到合理的驗證模型中意味著解析每個使用者在每個子站台的角色 — 這和聽起來一樣繁瑣。

外掛和更新脆弱性

網絡啟用的外掛同時影響所有子站台。破壞一個子站台的外掛更新會破壞每個子站台的管理員界面。特定站台的外掛會造成版本衝突。共享程式碼庫意味著每項更改都是潛在的全網絡中斷。

大規模性能降低

有 10 多個子站台的 Multisite 網絡相比獨立的 WordPress 安裝的頁面加載速度慢 40-60%。序列化資料解析、共享資料庫連接和外掛開銷都堆積在一起。Lighthouse 移動評分通常在 35-55 之間。不太好。

你會得到什麼：Next.js + Supabase 多租戶架構

目標架構用單一 Next.js 應用程式和 Supabase 後端替換整個 Multisite 網絡，使用行級別安全性進行租戶隔離。

基於路由的多租戶

而不是由 WordPress 管理的子域或子目錄，每個地點都獲得一個乾淨的路由：/locations/[slug]。共享元件（導航欄、頁腳、品牌元素）從單一佈局呈現。特定於位置的內容通過 location_id 從 Supabase 中提取。一個程式碼庫、一個部署、無限的位置。

Supabase RLS 用於資料隔離

行級別安全性原則強制執行位置管理員只能看到自己的資料，而網絡管理員可以看到一切。沒有應用級別的過濾黑客。資料庫本身強制執行存取：

CREATE POLICY "location_isolation" ON posts
  FOR ALL USING (
    auth.uid() IN (
      SELECT user_id FROM user_locations
      WHERE location_id = posts.location_id
    )
  );

這消除了困擾多租戶 WordPress 設定的整個授權錯誤類別。

現代管理儀表板

位置管理員獲得專為目的設計的儀表板：添加位置、編輯每個位置的內容、管理媒體。不再需要點擊 WordPress 的網絡管理員切換器。不再有「超級管理員」與「站台管理員」的混淆。

我們的 7 階段遷移過程

第 1 階段：網絡審計（1-2 週）

我們映射網絡中的每個子站台 — URL 結構、內容量、使用的外掛、自訂貼文類型、自訂欄位、域名映射配置。我們查詢 wp_blogs 以列舉子站台，然後通過 REST API 和直接資料庫查詢爬取每個子站台。

我們識別共享內容（全網絡）與特定站台的內容。共享外掛與特定站台的外掛。子主題、mu-plugins 和具有自訂功能的網絡啟用外掛中的自訂程式碼。

輸出是一份遷移規格文件，其中包含逐個子站台的內容清單。

第 2 階段：架構設計（1 週）

我們設計 Supabase 架構：locations 表、帶有 location_id 外鍵的內容表、每個表的 RLS 原則。我們設計 Next.js 路由結構並將每個舊 URL 映射到其新等價物以進行 301 重定向。

管理儀表板被線框化：位置管理、每位置內容編輯、基於角色的存取。每項決定都在我們寫一行程式碼之前被記錄。

第 3 階段：內容匯出（1-2 週）

這是 Multisite 遷移變得技術性的地方。我們通過兩個管道提取內容：

WP REST API 用於標準內容 — 每個子站台的已驗證請求，在數千篇貼文中處理分頁。

直接資料庫查詢 用於 API 無法呈現的所有內容：存儲在 wp_2_postmeta 中的 ACF 欄位、外掛創建的自訂表格、包含關鍵配置的序列化選項。

序列化資料通過 PHP 的 unserialize() 或 Python 的 phpserialize 庫處理。嵌入在序列化選項（siteurl、home）中的域引用在重新序列化之前被更新。對序列化字符串進行天真的查詢和替換會損壞長度前綴並破壞一切 — 我們見過這種情況出錯，清理它很殘酷。

媒體檔案通過迭代每個子站台的 /wp-content/uploads/sites/[id]/ 被下載。使用者從網絡範圍的 wp_users 表匯出，每個站台的功能從序列化的 wp_usermeta 條目中解析。

輸出：每個子站台的 JSON 和 CSV 檔案，所有內容、使用者和媒體都被列舉。

第 4 階段：構建（2-6 週）

Next.js 應用程式使用基於路由的多租戶成形。Supabase 表被創建，RLS 原則被強制執行。共享佈局元件處理品牌一致性。每個位置的頁面範本呈現本地化內容區域。

管理儀表板支持添加位置、編輯位置內容和查看所有位置的聚合資料。聯繫表單、預訂整合和第三方嵌入被重建或遷移。

時間表取決於複雜性：擁有標準頁面的 5 個子站台網絡需要 2 週。具有自訂預訂系統、會員區域和複雜 ACF 佈局的 40 個子站台網絡需要 6 週。

第 5 階段：內容匯入（1-2 週）

所有內容都使用 location_id 映射批量匯入到 Supabase。每個 wp_2_ 前綴表都映射到位置 ID 2。媒體 URL 從 /uploads/sites/23/image.jpg 被重寫為 Supabase Storage 路徑或新 CDN URL，使用跨所有內容欄位的正規表達式轉換。

WordPress 使用者被映射到 Supabase Auth。密碼雜湊被保留 — bcrypt 重新雜湊在第一次登入時發生，所以使用者不需要重置密碼。

我們通過針對每個子站台抽樣檢查 10% 的內容與原始內容進行驗證。

第 6 階段：重定向映射（1 週）

所有子站台的每個舊 URL 都被映射到其新 URL。對於域名映射的子站台，舊域名重定向到新的 /locations/[slug] 路徑，使用 301。舊子域（site2.example.com）重定向到 /locations/site2。

我們爬取每個舊網站地圖並驗證每個 URL 都存在 301。新網站地圖被提交到 Google Search Console，針對每個先前的域名。

第 7 階段：啟動和監控

DNS 轉換按域名發生。SSL 憑證通過 Vercel 自動佈建。Google Search Console 獲得包含新網站地圖的新域屬性。我們監控 30 天：索引進度、Core Web Vitals 基線、404 追蹤。

舊的 WordPress 資料庫被存檔。在 60 天監控期後確認一切穩定，託管被取消。

SEO 保留策略

Multisite 遷移帶有真正的 SEO 風險 — 你可能同時更改數十個域中的 URL。我們的方法：

• 詳盡的 301 映射 — 每個 URL、每個子站台、每個域名。沒有 404。
• 每個域名的網站地圖提交 — 每個先前的域名都獲得自己提交到 GSC 的網站地圖。
• 標準標籤一致性 — 新頁面從第一天開始就具有適當的標準。
• 內容奇偶性驗證 — 自動化差異確保導入期間沒有內容丟失或截斷。
• 反向連結保留 — 我們審計每個子站台的反向連結，並確保 301 捕獲所有入站連結權重。

客戶通常在 90 天內看到有機流量改善 25-50%，主要來自 Core Web Vitals 收益。

時間表和價格

網絡規模	子站台	時間表	投資
小型	5-10	4-6 週	$15,000 - $30,000
中型	10-25	6-8 週	$30,000 - $60,000
大型	25-50	8-12 週	$60,000 - $100,000
企業	50+	10-16 週	$80,000 - $150,000+

價格取決於序列化資料的量、自訂貼文類型、使用者角色複雜性以及每個子站台的第三方整合。具有大量 ACF 使用或自訂外掛功能的網絡傾向於高端。

每個協議都從免費遷移審計開始。我們映射你的網絡、估算範圍，並在任何工作開始之前給你一份固定價格的提案。