SHOPLINE 轉 Shopify：常見問題、資料遷移及 SEO 上線完整指南

SHOPLINE 轉 Shopify，表面上似係將產品、客戶同訂單搬去另一個後台，實際上卻牽涉資料結構、會員權益、付款物流、SEO、追蹤系統同日常營運。任何一部分漏咗，都可能出現商品資料錯位、舊客登入唔到、積分對唔上，甚至自然搜尋流量突然下跌。

以下會用香港網店常見情況，拆解遷移前要問嘅問題、各類資料可以點處理，以及由準備、測試到正式切換嘅實務做法。重點唔係「搬得幾快」，而係搬完之後網站可以正常接單、團隊識用，顧客亦唔需要為平台轉換承受不必要嘅麻煩。

點解香港商戶考慮由 SHOPLINE 轉 Shopify

商戶考慮轉平台，通常唔係因為原有網站突然失效，而係業務發展到另一個階段：例如準備拓展海外市場、需要更完整嘅 App 生態、想整合 ERP 或 CRM、要建立較複雜嘅會員與自動化流程，又或者現有 Theme 同功能難以配合下一輪增長。當日常營運開始靠大量人手補救，平台限制造成嘅隱性成本，往往比月費差額更值得關注。

不過，Shopify 並唔會自動令生意增長，亦未必適合每一間公司。轉平台之前，應先將問題寫得具體：係結帳轉化率、跨境銷售、系統整合，定係後台效率出現瓶頸？如果問題其實來自產品定位、廣告成本或內部流程，單純換平台未必能夠解決。尚未確定方向，可以先閱讀 Shopify vs SHOPLINE 比較，再按實際需求計算。

較合理嘅轉平台理由

• 海外與多市場營運：需要按市場管理語言、幣別、網域、定價或商品供應。
• 功能擴充：希望利用更多第三方 App、Shopify Functions 或客製開發建立流程。
• 系統整合：要連接 ERP、WMS、CRM、POS、客服或商業智能系統。
• 品牌與轉化：現有前台設計、內容架構或結帳前流程已限制優化空間。
• 團隊協作：需要更清晰嘅權限、工作流程、報表或多地營運安排。

轉平台唔只係搬 CSV：三條遷移工作線

一個完整嘅 SHOPLINE 轉 Shopify 項目，其實包含三種遷移，而且三者要同步規劃。如果只處理產品 CSV，網站可能「睇落有貨」，但會員權益、營運流程同搜尋流量仍然接唔上。

Shopify 官方嘅 遷移指引亦建議先檢視舊店，再按資料類型選擇手動、CSV、遷移 App、Shopify Partner 或 API。值得留意係，Shopify 現時官方 Store Migration app 列出嘅直接來源並不包括 SHOPLINE，所以實務上通常要先匯出及轉換欄位，或者採用合適嘅第三方工具／客製程式；唔應該假設 SHOPLINE 匯出檔可以原封不動一鍵匯入。

第一步：盤點資料與決定遷移範圍

遷移前先建立一份「資料及功能清單」，記錄資料來源、數量、負責人、目標位置、轉移方法同驗收方式。呢一步雖然唔似設計新 Theme 咁吸引，但往往最能減少後期返工。亦應趁機清走停售多年、重複或品質太差嘅資料，而唔係將舊問題完整複製去新店。

全量搬遷，定只搬營運所需資料？

「全部搬晒」聽落最穩陣，但未必最合乎成本效益。舉例，客服可能只需要最近兩至五年訂單及仍在退換期內嘅交易，而財務歷史則可以保留喺權限受控嘅檔案庫。相反，如果會員級別按終身消費額計算，就算唔搬每一張舊訂單，都要保存可追溯嘅累計數值。決定範圍時，應同時問營運、客服、財務、行銷及合規團隊，而唔係只由網站開發人員判斷。

產品、變體、圖片與庫存點樣搬

SHOPLINE 可以匯出產品資料，但其 Excel 欄位、商品狀態及選項邏輯唔等於 Shopify 嘅產品 CSV 格式。正確做法係先保留一份原始匯出，再建立欄位 mapping 表，將每一欄轉成 Shopify 接受嘅結構。Shopify 亦提供產品 CSV 匯入說明；正式大量匯入前，應以十至二十款具代表性產品試跑。

產品資料最常出錯嘅位置

• Handle／網址識別：重複或包含特殊字元時，要先訂命名規則，亦要配合舊網址轉址。
• 選項與變體：顏色、尺碼、容量等層級未必一樣；組合數量、選項次序及缺貨變體要逐一核對。
• SKU 與條碼：應視為文字處理，避免試算表刪走前置零或以科學記數法改寫長條碼。
• 價格：售價、原價、成本及不同市場價格係不同欄位，唔好用一欄覆蓋所有邏輯。
• 重量與單位：克、公斤及磅轉換錯誤會直接影響運費。
• 分類：SHOPLINE 分類未必等同 Shopify collection；自動 collection 更需要先設條件。
• Metafield：規格、成分、產地、下載檔案等自訂資料，要先建立定義再匯入或由程式寫入。
• 圖片：要檢查主圖排序、變體對應、圖片解析度、替代文字，以及舊圖網址喺切換後會否仍然有效。

SHOPLINE 官方產品匯出及大量更新說明提到，可按全部、篩選結果或所選商品匯出，亦提醒條碼前置零嘅格式問題。呢類細節正正說明：匯出成功只代表拎到資料，唔代表目標平台已經正確理解資料。

庫存應該最後先切

產品主檔可以較早搬，但庫存數量會持續因 SHOPLINE 訂單、退貨、門市及倉庫操作而改變。比較穩妥嘅方法係先喺 Shopify 建好產品、SKU 同庫存地點，測試同步規則；到正式切換前設定短暫變更凍結，匯出最後庫存快照，再匯入 Shopify。若同時接駁 ERP、WMS 或 POS，更要先指定邊個系統係 inventory source of truth，避免兩邊互相覆寫。

客戶資料、帳戶密碼與私隱安排

客戶姓名、電郵、電話、地址、標籤及部分自訂欄位通常可以整理後匯入，但帳戶密碼係例外。Shopify 官方指出，密碼經加密保存，不能經客戶 CSV 遷移；因此「客戶資料搬到」同「客戶可以沿用原密碼登入」係兩回事。

舊客登入要點安排？

實際體驗取決於你採用嘅 Shopify 客戶帳戶類型。使用現行 customer accounts 時，顧客可透過電郵收到一次性六位數驗證碼登入，毋須沿用舊密碼；如使用需要密碼嘅 legacy customer accounts，就要設計帳戶邀請或重設密碼流程。無論採用邊種，都應喺上線前測試新舊客登入、地址顯示、訂單可見性及電郵送達，並預先準備清晰通知，避免顧客誤以為收到釣魚電郵。

Shopify 嘅客戶匯入指引亦說明，客戶 CSV 唔會匯入訂單資料，而來自其他平台嘅 Total Spent 及 Total Orders 亦不能當作 Shopify 原生數值匯入。至於來源資料，SHOPLINE 提供顧客報表匯出，但可用欄位及權限應按商戶現有方案確認。

遷移檔案本身都係個人資料

客戶 CSV、地址及訂單資料唔應該散落喺私人電腦、即時通訊群組或公開雲端連結。項目期間要限制存取人員、使用受控儲存、記錄傳送對象，驗收後按保留政策刪除不再需要嘅臨時檔。香港私隱專員公署說明，個人資料私隱條例下嘅資料保障原則涵蓋準確性、保留期、用途及資料保安；如由供應商處理資料，商戶亦要以合約或其他方式管理相關責任。詳情可參考私隱專員公署條例簡介。

歷史訂單、積分、購物金、禮品卡與評價

呢幾類資料最容易被低估，因為佢哋唔只係「紀錄」，仲可能代表未履行嘅顧客權益或會計負債。Shopify 客戶 CSV 唔會帶入訂單；官方 Store Migration app 亦主要處理產品及客戶，並不等於完整搬入訂單、collection、SEO、網誌、評價及所有整合。需要歷史訂單時，通常要用支援訂單嘅遷移 App、API 或 Partner 方案。

歷史訂單要搬幾多？

先由使用場景反推：客服要查幾耐以前嘅購買紀錄？退換貨期限係幾多日？會員等級會否計終身消費？財務或審計要保留咩欄位？如果只為偶爾查詢，將舊訂單保留於權限受控嘅只讀資料庫，可能比將十年紀錄全部轉成 Shopify 訂單更實際。若決定匯入，應先測試付款／履行狀態、稅額、折扣、退款、顧客對應及訂單編號，並暫停會被「新訂單」觸發嘅通知、積分、ERP 同電郵自動化，免得顧客突然收到多年以前嘅訂單通知。

積分及購物金要先對負債

SHOPLINE 可匯出會員點數及商店購物金報表，但 Shopify 端採用邊個會員 App、store credit 或禮品卡機制，會直接影響可匯入欄位、到期日及兌換方式。應先鎖定目標方案，再做「舊顧客 ID／電郵 → 新客戶 → 餘額」對應；匯入前後分別計算總餘額、有效帳戶數及到期分佈。任何無法一對一重現嘅規則，例如指定商品倍數積分、會員生日延長期或跨門市共用餘額，都要明確決定補償及通知方式。

• SHOPLINE：匯出會員點數報表
• SHOPLINE：匯出商店購物金報表

禮品卡亦要獨立規劃。代碼、餘額、有效期與原發行系統相關，唔應假設普通 CSV 可以無縫搬遷；有時需要喺新店重新發行並通知顧客。商品評價則要先選定 Shopify 評價 App，再按照該 App 格式整理產品識別、評分、內容、日期及圖片。SHOPLINE 本身提供商品評價匯出說明，但能夠匯出並不保證目標 App 接受所有欄位。

頁面、網誌、Theme、App 與系統整合

SHOPLINE Theme 及平台元件不能當作 Shopify Theme 直接匯入。設計上可以延續品牌色、字體、版面節奏及重要互動，但模板結構、Liquid 程式、section、App block 同結帳相關能力要按 Shopify 架構重建。轉平台亦係改善舊網站嘅機會，但唔建議同一時間毫無節制地改品牌、改導航、改文案、改產品結構及改全部流程，否則問題出現時好難判斷原因。

先做功能對照表，再揀 App

唔好用「舊平台有十個模組，所以 Shopify 裝十個 App」作為選型方法。應先列出真正業務要求、每日使用人數、資料輸入與輸出、失敗後果及負責團隊，再判斷用 Shopify 原生功能、Theme、App 定客製整合。相同名稱嘅 App 功能未必相同，而多個 App 同時修改折扣、商品頁或結帳邏輯，更可能互相衝突。

內容頁唔好只複製畫面

關於我們、送貨、退換貨、私隱政策、FAQ、門市資料及網誌都要逐頁盤點。除咗正文，仲要保留頁面標題、Meta Description、圖片替代文字、內部連結、下載檔及發布日期。舊頁若已經有搜尋流量或外部連結，應優先保持內容意圖及建立準確轉址，而唔係搬站時順手刪除。

SEO 核心：URL 對應與 301 轉址

轉平台最常見嘅 SEO 風險唔係 Shopify 本身，而係網址結構改變。Shopify 產品、collection、頁面及網誌會使用平台既定路徑，例如 /products/、/collections/、/pages/ 及 /blogs/。如果 SHOPLINE 舊網址唔同，而又未逐頁做 301，Google 及其他網站累積嘅訊號就可能落到 404 頁。

URL mapping 應該點做

1. 收集舊網址：結合舊 sitemap、網站爬取、Search Console、分析工具、廣告落地頁及外部連結資料。
2. 清理及分級：標記產品、分類、內容、參數頁、語言版本，並按流量、收入及外鏈排優先次序。
3. 建立一對一目標：每個有價值舊 URL 指向內容意圖最接近嘅新 URL；停售商品可導向最相關替代品或分類。
4. 預先匯入 301：正式改 DNS 前將轉址加入 Shopify，並按官方 URL redirect 規則檢查固定路徑及參數限制。
5. 爬取驗收：測試狀態碼、目標內容、redirect chain、loop、404 及內鏈，唔好只抽查幾條首頁連結。

除咗網址，仲要保留咩 SEO 元素？

• 頁面 Title、Meta Description、H1、主要正文及搜尋意圖
• 重要圖片、alt 文字、結構化資料及產品可用性
• 導航、breadcrumbs、collection 與網誌之間嘅內部連結
• 語言／地區版本對應，以及 canonical 設定是否符合預期
• robots 規則、noindex 意圖、404 頁及 Shopify 自動產生嘅 sitemap.xml

如果沿用同一個主網域，通常唔需要使用 Google Change of Address，但仍要向 Search Console 提交新 sitemap，並監察索引、404、排名、自然流量及重要頁面狀態。如果連主網域都更改，就屬於更大規模嘅 site move，應按 Google Search Central 網站遷移指引另行規劃。即使做足準備，上線初期仍可能有短期波動；重點係快速發現錯誤，而唔係承諾排名完全不變。

付款、物流、網域與數據追蹤

資料搬完唔代表可以收錢。付款服務、銀行驗證、退款權限、運費規則、取貨點、稅項、訂單通知及市場設定都要喺 Shopify 重新配置。付款方式唔係由 SHOPLINE 「搬過去」，而係重新申請或連接，再測試授權、扣款、失敗付款、取消與退款。香港商戶亦應實測本地常用付款方式、不同裝置及目標市場，而唔係只用測試模式行一次信用卡。

網域切換前要準備

• 確認域名註冊商帳戶、DNS 權限、續期資料及現有紀錄。
• 記錄切換前 DNS 設定，以便有需要時回退。
• 先喺 Shopify 連接及驗證網域，並預留 DNS 與 TLS 生效時間。
• 檢查電郵相關 MX、SPF、DKIM 等紀錄，改網站指向時唔好誤刪公司電郵設定。
• 舊平台暫時保留後台或只讀存取，唔好一上線就取消帳戶。

Shopify 官方指出，第三方網域連接後仍由原註冊商管理及續期，而網域完全生效可能需要時間；實際 DNS 要按最新官方連接指引設定。避免將網上文章記錄嘅 IP 當成永久值，上線當日應以 Shopify 後台顯示要求為準。

追蹤及銷售渠道要重新驗證

GA4、Google Tag Manager、Meta Pixel、廣告轉化、Google Merchant Center、電郵平台、聯盟追蹤及 consent banner 都要重新安裝及驗證。特別係產品 ID 或 variant ID 改變後，商品 Feed、動態再行銷受眾及舊報表未必可以自然接續。上線前應建立測試訂單，確認 view item、add to cart、begin checkout、purchase、退款等事件冇重複或漏報，亦要為切換日期加註記，方便之後解讀數據。

四種遷移方法點樣揀

冇一種方法適合所有店。好多項目最後都係混合做法：產品及客戶用 CSV，訂單與 metafield 用 App／API，Theme 由開發人員重建，積分則由會員系統供應商處理。

揀工具前，要求做一次 sample migration

無論供應商話支援幾多欄位，都應先揀一批「最難產品、最複雜訂單、不同狀態會員」試搬。要求提供錯誤紀錄、未支援欄位、重跑機制及對數方法，並確認工具會否發送通知、建立真實交易、觸發 App 或更改庫存。工具只係運輸工具，資料正確與否仍然要由商戶驗收。

建議時間表與正式切換流程

以下只係規劃起點，並非固定報價或交付承諾。產品數量唔係唯一因素；多語言、訂閱、POS、會員負債、ERP、客製促銷及審批速度，往往比商品數更影響工期。

建議以階段管理

1. 需求與盤點：定義成功標準、資料範圍、功能差異、風險及責任人。
2. 架構與設計：確定產品模型、collection、導航、Theme、App 及整合方案。
3. 第一次遷移：搬測試資料，修正欄位、編碼、圖片及關聯問題。
4. 建置及整合：完成前台、付款、物流、稅務、通知、會員及外部系統。
5. SEO 準備：完成 URL mapping、301、metadata、內鏈及追蹤設定。
6. UAT 驗收：由營運、客服、行銷、財務及管理人員按真實情境測試。
7. 變更凍結與增量：停止非必要改動，搬最後新增／更新資料及庫存快照。
8. 切換與監察：改網域指向、開放結帳，密集監察訂單、錯誤、SEO 及客服反饋。

點樣減少停機及漏單？

大部分新店建置可以喺獨立 Shopify 網址及受密碼保護環境完成；真正高風險時段係最後庫存、未完成訂單及網域切換。建議選擇相對低流量時段，提前通知內部團隊，設定短暫內容及商品變更凍結，並清楚指定邊一刻開始由 Shopify 接單。若兩個前台同時接受訂單而又冇即時庫存同步，就容易超賣及對錯數。

上線前驗收及對數清單

驗收唔應該只係「逐頁撳下」。每個項目要有預期結果、實際結果、負責人及證據。以下清單可按店舖情況增減：

對數時唔好只比較「產品總數」，因為一件產品可能包含多個變體。最少要分別比較產品、變體、有效 SKU、圖片、客戶、地址、已搬訂單及會員餘額。若範圍本身係部分遷移，亦要將排除條件寫低，避免團隊誤以為數量差異代表漏資料。

常見風險、成本與是否值得轉

轉平台成本除咗 Shopify 月費，仲包括 Theme、App 訂閱、設計與開發、資料清洗、第三方遷移、系統整合、內部培訓、雙平台並行期，以及上線後修正。最容易超支嘅部分通常唔係複製產品，而係「舊功能其實冇人完整寫低」以及「多個系統對同一欄位有不同理解」。

咩情況未必需要即刻轉？

如果現有店舖運作穩定、未有清晰增長需求、內部未有負責人、資料品質極差，或者正值全年最大型推廣期，延後遷移可能更理性。可以先修正商品主檔、整理 URL、記錄流程及驗證 Shopify 原型，等成功標準、預算與資源清楚後再切換。轉平台係一項業務項目，唔係單純 IT 採購。

SHOPLINE 轉 Shopify 常見問題

1. SHOPLINE 可唔可以一鍵直接搬去 Shopify？

現時 Shopify 官方 Store Migration app 所列直接來源未包括 SHOPLINE。產品與客戶多數要先由 SHOPLINE 匯出，再轉換成 Shopify 所需格式；訂單、評價、積分、購物金及其他複雜資料，則可能要第三方工具、API 或 Partner。任何服務聲稱「一鍵完成」，都應先要求 sample migration 及欄位清單。

2. 舊客可唔可以用原本密碼登入？

密碼唔可以經 CSV 搬遷。使用 Shopify 現行 customer accounts 時，顧客可用電郵一次性驗證碼登入；如果使用 legacy accounts，就要安排啟用或重設密碼。上線前應通知顧客，並測試垃圾郵件、電郵延遲及客服處理方式。

3. 歷史訂單一定要全部搬嗎？

唔一定。應按退換貨、客服、會員級別、財務與報表需要決定。可以全量搬、只搬指定年期／狀態，或者保留只讀檔案及將累計值存於其他欄位。最重要係寫清楚新 Shopify 報表由邊日開始代表完整交易。

4. 原有網域可唔可以繼續用？

一般可以，而且沿用相同主網域通常較有利於顧客辨識及降低遷移變數。需要將 DNS 指向 Shopify、完成驗證及確認 TLS，同時保留公司電郵所需紀錄。即使網域相同，內頁路徑仍可能改變，所以 301 mapping 仍然不可少。

5. 做齊 301，SEO 排名係咪一定唔跌？

冇人可以保證排名完全不變。準確 301、保留內容意圖、metadata、內鏈及技術可抓取性，可以大幅降低可避免嘅損失，但搜尋引擎仍需要重新抓取及處理新網址。應預留數星期密切監察，而唔係上線後先等自然恢復。

6. 搬站期間可唔可以兩間店同時營業？

建置與測試階段可以保留舊店營業，新 Shopify 店則保持受控預覽。正式切換時，如果兩邊同時公開接單而庫存、訂單及會員權益冇即時同步，就容易重複扣庫存、漏單或積分不一致。最好定義清楚接單切換時間，並做好最後增量。

7. 轉去 Shopify 之後，原有 App 功能會自動存在嗎？

唔會。兩個平台嘅模組、Theme 與 App 架構不同，需要逐項判斷由 Shopify 原生功能、第三方 App 或客製開發取代。尤其會員、訂閱、贈品、物流標籤、ERP 及 POS，應按完整流程測試，唔可以只比較功能名稱。

8. 幾時最適合正式上線？

通常揀相對低流量、冇大型推廣、團隊可以即時支援嘅時段。要避開購物節、直播、產品首發、盤點及財務結算高峰。上線日期亦要預留 DNS、付款審批、App 審核及最後資料修正嘅緩衝。

總結：點樣降低轉移成本

SHOPLINE 轉 Shopify 最穩陣嘅做法，唔係追求最快將所有資料倒入新後台，而係先確認點解要轉、邊啲資料真係有營運價值，以及搬完後每一個流程由邊個系統負責。將資料、商業邏輯同流量身份三條工作線一齊管理，先可以避免「網站已上線，但生意未接通」。

實務上，先盤點、再做 sample migration；先定目標機制、再搬積分與購物金；先完成 URL mapping、再切網域；先通過跨部門 UAT、再開放正式接單。最後保留舊平台作短期只讀備援，為新店設定清晰監察及回退條件。咁樣做未必係表面上最快，但通常最能減少漏資料、顧客投訴、SEO 損失同上線後返工。