Shopify 購物流程：從落地頁到結帳與售後

不少 Shopify 網店出問題，不是因為沒有流量，而是訪客進來之後，走不完一條連貫的路。廣告說的是一個賣點，落地頁先講另一件事；購物者找不到合適商品或款式；頁面沒有回答送貨、價格、售後和是否合用；加入購物車之後，結帳又出現新的不確定；付款完成，品牌與顧客的關係也就斷了。

網店購物旅程可以這樣理解：訪客帶着某種流量意圖進站，經過落地頁承接、商品發現、信任建立、加入購物車與結帳，再在購後服務和內容裏回到品牌。這不是單一頁面的轉換技巧，而是 Shopify 模板、主題前端、社交渠道、結帳能力和購後營運，共同組成的一條可維護路徑。

下面的方法按這個次序使用：先統一意圖，再安排頁面資訊；先把商品和市場規則說清楚，再談更複雜的 AI 購物 或 Shopify Plus；最後用購後接觸點和持續維護，把一次交易接成較長期的關係。本文不承諾排名、引用、轉換或收入結果。

1. 先畫出一條完整的購物路徑

不要從「首頁要不要換風格」開始。先把購物者此刻的問題、應該承接的頁面，以及系統界線，寫在同一張表。

這張表既是資訊架構，也是驗收標準。若某個階段沒有點名的用戶問題，後面就很容易用更多模組、更多應用程式和更多動效，去遮蓋結構缺口。

2. 階段一：把流量意圖準確交給落地頁

先建立「來源承諾—第一屏回應」

落地頁的第一件事，不是展示全部內容，而是讓訪客確認自己沒有走錯。搜尋、短影片、創作者內容和廣告，各自帶着不同語境進來。為每類高價值入口保留一張簡短的意圖卡：

• 訪客剛才看到甚麼主題、使用情境或產品承諾；
• 第一屏用哪句標題和哪種視覺回應這個承諾；
• 下一步是單品、比較、指南，還是開始選購；
• 哪些必須出現在第一屏，哪些可以留給商品頁和常見問題。

這是內容和頁面設計的共同工作。社交渠道不應只負責把人送進來，還應持續提供真實提問、評論和異議，幫助團隊更新落地頁的問答和證據。渠道文案、落地頁標題和商品事實需要同一語義。一句只為點擊而寫、落地卻完全不同的句子，是交接失敗，不是流量成果。

SEO、GEO 與落地頁是同一批事實的不同入口

網店 SEO 和 GEO 不應脫離頁面內容和體驗，單獨許諾排名或 AI 引用。較穩妥的做法，是把商品事實、清楚的標題結構、可理解的模組和品牌資訊，做成有人可以維護的頁面資產。標題應說明對象和用途。商品頁應提供可核對的規格、價格和款式。站內路徑應幫助人和系統看見商品關係。

Google 的 ProductGroup 標記，可以讓商品具備在 merchant listing 中展示款式資訊的資格。「具備資格」不是一定會展示，也不是排名或流量提升。Google 商品款式結構化資料說明

3. 階段二：讓購物者更快找到正確商品

商品發現首先是資訊架構問題

找不到商品時，通常不是少了一個按鈕，而是系列、命名、篩選和款式關係沒有被設計出來。可以按這個次序檢查：

1. 首頁是否把主要使用情境或產品類別交代清楚；
2. 系列頁能否按購物者任務瀏覽，而不是按內部組織方式；
3. 搜尋和篩選是否返回人可以理解的結果；
4. 商品頁是否把款式、使用情境、規格和相關內容連起來；
5. 內容頁、社交入口和廣告落地頁，能否回到對應系列或單品。

這是工作建議，不是平台保證。它的價值是把「找到商品」從視覺偏好，變成可以逐項檢查的路徑。

用可維護的 Shopify 主題承載頁面結構

Shopify 主題以 Liquid 作為模板語言，並與 HTML、CSS、JavaScript 和 JSON 一起構成。Shopify 主題架構是設計和開發的事實依據。對大多數 Online Store 頁面，應先把資訊架構做進可維護的主題和前端，而不是把所有互動都做成一次性實作。

若營運團隊需要繼續調整頁面結構，JSON 模板 是重要的交付界線。官方建議在模板使用章節時採用 JSON 模板。JSON 模板保存要渲染的章節及其設定，商家可以在主題編輯器裏增刪和重排。JSON 模板 說明

驗收看「能不能操作」，而不只看「像不像設計稿」：

• 章節 schema 是否定義了 presets，讓營運能在編輯器把模組加入 JSON 模板；
• 現有章節能否按需要重排或移除；
• 評價、活動或倒數等動態內容，是否使用合適的 theme app extension 和 @app block；
• 是否清楚：安裝應用程式後，app block 不會自動出現，仍須在主題編輯器放置和設定；
• 應用程式和腳本疊加後，手機體驗、兼容性和 Core Web Vitals 是否按實際頁面範圍測試。

Theme app extensions 讓應用程式可以在不直接改主題程式碼的情況下，向 Online Store 2.0 主題提供動態元素，降低把主題改壞的風險。這不能推論所有應用程式都不會影響速度。Theme app extensions 與 app blocks 分別說明這兩條界線。

甚麼時候才需要評估 Headless

主題能力足夠時，應先完成主題結構、Liquid 模組和前端互動。只有具體體驗要求確實超出主題時，才評估 React、Vue 或 Headless 店面。Headless 不是預設答案，也不會自動帶來 SEO、GEO 或轉換結果。實作應服務可維護性、效能和營運編輯，而不是成為方案本身。

4. 階段三：用事實和市場規則建立信任

把「放心購買」拆成頁面可以回答的問題

信任不是一張「我們值得信賴」的標籤，而是提前回答購物者會問的問題：商品是甚麼、適合誰、如何選擇、何時發貨、運費怎麼算、能否退換、使用後如何得到支援，以及不同市場看到的價格和可售商品是否一致。

這些答案應出現在需要它們的購買節點。商品頁講規格和是否合用；購物車確認數量和款式；結帳確認地址、送貨和付款；購後頁確認訂單和後續支援。不要把所有說明塞進一條很長的常見問題，再要求購物者自己找。

多市場不是只翻譯語言

在 Shopify Markets 裏，「市場」是商家要用特定購買體驗覆蓋的一組買家，可以按所在地區、零售地點，或代為採購的公司地點匹配。一個買家可能同時匹配多個市場。Shopify 會按匹配市場由最具體到最不具體排序。市場可繼承父市場的自訂設定；結果取決於設定類型：部分子市場設定會覆蓋繼承值，目錄和網店網址設定（web presences）等則可在繼承項目之外疊加。只有匹配市場均未定義相關自訂設定時，才回退到商店預設。Shopify Markets

因此，多市場設計至少要回答四組問題：

• 這個市場能看到哪些商品、目錄和內容；
• 這個市場展示甚麼價格、幣種、稅項或關稅相關資訊；
• 網域、子網域、子目錄和語言路徑如何呈現；
• 訪客進入結帳後，送貨地址或公司地點改變，會否改變市場上下文。

Shopify Markets 可以設定幣種、一個或多個目錄、店面呈現和與稅項／關稅相關的定價行為，也可設定網域或語言、價格、上架商品和主題自訂。Markets API 概覽

幾個細節直接影響信任：

• 被某個市場目錄排除的商品，會在該市場上下文中從店面隱藏、搜尋中省略，並阻止加入購物車。若結帳送貨地址改變，受限商品還可能從購物車移除。
• 國際價應以 Shopify 為該市場載入的價格為準，不要在店面用基礎款式價自行換算。自動換匯不足時，再為市場設定目錄和價目表。
• 展示幣種是購物者在結帳時同意支付的訂單幣種；發卡行仍可能按持卡人的帳戶幣種換匯或收費；即使用本地幣種扣款，也可能另收國際交易費，應向發卡行核實。Shopify 費用說明 商店幣種和結算幣種用途不同，三者不一定相同。
• 國際市場的本地店面可以使用不同網域、子網域或子目錄。應按 Markets 的網域與語言設定確認各版本網址，不能假設每種語言都必須另加子目錄。不要把 /cart 這類購物車路徑當成固定的語言或幣種路徑。

多市場項目的驗收對象不是語言切換，而是整條規則鏈：買家條件、目錄、價格、店面呈現、結帳地址。WESWOO 的 B2B 與多市場工作，主要是公司帳戶、專屬目錄與定價、賬期、草稿訂單、採購門戶，以及按市場設定可售商品、價格和內容。核心公司帳戶、目錄、賬期和自助下單，Basic、Grow、Advanced 和 Plus 都有。仍須逐店確認的是：3 次跨活躍 B2B 市場的活躍目錄分配是否足夠、商店是否使用現行 Markets 體驗、目錄是否必須直接分配給公司或地點、是否需要訂金或部分付款，以及客戶分層、價格體系和 ERP／WMS 如何對應這個模型。後台系統更複雜，本身並不構成必須使用 Plus 的理由。較深的角色、資料來源和發佈治理，見 Shopify Plus 多市場治理；本文只處理購物路徑上的能力界線。品牌內容如何進入可編輯模板及商品欄位，另見 Shopify 品牌系統：主題、模板與商品資料。

5. 階段四：把加入購物車和結帳做成連續動作

加入購物車前後要保持同一套事實

加入購物車按鈕不是路徑終點。點擊前，購物者需要知道選了哪個款式、數量如何影響價格、是否存在市場限制。在購物車裏，需要能檢查商品、數量、價格和送貨條件。到結帳時，頁面應盡量減少需要重新理解的資訊。

用真實任務測試：從社交內容進入某個款式，切換市場或送貨地址，加入購物車，再回到商品頁修改選擇，最後檢查結帳顯示。記錄每一頁實際展示了甚麼，而不只檢查按鈕能否點擊。

結帳能力必須先看方案界線

Shopify 結帳自訂不能寫成「裝個應用程式就能改」。以下界線以 2026 年 9 月 9 日核對的官方說明為準，方案範圍會更新：

• 在結帳的資訊、送貨、付款步驟渲染 Checkout UI extensions，只對 Shopify Plus 商店開放。
• 訂單完成頁 和 訂單狀態頁 頁上的 UI 擴展，對 Shopify Starter 以外的方案開放。
• 相關技術還包括 Checkout UI extensions、購後擴展、以 GraphQL Admin API 改結帳外觀、Shopify Functions 和 web pixel。以 Admin API 改結帳外觀需要 Plus。
• 購後擴展在 Starter 以外仍須申請正式商店存取，目前仍有 beta 界線。不要把它和 訂單完成頁／訂單狀態頁 的 UI 擴展當成同一件事。
• 任何方案都可以使用包含 Functions 的公開 App Store 應用程式。只有 Plus 商店可以使用包含 Shopify Function APIs 的自訂應用程式。部分 Function API 仍屬 Plus 或功能預覽。Functions 可按目標 API、應用程式分發方式及方案資格用於自訂折扣、重新命名或排序付款／送貨選項、按規則阻止繼續結帳，以及處理履約或自取點相關邏輯。這些是平台能力方向，不是轉換率承諾。

請在 checkout app extensions 和 Shopify checkout technologies 核對。仍在使用 checkout.liquid 的商家，需要先遷移到 Shopify Extensions in Checkout，才能使用相應的 Function APIs。

值不值得評估 Plus，取決於必須使用甚麼能力

Basic、Grow、Advanced 和 Plus 均可使用 Shopify B2B。前三種方案在活躍 B2B 市場中合計最多進行 3 次活躍目錄分配；同一活躍目錄分配至兩個活躍市場，計為兩次，Plus 不受此分配次數限制。Advanced 與 Plus 均可透過 Markets 提供情境化店面和結帳體驗，但不等於 Advanced 取得 Plus 核心結帳步驟 UI 擴展資格。Shopify B2B 按方案能力

當需求明確依賴 Plus 專屬的結帳步驟 UI 擴展、結帳外觀自訂，或 Plus 專屬的 B2B 控制——例如把目錄直接分配給公司或地點、訂金、部分付款、按履約發出付款要求——才值得評估 Shopify Plus。當團隊已經確認組織、交易和多市場治理需要更高一層的技術與遷移支援時，也值得評估。公司帳戶、目錄、賬期和自助下單本身不是 Plus 專屬。WESWOO 可協助評估 Plus 升級、遷入 Shopify，以及 Plus 之後的結帳支援。這不是每個網店都必須升級的理由。

若當前主要問題是首頁或商品頁結構混亂、營運無法編輯模組、手機購買路徑不清楚，或 JSON 模板、theme app blocks 和 訂單完成頁／訂單狀態頁 已經覆蓋需要，就不應把 Plus 當成預設解法。Advanced 和 Plus 可按市場建立結帳及帳戶頁覆蓋，但須符合該方案可用設定及擴展目標。在資訊、送貨、付款核心步驟新增符合資格的 Checkout UI 擴展，才涉及 Plus 限制；不能因此把所有按市場的品牌樣式或設定覆蓋都當成 Plus 專屬。實際方案要以商店現行方案和項目需求為準。

AI 購物 和站內 AI 指引，要按資格和事實落地

AI 購物 可以幫助訪客更快理解商品、比較選擇或走向結帳，但不能寫成所有商家都能立刻打開的統一入口。對沒有 Merchant Center UCP integration hub 存取權、採用直接 API 接入的商家，Google 現行概覽要求先加入候補名單，並取得 Google 批准後才能上線；已有 hub 存取權的商家應核對 Merchant Center 對應路徑，不能把直接 API 流程當成所有商家的統一入口。「準備接入」不是「已經可用」。這是 Google 平台內交易接入的要求，不是一般搜尋收錄、AI 摘要展示或網站被引用的前提。Google UCP 概覽

在本文所引 Google UCP 直接 API 接入路徑中，若不實作帳戶連結，商家必須支援訪客購買體驗。UCP 帳戶連結 也意味着項目要提前檢查：在沒有登入的情況下，訪客是否仍能完成必要的商品理解、訂單互動和購買體驗。

商品類型也有界線。本文所引 Google UCP 直接 API 指南對應的原生 checkout，目前不支援訂閱結帳；不應據此推論訂閱不能在其他 AI 購物場景展示或引導訪客回站購買。該原生 checkout 中對應商品的 native_commerce(checkout_eligibility) 應為空或 FALSE。UCP Merchant Center

更新這個欄位時，須一併保留適用的資格旗標：Google 每次上傳會整體覆蓋 native_commerce 屬性組，並非增量修改，省略的旗標會被清空。同時使用原生結帳與購物車轉移時，每次更新須以 native_commerce(checkout_eligibility:cart_eligibility) 組合格式帶齊適用旗標，並覆核兩者結果；不能只改結帳資格，卻意外改變購物車轉移的參與狀態。

在站內做 AI 指引時，較穩妥的是把它當成一層內容互動，而不是替代商品事實。回答應來自當前商品、款式、市場、送貨和售後資訊。不確定時，應引導購物者查看原文或聯絡團隊。上線前，用真實問題核對回答與頁面事實。商店有沒有 UCP 資格、目前審批狀態、商品組合是否合適，必須按項目核實。不要把能力寫得比 Google 現行說明更寬。

假設驗收路徑：由社交單品入口走到訂單狀態

以下假設一家品牌銷售不同容量的水杯，只示範檢查方法，不對應客戶成果。測試使用獲授權的測試環境及付款方式，不為驗證流程擅自建立真實扣款。

1. 從介紹某容量的社交入口進入對應商品頁，記錄入口承諾、預設款式、實際標題和價格；由內容負責人核對頁面是否回答同一需求。
2. 切換容量和目標市場，記錄款式、可售狀態、展示幣種與價格；商品營運確認目錄及欄位，測試人員再檢查實際顯示，不在前端另算一套價格。
3. 加入購物車、修改數量並進入測試結帳，核對選項、價格、送貨地址及市場變更後的結果；不一致就記錄步驟與負責人並暫停該路徑，不能只以按鈕可點擊為通過。
4. 完成獲准的測試訂單後，檢查訂單完成頁、訂單狀態頁和協助入口，由售後負責人確認。AI 回答只引用同一商品及市場的已確認事實；UCP 資格另列帳戶及接入路徑證據，站內測試通過不代表取得 Google 上線批准。

每步保存輸入條件、預期、實際、證據時間與負責人。例子不承諾轉換提升；若只驗證到購物車，就清楚記錄範圍，不把未測試的付款或購後步驟標成通過。

6. 階段五：把購買完成接到購後留存

訂單完成頁 和 訂單狀態頁 仍是購物路徑的一部分

付款完成後，購物者通常關心訂單是否成功、如何查看狀態、需要準備甚麼，以及出問題找誰。訂單完成頁 和 訂單狀態頁 可以承接訂單確認、使用說明、售後入口、常見問題和下一次到訪路徑。內容優先次序應由商品和顧客旅程決定，不應為了增加模組而增加模組。

按現行平台規則，訂單完成頁 和 訂單狀態頁 的 UI 擴展可用於 Basic 及以上。分開的購後擴展表面，另有正式商店存取和 beta 要求。實施前要確認方案、存取權限、應用程式兼容性和目標頁面範圍。應用程式商店的宣傳句子不夠。

留存是內容、服務與主題維護的共同工作

一次交易之後，可以圍繞訂單狀態、商品教育、使用提醒、售後問題和相關內容設計連續接觸點。這些是營運建議，不是再次購買或收入承諾。更重要的是：購後頁面不能在主題更新、市場變化或應用程式升級後失效。

上線後的網店仍需要兼容性維護、主題迭代，以及效能和購買路徑覆盤。WESWOO 把上線後支援當成持續工作，而不是一次交接。數據追蹤、版本變更和活動模組，應保留可追溯的變更紀錄。SEO 和廣告效果仍取決於內容和投放，不應打包成建站結果。WESWOO 服務

7. 用五個階段把方案落地

下面是適合跨境品牌團隊的編號框架。具體次序可按現有網店和業務界線調整。

階段 1：盤點意圖和斷點

列出主要流量來源、入口頁、核心商品和目前的下單路徑。把「流量到了但沒有買」「購物者找不到商品」「在結帳中斷」「買完沒有回流」分別放到六段路徑上。此階段先找問題，不急着換模板。

階段 2：重做資訊架構和落地頁承接

為首頁、系列頁、商品頁、內容頁和購後頁定義角色；確定第一屏回應、商品發現、信任證據和下一步動作。把社交渠道反饋轉成頁面問題清單，並指定事實來源和內容負責人。

階段 3：把結構交付成可編輯主題

以 Online Store 2.0 主題、Liquid、JSON 模板、可重用章節／區塊，以及真正需要的 app blocks 實作頁面。對舊站先判斷能否修復；只有結構、能力或互動確實不適合主題時，才進入 Headless 評估。效能測試必須寫明頁面範圍和測試條件。

階段 4：核對市場、結帳和 AI 資格

逐項確認：商店方案、B2B 需求、Markets 條件、目錄與價格、展示幣種、付款方式、結帳擴展門檻、UCP 接入路徑及相應候補名單／審批、訪客購買體驗，以及商品結帳資格。把每項記為已確認、待申請或不適用，附帳戶狀態或官方依據；只把已確認能力納入上線範圍，未確認項交由負責人補證。

階段 5：上線後以同一批問題閉環迭代

把頁面、應用程式、結帳、訂單狀態和市場變更納入維護清單。持續觀察哪個階段反覆出現同一個購物者問題。先改頁面事實和路徑，再決定是否需要新應用程式或更重的前端。讓數據和顧客反饋回到資訊架構，而不是只做一次視覺改版。

8. P0／P1／P2 實施優先次序

9. 上線前可執行檢查清單

頁面和內容

• 每個主要入口都有對應的第一屏標題和下一步動作。
• 商品頁寫明規格、款式、價格、使用情境、送貨與售後資訊。
• 系列頁、搜尋、篩選和內容連結可以把購物者帶到正確商品。
• 標題結構和商品事實，可由購物者、搜尋系統和內容團隊覆核。
• 社交渠道反覆出現的問題，已進入常見問題或商品說明，並標明證據範圍。

主題和前端

• 關鍵頁面使用可維護的 Liquid、JSON 模板 和可重用章節／區塊。
• 營運需要新增的章節已定義 presets；需要應用程式內容的章節已確認 @app block 條件。
• 應用程式、腳本、動效和手機兼容性按實際頁面測試，而不只看首頁。
• 已判斷舊站是修復、重整，還是確實需要 Headless。

市場、結帳和 AI

• 已確認商店方案、市場資格、目錄、價格來源、展示幣種、網域／語言路徑和付款方式。
• 已確認結帳步驟擴展是否需要 Shopify Plus，訂單完成頁／訂單狀態頁 擴展是否受 Starter 限制。
• 已確認應用程式兼容性、購後擴展的正式商店存取申請，以及任何 beta 或 API 預覽界線。
• 若規劃 Google UCP，已確認直接 API 或 Merchant Center hub 接入路徑及適用要求，包括相應候補名單、Google 批准、訪客購買體驗、商品結帳資格及帳戶連結方案。

購後和維護

• 訂單完成頁 和 訂單狀態頁 提供訂單狀態、協助入口，或與商品相關的下一步內容。
• 主題、應用程式、市場和結帳變更都有回歸測試和具名負責人。
• 已有 數據基線，能區分各階段的進入、離開和重複問題。沒有基線時，不要承諾提升幅度。

10. 常見問題

1. 網店購物旅程和「做一個更好看的首頁」有甚麼分別？

首頁只是入口之一。購物旅程從流量意圖開始，經過落地頁、商品發現、信任、加入購物車、結帳和購後回流；每個階段都要有對應的資訊和動作。視覺改版只有在它改善了這條路徑的理解和操作時，才有意義。

2. 廣告點擊很多但加入購物車很少，應否先換 Shopify 主題？

不一定。先核對廣告或社交內容與第一屏是否在講同一件事，再檢查商品發現、款式選擇和信任資訊。若主題結構還能承載這些修復，應先重整可編輯模組；只有主題能力不足時，才評估更大範圍的重做或 Headless。

3. JSON 模板 能保證轉換率提升嗎？

不能。JSON 模板 已核實的價值，是讓章節及其設定以資料方式保存，並支援在主題編輯器增刪重排。營運要能加入章節，schema 仍需要 presets。它改善的是可維護性和編輯界線，不是轉換結果保證。

4. 甚麼情況下值得考慮 Shopify Plus？

當需求依賴資訊／送貨／付款步驟的 Checkout UI extensions、Plus 的結帳外觀能力、超過 3 次跨活躍 B2B 市場的活躍目錄分配、把目錄直接分配給公司或地點，或訂金、部分付款和按履約請款時，值得進入 Plus 評估。公司帳戶、目錄、賬期和自助下單在較低方案也有，本身不是 Plus 觸發條件。若需要的是頁面結構、主題模組、商品發現，或非 Starter 方案的 訂單完成頁／訂單狀態頁 內容，Plus 不應是預設升級。更複雜的 ERP 或 WMS，本身也不要求 Plus。請核對 Shopify 的 B2B 方案功能。

5. 現在能否直接接入 Google AI 購物／UCP？

不應這樣承諾。沒有 integration hub 存取權的直接 API 路徑，現時要求先加入候補名單並取得 Google 批准後才能上線；已有 Merchant Center hub 存取權則核對對應路徑。直接 API 路徑不實作帳戶連結時，必須支援訪客購買體驗。該指南對應的原生 checkout 目前不支援訂閱結帳，不代表其他 AI 購物展示或回站購買都不可用。資格按接入路徑、項目與商品核實，只把已確認能力納入範圍。

6. 多市場是不是把頁面翻譯成幾種語言就夠了？

不夠。市場還涉及買家條件、目錄、可售商品、價格、展示幣種、稅項／關稅相關定價行為、網域／語言路徑，以及結帳地址變化。只切語言而沒有市場價格、商品和付款規則，不能視為完整本地化。

7. 購後留存應該從哪裏開始？

先把訂單確認、訂單狀態頁、售後入口和商品教育做清楚，再按實際顧客問題安排後續內容。Basic 及以上可以使用 訂單完成頁／訂單狀態頁 UI 擴展。分開來說，購後擴展的正式使用仍須確認存取和 beta 條件。留存建議不是再次購買或收入承諾，必須結合自己的內容和數據基線迭代。

11. 把購物路徑交付成可長期維護的 Shopify 網店

網店購物流程最終要落到頁面、主題和前端交付，而不是停在一份策略報告。WESWOO 對外主體為西西木（深圳）科技有限責任公司，定位是同時處理效能與設計的 Shopify 網店技術團隊；核心工作是頁面設計、資訊架構、主題與前端開發。關於 WESWOO

在具體項目中，WESWOO 先處理品牌視覺、UI／UX、資訊架構和購買路徑，再把它們實作為 Online Store 2.0 主題、可重用章節／區塊，以及 Liquid／JavaScript 前端訂製。主題開發會關注營運能否繼續編輯、應用程式和腳本兼容性、手機適配，以及上線後維護。需要時才評估 React、Vue 或 Headless。服務頁也強調：主題能解決就不先做 Headless；舊站能修就不把所有問題推倒重來。WESWOO Shopify 服務說明

當項目還涉及平台遷移、Plus 升級、B2B 公司帳戶和目錄定價、多市場呈現、付款或 ERP／WMS 協同時，頁面和前端仍應與業務規則一起設計。WESWOO 可承接 Shopify 建站、前端開發、遷移、B2B、多市場、Plus，以及系統接駁和較長期技術支援。具體方案取決於目前網店、方案、市場資格、應用程式和資料界線，不是一套統一套餐。

若團隊正面對「有流量但買不動」「商品難找」「結帳容易中斷」或「買完顧客就失聯」，可以先整理目前入口、主要商品、目標市場、商店方案、結帳自訂需求和 數據基線，再帶着項目背景和目標討論頁面設計、主題開發、遷移或長期維護。聯絡 WESWOO

方案補充：B2B 基礎能力並非 Plus 獨佔。請按現行方案與實際需求逐項核對。