跨境品牌經常把 Shopify 品牌網店，做成一張故事頁加一組視覺稿。代價稍後才出現：定位進不了首頁、系列頁、商品頁和結帳；營運改一句文案都要改程式碼；多開一個市場，就只翻譯首頁。較直接的判斷是：先讓品牌進入購物模板，再用可重用章節、主題設定和商品欄位，把敘事變成營運可以維持的系統。
以一個假設情境為例：團隊花兩星期整理品牌用語，也換過首頁主視覺。購物者仍從廣告進來，落到「全部商品」，篩選只剩價格和顏色。商品頁第一屏是圖片和加入購物車。賣點寫在頁腳「我們的故事」。結帳仍是平台預設。這不是審美沒做好，是品牌資訊沒有進入店面系統。
品牌先進購物模板，故事頁只能當補充
Shopify 主題不是一張大海報。店面按模板組織：首頁是 index，系列頁是 collection，商品頁是 product，購物車是 cart，關於我們、政策和活動說明通常走 page。另外還有搜尋、網誌、404 和密碼頁。購物者幾乎不會按內部品牌手冊的次序逛店。他們從廣告、搜尋、電郵或社交進來，落在某一類模板上。
因此，品牌系統要先問的不是「故事怎麼寫」，而是這類頁面分別要回答甚麼。首頁把人接住，並送到對的系列或商品；系列頁用資料和篩選幫人收窄選擇；商品頁把規格、是否合用、價格和加入購物車一次說清；購物車處理改數量、送貨預期和去結帳。關於我們可以講工藝和來歷。它補不了商品頁缺規格、系列頁不能篩、結帳時政策看不見。
把品牌做成往首頁堆模組，常見結果是視覺很完整，購買路徑仍是主題預設。Shopify 目前允許一個 JSON 模板最多 25 個章節，每個章節最多 50 個區塊，整個主題最多 1,000 個 JSON 模板。這是結構上限，不是必須改 Headless 的訊號。品類需要不同資訊時，較穩妥的是替代模板：維持同一套主題，按品類掛不同的商品頁或系列頁，而不是另做一座站。見 Shopify 的 JSON templates 和 theme limits。
視覺和文案要進營運能改的資產
可持續營運有一個很具體的標準：換季改賣點、上新改規格、換市場改表述時，營運能在後台改，而不必改主題程式碼。
Online Store 2.0 提供章節與區塊、動態來源，以及商品、款式、系列和商店上的 metafields（自訂欄位）。相容的章節及區塊設定可以把後台欄位接到店面；一般主題設定並不直接支援動態來源。支援的欄位類型和連接數量，取決於該設定和上下文；設計主題時應核對 dynamic sources，不要把它寫成一條適用所有介面的數字上限。
類別欄位可以驅動色板，並在 Search & Discovery 已設定時，作為部分篩選條件。前提是主題真的渲染這些欄位。後台建了、前台沒有對應章節、區塊或篩選，購物者仍然看不見。
品牌句寫死在 Liquid 裏，營運改不了；只寫在某個首頁模組的靜態文案裏，商品一更新就會和商品組合脫節。顏色、字體、按鈕、間距同樣應進主題設定，而不是每個模組各寫一套。品牌如果只存在於設計稿，上線後容易在日常改版和多市場營運中失去一致性。
首頁、系列頁、商品頁各管一段
不要用漏斗百分比去想像購物者怎麼走。按頁面該回答的問題檢查，更接近真實逛店。
| 模板 | 該回答的問題 | 資訊主要從哪裏來 |
|---|---|---|
| 首頁 | 這是誰的店、適不適合我、下一步去哪裏 | 商店欄位、精選系列、活動頁、主題設定裏的品牌語 |
| 系列頁 | 有哪些、怎麼收窄、和相鄰品類有何不同 | 系列描述、自動化系列條件、Search & Discovery 篩選、系列欄位 |
| 商品頁 | 這款是否合用、規格是否夠、能不能放心加入購物車 | 商品／款式／類別欄位、媒體、款式選擇器、政策入口 |
| 購物車 | 改數量、看送貨預期、去結帳 | 行項目、推薦、購物車須知。不要把長品牌故事塞進來 |
以護膚為結構示例（不是某家店的成績）：如果「針對敏感肌」只寫在品牌故事裏，系列頁沒有膚質或成分篩選，商品頁第一屏也沒有適用說明，定位就沒有進入購買判斷。
系列頁的工作是用資料和篩選完成選擇，不是再講一遍創辦故事。規格、用法、兼容性和加入購物車，輪到商品頁。精華和套裝、配件和主機，欄位不同、模組次序可以不同，用替代模板處理，主題仍是同一套。
Shopify 的商品模板負責媒體、內容和款式加入購物車路徑，可以接 line item properties、Cart AJAX API 和推薦 API。它不規定品牌模組必須按甚麼次序出現，也不承諾某種排布就更好賣。能維護的是：加入購物車之前，購物者需要的事實是否都在，以及這些事實是不是後台欄位，而不是設計稿上的一段話。
賣點要變成商品事實
內容敘事如果只活在首頁文案裏，SKU 一更新就會過期。能跟着商品組合走的，是商品資料。
先定每個品類需要展示的事實——物料、兼容型號、膚質、功率、認證、包裝規格——做成欄位，而不是每次手寫進富文本。款式用色板或清楚的選項名，避免購物者在縮圖裏猜。
把 Search & Discovery 篩選配在購物者真正用來收窄選擇的欄位上。用支援的自動化系列條件，例如標籤、價格、庫存或合資格欄位，整理商品組合，減少靠人手維護一長串「品牌精選」。設計商品組合前，先核對哪些欄位類型受支援。
營運上的好處是：首頁可以換季節語氣，商品頁和篩選仍指向同一套事實。敘事不再是設計師的段落，而是目錄資料。評價、尺碼表和說明書下載，同樣應接到商品或款式，出現在決策點附近，而不是遠處的頁腳區塊。欄位字典、用語庫和市場差異表屬另一項資料工作，見 商品資料治理：欄位、用語與市場一致性。本文處理的是這些事實如何進入模板和購買路徑。
信任要放在做決定的位置
跨境購物者在商品頁就會問：成分是甚麼、能不能清關、保用怎麼算、運費和稅項誰承擔、這些評價是不是這一款。這些問題往往在加入購物車前後出現，不應只放在品牌故事頁深處。
法定披露、成分表、說明書、合規檔案和評分摘要，適合進欄位，並在商品頁、必要時在購物車可見位置展示。頁腳放政策連結是底線，不是信任設計的全部。評價應對到 SKU 或款式。一條泛商店好評橫幅，幫不了規格決策。
多市場時，信任表述還要對齊該市場能賣的貨、能顯示的價格和稅項。把一個市場的認證說明原樣翻譯到另一個市場，可能構成錯誤承諾。這是內容系統問題，不是翻譯問題。
不要在主題裏硬補結帳品牌
主題管店面。結帳、新版顧客帳戶、棄單電郵和購後狀態頁，是另一套編輯器和擴展界線。把結帳品牌理解成「把主題頁頭搬進去」，後續便容易需要重新調整。
在結帳的資訊、送貨、付款步驟做 Checkout UI 擴展，目前屬於 Shopify Plus。主題的 app block 不會渲染到結帳頁。舊的 checkout.liquid 和舊感謝頁腳本，已被官方結帳擴展路徑取代，不宜再當常規定製入口。Thank you、訂單狀態頁擴展以及 Shopify Functions，另有方案和能力界線。不要按「主題做完就能做結帳品牌」來估。見 Shopify 的 checkout technologies。
新版顧客帳戶獨立於主題，在 checkout and accounts editor 管理。也可以把帳戶放到主網域的子網域，讓登入後的觀感連續。子網域解決的是連續性和識別，不是自動帶來再次購買。棄單挽回走結帳電郵和自動化，口吻可以品牌化，但路徑不在 Liquid 主題裏改。
購後加售不是預設可用模組。若自行開發 post-purchase extension，正式商店目前需要先申請使用權限；兼容性亦取決於應用程式、付款方式、商品類型和市場。訂單之後的品牌關係，更多是訂單狀態頁能講清的履約資訊，以及帳戶裏能找到的訂單與補購入口。
多市場一致性不是翻譯首頁
品牌一旦賣進多個國家或地區，系統界線就不再是「看起來像不像我們」，而是「這個市場能不能下單、看到甚麼價、用甚麼語言、稅怎麼顯示」。
Shopify Markets 按市場設定語言、定價、網址和可售商品。結帳以收貨地址決定最終市場體驗，包括幣種和該市場的自訂。主題上的語言選擇器，不等於結帳已被 Markets 覆蓋。
自動重新導向通常只作用於訪客進入的第一頁，並且會忽略搜尋引擎爬蟲。它幫的是訪客進對市場，不是國際收錄的全部工作。Shopify 在 Markets localisation 說明這兩點。
每個市場應只展示該地區可售商品。首頁主視覺翻譯對了，目錄裏仍掛着不能售出的 SKU，前面的承諾是空的。價格、推廣或稅項顯示若和結帳不一致，敘事會在付款頁被拆掉。多市場要先對齊可售商品組合和價格事實，再談主題差異和語氣。
B2B 也不再是「必須先上 Plus 才能做批發」的舊印象。Shopify 現行對照是：B2B 可用於 Basic、Grow、Advanced 和 Plus。Basic、Grow 和 Advanced 商店需使用新版 Shopify Markets，並在全部 B2B 市場合計最多分配 3 個活躍目錄。Plus 沒有目錄上限，並且可以把目錄直接分配給公司或公司地點。訂金、部分付款和按履約請款仍只在 Plus。把任何一項當成升級理由前，先核對 Shopify 的 B2B 方案功能。方案界線會更新。
批發仍要進入主題和帳戶。營運問題是：誰能看見哪份目錄、甚麼價格、如何下草稿訂單。不是首頁加一個「經銷商入口」。
先做能改的系統，再談升配
品牌系統可以按這條次序自檢，避免跳步：
- 定位寫成每類模板要回答的問題，而不是一篇品牌故事。
- 首頁、系列、商品、購物車和必要的 page 模板分工，品類差異用替代模板。
- 視覺規範進主題設定；賣點、規格、披露進欄位和動態來源。
- 商品資料可篩、可用於自動化系列、能驅動商品頁模組。
- 信任資訊出現在加入購物車和結帳決策點。
- 結帳、顧客帳戶、棄單按官方編輯器和方案界線實施，不以主題程式碼繞過官方限制。
- 再開市場：可售商品、價格、語言、網址、稅項顯示一起對齊。
技術選型看卡住的是哪一層。資訊架構和可維護主題做完之前，不要用 Headless 店面解決文案寫死的問題。較深互動仍可以留在 Liquid 主題裏，用 theme app extensions、Cart AJAX 和適量 JavaScript 完成。這正是 Shopify 網店頁面設計與開發 通常先落地的一層。
Headless 店面可以自選技術棧；Hydrogen 是 Shopify 以 React 為基礎的框架。為該架構設定相應的 storefront channel 和 API 存取。逐項核對每個欄位定義的 Storefront API 權限，只暴露公開店面需要的欄位。把這當成明確的實作工作，而不是離開主題後自動出現。見 Shopify 的 Storefront API metafields。
若單一模板碰到 25 個章節上限，優先拆模板、做替代模板，或用 metaobjects 承載內容頁。不要把這個上限當成必須 Headless 的門檻。
Plus 針對的是另一組界線：結帳資訊、送貨、付款步驟上的 UI 擴展、以 Shopify Functions 建立的自訂應用程式，以及不限數量並可直連公司或地點的 B2B 目錄。包含 Functions 的公開應用程式，較低方案也可以使用。評估 Shopify Plus 升級與遷移 時，應對照實際需要的能力，而不是假設任何複雜項目都需要 Plus。B2B 與多市場 同樣如此。角色、資料來源和發佈節奏屬治理問題，見 Shopify Plus 多市場治理。
WESWOO 的工作，是把品牌視覺、資訊架構和購買路徑做成可維護的 Shopify 主題與前端，並在項目真正需要時，再做 Plus、Headless 或多市場實施。欄位、篩選、替代模板和結帳擴展上線後仍會改，所以交付按可維護來設計，而不是把文案一次性寫進模組。
若你正在做品牌網店，或現有主題把定位留在了關於我們，可以把網店現狀、目標市場和卡點一併說明——是新建、改版、遷移還是長期維護。當你 聯絡 WESWOO 時，帶上項目背景和需要的結果。這已足夠判斷下一步是模板分工和欄位，還是已經碰到結帳與目錄界線。