Headless CMS 的 Demo 常展示拖拉頁面、即時預覽和漂亮後台，但正式專案的難題在內容模型、權限、在地化、發布與前端快取。選型應使用品牌自己的文章、活動和商品敘事做 proof of concept，而不是比較功能表勾選數量。
第一步先確認哪些資料屬於 CMS。價格、庫存、variant 和 checkout 應維持 Shopify 交易來源；品牌故事、編輯內容與跨通路素材才進入內容平台。
從內容關係開始
列出 page、article、campaign、author、FAQ、guide、media 和 product reference。確認內容是一對一、一對多或多對多，是否需要排序、反向查詢與跨市場版本。只用一個 page builder document 塞所有區塊，早期很快，日後難以重用和分析。
用三種最複雜的真實頁面建模，再請編輯者完成新增、引用、更新與移除。模型應反映內容語意，不綁死當前視覺欄位名稱。
預覽要測完整路由
編輯者需要從 CMS 打開正確市場和 slug，看到未發布內容、商品 reference 與所有前端元件。測試新頁尚無正式 URL、slug 變更、引用草稿、行動版和權限不足。能預覽單篇文章，不代表能處理整站 routing。
若有 visual editing，還要驗證點擊畫面能否回到正確欄位，以及 draft token 沒有暴露。預覽環境的 cache 和 production 必須隔離。
在地化要選文件或欄位策略
欄位級翻譯方便共用結構，文件級版本則可讓市場有不同段落、slug、發布時間與工作流程。依市場自主程度、fallback 規則、SEO URL 和編輯責任決定。不要用字元轉換代替市場內容，也不能讓缺少語系的公開 URL默默 fallback。
建立一組完整四市場內容，測 sibling navigation、缺頁、引用與媒體。模型在少量欄位上可用，不代表長篇內容也容易管理。
權限和發布流程要符合組織
列出作者、編輯、審核、法務、翻譯和管理員能做的動作。確認是否支援 draft、review、scheduled publish、webhook、版本歷史和回復。平台有工作流程功能，也要看團隊是否有人負責維護規則。
高風險政策頁和一般 campaign 可以有不同核准流程。權限若只能做到全有或全無，可能需要額外治理或不同工具。
API、查詢與效能
用實際前端 query 測試 response、pagination、reference 展開、圖片 pipeline、CDN、webhook 和 rate limits。比較 framework SDK、TypeScript 型別、preview data 和 error handling。大量 nested page builder query 若很難快取，可能增加前端複雜度。
也要估 content migration、schema migration、environment、backup 和 export。API 快只是其中一項，整個發布路徑才是營運成本。
媒體與無障礙不能漏掉
用真實圖片、影片與文件測 asset pipeline：裁切焦點、responsive URL、格式、權利資訊、替代文字、圖說和跨市場版本。若同一資產被多頁引用，替換和下架要能找出所有使用位置。外部 DAM 若是主系統，也要確認 reference、權限和失效行為。
Rich text 與 page builder 應限制語意結構，讓 heading 層級、link text、table 和 media alt 能被治理。後台自由度若讓每位編輯者自行輸入 HTML，前端很難維持 accessibility 和設計一致性。
支援與供應商風險
確認官方 SLA、支援時區、事故通知、status page、資安與資料區域。開源 SDK 很完整，不代表帳號、資料或 billing 問題有人在你的工作時段處理。供應商路線圖只能當參考，關鍵功能要以目前可驗證版本為準。
計算三年與退場成本
將使用者席次、API、頻寬、asset、環境、support、開發與維運一起估算。確認可匯出結構化內容與媒體 reference，避免資料只能以供應商專有格式存在。供應商改價或產品方向變更時，品牌應知道如何搬離。
最後以同一 PoC 評分內容模型、編輯、預覽、在地化、權限、前端、維運和成本。若 Sanity 是候選，可查看 Sanity CMS 服務的技術邊界；無論選哪個系統，都應將決策放回 Headless Shopify 架構驗證。