服務｜Headless CMS 遷移
搬家，不該搬掉你的流量
把 WordPress、Webflow 或老舊 CMS 的內容搬進 Headless 架構，同步核對網址、搜尋排名與結構化資料，降低切換造成的流量風險。
你現在的 CMS
WordPress
文章、媒體庫與自訂欄位
Webflow
CMS collections 與互動
HubSpot CMS
行銷頁與部落格
Drupal／其他
老站台與客製系統
Tenten 遷移工作台
你將得到
Sanity ＋ Next.js 前端
結構化內容與可量測的載入效能
SEO 訊號遷移與核對
301、網站地圖與 JSON-LD 對照
升級的編輯體驗
即時預覽、多語系、可重用區塊
CMS 搬遷後的搜尋流量可能波動。先建立網址、sitemap、結構化資料與搜尋表現基準，才能分辨正常變化和需要處理的遷移缺口。
遷移為什麼會失敗
01
轉址斷裂
舊網址若沒有清楚對應，既有反向連結可能導向 404，搜尋與使用者都找不到原內容。
02
結構化資料遺失
JSON-LD 與 meta 沒有一起搬，搜尋引擎就得重新認識整個網站。
03
Sitemap 退化
新舊 sitemap 交接混亂，會增加搜尋引擎辨識網址變更的難度，收錄變化也更難定位。
04
圖片與 OG 漂移
媒體網址改變或社群預覽失效，會讓既有分享連結出現錯圖、缺圖或內容不符。
遷移是 SEO 工程，不是搬檔案
我們的六階段方法
基準審計
盤點現有網址、流量分佈、結構化資料與排名資產，建立可驗證的遷移基準線。
內容模型設計
把頁面拆成欄位、關聯與可重用區塊的結構化模型，明確區分內容與呈現責任。
網址對照與轉址
建立全站網址清單、目標頁與 301 規則，並用爬取報告追蹤未對應項目。
結構化資料對等
逐頁盤點並重建 JSON-LD、中繼資料與社群分享資訊，再比對遷移前後差異。
灰度上線
透過預備環境驗收、功能旗標與即時回復安排，依實際架構把切換中斷時間降到最低。
30 天監測
在約定期間追蹤索引、搜尋表現與 404，依影響程度分派問題並留下處理紀錄。
從哪裡搬
熟悉 WordPress、Webflow 與 HubSpot 遷移
最常見的來源是 WordPress 與 Webflow。文章、分類、媒體與自訂欄位對應到結構化內容模型，客製外掛的邏輯以 API 或前端功能重現。
搬去哪
預設推薦 Sanity，跑在 Next.js 前端上
Sanity 提供結構化內容、即時協作與可程式化的內容模型；Tenten 自己的網站與內容系統也採用這套架構。企業級授權需求則另評 Contentful 等方案。
編輯體驗
讓編輯團隊接手日常更新
即時預覽、可重用區塊與多語系工作流程，讓內容與呈現分開管理，行銷團隊不必每次都等工程師改頁。
先盤點遷移風險，再確認實作範圍與費用
第一段是遷移審計：盤點資料量與風險，交付轉址對照表樣本、內容模型草案與實作估算。
第二段依審計結果確認工作範圍、相依條件與費用，再執行六階段方法。即使審計後決定不遷移，風險清單仍會交付。
常見問題
可以，但要先盤點文章、分類、媒體庫、自訂欄位與外掛資料能否匯出，再設計目標內容模型。WooCommerce 商店則要另外評估商品、會員、訂單與商務整合。
可能出現波動，無法保證排名或恢復時間。我們會把網址對照、sitemap、結構化資料與 Search Console 監測列為交付範圍，以降低可避免的損失並加快定位。
要看來源系統與增量同步能力。前期可讓新舊系統並行；最終凍結窗口則在遷移演練後確認，並事先安排內容團隊的工作方式。
若網址、索引訊號或內容缺漏，可能造成流量下降、轉址錯誤或編輯中斷，而且沒有固定恢復時間。因此我們先做審計與演練，上線後再依基準線持續監測。
Sanity 提供結構化內容、協作與可程式化內容模型，可用於需要獨立內容層的 Headless 架構；Tenten 自己的網站也使用 Sanity。若有企業級授權或治理需求，仍要比較 Contentful 等方案與當期合約。
時程取決於網址與內容量、資料品質、客製欄位、整合和審核節奏。可先用固定範圍完成遷移審計，再依結果提出實作報價、里程碑與變更機制。
