WooCommerce 搬遷後多語系與多貨幣：locale、hreflang 與價格顯示要核對甚麼
搬遷後，中文頁和英文頁都打得開，不代表語言版本正確；產品頁見到港幣符號，也不代表結帳時真的用港幣收款。多語系和多貨幣是幾層不同設定，任何一層用「看起來正常」代替證據，都可能變成錯價、錯稅或錯語言訂單。
本文集中搬遷後的多語系／多貨幣驗收，不重複換主機後的 DNS、TLS、付款回呼、電郵與快取基礎檢查。那篇處理「新主機是否真的接手、單是否入到正確系統」；本篇只補上語言版本、hreflang、canonical、貨幣顯示、結帳幣值與稅務這幾層。也不重複staging 隔離與更新後功能回歸的完整清單，只在最後列出多語系／多貨幣測試要怎樣隔離。
介面語言、搜尋語言標籤、交易貨幣不是同一件事。 locale 影響介面語言；hreflang 和 canonical 影響搜尋如何理解語言版本；貨幣、稅、結帳與訂單則是交易層。三層可以互相影響，但沒有一層可以代替另一層。
一、locale 是介面語言，不是貨幣或 hreflang
WordPress 的 Site Language 是後台／網站介面語言設定；官方文件把它描述為 WordPress dashboard language [7]。它不會自動把產品內容、分類、文章或主題字串翻譯成另一種語言。前台內容翻譯要靠主題、翻譯檔或多語系外掛；WooCommerce 本身是 translation-ready，但仍要有所選語言的翻譯檔，未翻譯的字串可能保持原文 [9]。
WordPress locale 的寫法常見 pt_BR、en_GB 這種「語言_地區」底線格式 [8]；hreflang 則用 pt-BR、en-GB 這種連字號標籤 [1]。兩者相似，但不是同一個字串。不要直接把 WordPress locale 貼進 hreflang 就當完成，也不要見 locale 有國家碼就推斷貨幣。
搬遷後最常見的問題不是翻譯文字本身，而是語言切換後仍然去舊域名、舊路徑，或者只回到首頁。Google 建議不同語言版本使用不同 URL，而不是單靠 cookie 或瀏覽器設定動態改語言 [3]。如果搬遷後只有一個 URL 靠 cookie 轉語言，搜尋引擎和快取都可能只見到其中一個版本；這不是加幾行 hreflang 就可以補救。
| 層 | 你要回答的問題 | 不是甚麼 |
|---|---|---|
| locale／介面語言 | 這個 URL 的前台和後台語言是甚麼？翻譯檔存在嗎？ | 不是貨幣，也不是 hreflang |
| hreflang／canonical | 這個語言版本和哪個版本互指？搜尋應顯示哪個版本？ | 不是轉址，也不是貨幣切換器 |
| 貨幣／稅／結帳 | 客人看到、被收取、訂單記錄和稅務用哪個幣值？ | 不是由 locale 自動決定 |
二、hreflang：語言／地區標籤，不是貨幣或 redirect 指令
hreflang 用來告訴 Google「這些 URL 是同一個內容的語言或地區版本」；Google 明確表示，它不會用 hreflang 或 HTML lang 屬性偵測頁面語言，而是用演算法判斷 [1]。hreflang 是配對訊號，不是自動翻譯、不是貨幣指令，也不是叫瀏覽器轉址的指令。
1. 有效語言標籤：語言必要，地區可選
Google 文件要求 hreflang 使用語言碼（ISO 639-1），可選地區碼（ISO 3166-1 Alpha 2）；只寫地區而不寫語言不合法 [1]。例如 en、en-GB、de-ES 可以；單獨一個 HK 不可以。x-default 是選用的後備版本，用來接住沒有明確匹配語言／地區的訪客 [1]。
hreflang 也可以帶 ISO 15924 script subtag，例如 zh-Hant（繁體中文）、zh-Hans（簡體中文）。zh-Hant-HK 是語言 zh + script Hant + 地區 HK，不是 WordPress 的 zh_HK locale；不要只把底線換成連字號，就假設兩者語義相同。
2. 每一版都要列出自己，也要互相指回
Google 的規則很清楚：每個語言版本都要列出自己以及所有其他版本；HTML <link> 要放在 <head>，URL 要用完整絕對網址；如果 X 指向 Y，Y 也要指回 X，否則註解可能被忽略或解讀錯誤 [1]。self entry 不是錯誤，而是必要條件。
以下只是格式示例，不是本站實際語言簇：
<link rel="alternate" hreflang="zh-Hant-HK" href="https://example.com/zh-hk/page/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
三個版本都要有同一組 links，包括自己。搬遷後如果只改了其中一頁的域名，或者只把舊域名 search-replace 了資料庫、但外掛在輸出時仍用舊設定，就會出現單邊鏈、舊域名或缺失 self entry。
3. 同一語言不同貨幣：不要重複用同一個 hreflang
貨幣不是語言，也不是地區碼。不要因為同一頁有 HKD、USD、GBP 三個價格版本，就為三個 URL 重複加上同一個 hreflang="en"。 一個 hreflang 值應該對應一個語言／地區版本；重複值會令語言簇混亂。
如果貨幣版本只是同一個語言頁的 session／query 狀態，通常不應把每個貨幣 URL 都塞進 hreflang 語言簇。應先決定哪個是主要可索引語言頁，貨幣切換是否要產生獨立 URL，以及那些 URL 的 canonical／indexability 怎樣處理。不要用 hreflang 當貨幣切換器。
4. hreflang 不保證索引，也不能掩蓋 canonical 問題
hreflang 只描述替代版本。頁面仍然要回 200、可被抓取、沒有 noindex，canonical 也要指向同一語言的正確版本。一個 noindex 頁不會因為加了 hreflang 就變成可索引；把 noindex 的購物車或結帳頁放進語言簇，只會令驗證更混亂。
搬遷後要檢查的是實際 rendered HTML 和 sitemap，不是只看資料庫。特別留意：
- hreflang、canonical、og:url 仍然指舊域名；
- 只有單邊 hreflang，沒有 return link；
- 語言碼寫錯，或把 WordPress locale 的底線格式直接貼進 hreflang；
- 用相對 URL，或同一頁的 links 不一致；
- canonical 跨語言，造成互相矛盾的語言訊號；
- 自動 redirect 按瀏覽器語言跳走，令其他版本難以被看到。
三、canonical 與 indexability：同一語言，不要把全部語言併成一個
Google 對 canonical 的建議是：如果頁面有 hreflang，canonical 應指向同一語言的頁面，或同一語言不存在時最接近的替代語言 [2]。canonical 是強訊號，不是強制命令；如果英文版 canonical 指向中文版，會造成互相矛盾的語言訊號，Google 可能忽略這個 canonical 或選擇其他版本，不能當成可靠的「合併」方法。
最簡單、也最容易核對的做法，是每個語言版本 self-canonical；如果同一語言內有追蹤參數、結尾斜線、www／非 www 等重複 URL，才把該語言的重複版本指向同語言的首選 URL。不要把「所有語言指向預設語言」當成統一權重的方法。
indexability 要逐頁核對：
- HTTP 200，沒有意外的 redirect chain；
robotsmeta 或X-Robots-Tag不是 noindex；- canonical 是同一語言、絕對 HTTPS URL；
- hreflang 的每個目標都存在、回 200、可索引；
- sitemap 包含正確語言 URL，沒有舊域名；
- 購物車、結帳、我的帳戶等交易頁按網站政策 noindex，且不被當成 SEO 語言版本。
搬遷後亦要留意 trailing slash、大小寫、語言前綴和參數。如果 canonical、redirect、sitemap 和內部連結互相矛盾，搜尋引擎會自行選一個，結果未必是你想要的版本。
四、貨幣：顯示換算、結帳收取與商戶結算要分清
WooCommerce 核心每個商店只設一個 base currency，用它顯示產品價格和記錄新訂單；要顯示或收取其他貨幣，需要 multi-currency 外掛／擴充 [4]。官方文件亦明確說，Currency Converter Widget 只改變價格顯示，不代表結帳會用該貨幣收款 [4]。
顯示幣可以和結帳幣不同，但這只是顯示層與交易層可以分開；不是說結帳、訂單或實際收款出現任何幣值差異都正常。搬遷後要分開核對四個層次：
- 產品頁和分類頁顯示甚麼幣？換算價怎樣來？
- 購物車和結帳頁向客人確認甚麼幣、應付總額多少？
- 訂單記錄和付款網關實際收取甚麼幣、多少錢？
- 商戶結算、退款、發票、訂單電郵和報表用甚麼幣？
客人確認結帳後，結帳頁、訂單記錄和付款網關實際收取的幣別與金額必須對得上。 如果網關按自己的換算、手續費或路由規則令金額不同，差異要能由網關紀錄和設定解釋；沒有解釋的幣別或金額落差，應視為錯幣／錯額並暫停，不能當作正常。商戶結算幣是另一個層次：網關可能以商戶結算幣入帳，這不代表客戶支付幣或訂單幣可以任意不同；客戶實付與商戶入帳要分開核對。
WPML 的 multicurrency 文件示範可按貨幣顯示不同付款方式：例如預設 Stripe 帳戶處理美元，地區 Stripe 帳戶或本地網關處理另一貨幣 [11]。這是付款方式路由，不代表結帳、訂單和網關實際收取可以出現無解釋的幣別或金額差異；路由後仍要核對客戶實付與商戶結算。
1. 四捨五入、分隔符和小數位要一起測
貨幣格式不只是一個符號。小數位、千位分隔符、小數分隔符、符號位置、固定價格與自動換算，都會影響顯示和總額。測試不要只用 100 這種整數：
0.01、0.005、9.99、99.99、100、1,000；- 零小數位貨幣（例如 JPY）如果你有服務日本市場；
- 固定價格與按匯率換算混合的產品；
- 優惠券的固定金額折扣、免運門檻和混合購物車；
- 稅前／稅後顯示不同時的總額。
WooCommerce 的貨幣設定包括幣別、符號位置、千位分隔符、小數分隔符和小數位數 [5]。如果搬遷後只改了幣別，沒有改分隔符或小數位，客人可能見到格式正確但數值難讀的價格。
2. 匯率不是搬遷設定，而是營運資料
多貨幣外掛通常有匯率來源、更新頻率、手動覆寫和換算費用。搬遷後要確認匯率沒有停留在舊環境、舊快取或測試值；亦要記錄你用的是哪個來源、多久更新一次、由誰覆核。不要假設「外掛會自動更新」就等於價格正確。
3. 改 base currency 不會換算舊訂單
WooCommerce 官方文件說得很清楚：改變 base currency 會改變商店顯示和收取的貨幣，但不會替你換算任何金額；產品價格數字會保持不變（原本 10 會顯示 10，不是自動換算），舊訂單亦保留原本的貨幣、符號和總額 [4]。搬遷後如果要改 base currency，必須手動更新產品價格，並核對舊訂單沒有被改寫。
五、稅與結帳：稅是獨立層，會令顯示價和總額不同
稅務設定和貨幣是兩個獨立層。WooCommerce 的稅務設定包括：價格是否含稅、按哪個地址計算稅（客戶送貨地址、帳單地址或商店地址）、購物車和結帳顯示含稅或未稅、運費稅類，以及不同稅類 [6]。搬遷後商店地址如果仍是舊地址，稅率可能整體錯位。
官方文件提醒，如果「價格輸入方式」、「商店顯示」和「購物車／結帳顯示」三個含稅／未稅設定不一致，可能出現差一仙的 rounding 差異或混亂 [6]。所以不要只測產品頁；要由產品頁、購物車、結帳、訂單到付款網關逐段對同一筆金額。
稅務與貨幣是兩層；多貨幣外掛可能影響稅基、換算與顯示，實際行為取決於外掛、稅務設定和付款網關。不要假設「幣別換了，稅會自動等比例換算」；要用實際地址、稅類和外掛設定測試。
1. 稅務測試要包含地址與身份
退稅、增值稅、GST、銷售稅的規則因地區而異；本文不是稅務建議，也不判斷你是否應該在某地收稅。測試要覆蓋：
- 訪客與已登入客戶；
- 送貨地址與帳單地址不同；
- 商店基準地址 vs 客戶地址；
- 含稅價與未稅價；
- 標準稅類、減稅類、零稅率與運費稅；
- 免運門檻、優惠券和混合購物車。
2. 結帳幣別和語言可以中途改變
如果客人在購物車中途切換語言或貨幣，購物車內容可能被重新定價、保留，或要求確認重置；這取決於多語系／多貨幣外掛的設定 [11]。搬遷後要實測「已在購物車有商品」時切換語言、切換貨幣、由訪客登入、套用優惠券，然後再入結帳。不要只在 empty cart 的狀態測。
六、搬遷後測試矩陣（示例）
六步核對
- 01 · 清單語言 × 貨幣 × 市場
列出每個要開賣的組合，不要只列語言。
- 02 · hreflangself + return links
每版列出自己與所有版本；完整 URL、有效語言碼。
- 03 · canonical同語言 + 可索引
canonical 不跨語言；200、index、sitemap 一致。
- 04 · 價格顯示幣別 + 格式 + 四捨五入
核對符號、分隔符、小數位、固定價與換算價。
- 05 · 結帳與稅顯示幣不等於收款幣
核對購物車、稅額、網關金額與訂單幣值。
- 06 · staging 隔離無真付款／真電郵
測試 key、郵件 sink、獨立快取與排程。
通過：每個關鍵組合都有證據。阻擋：錯幣、錯稅、單邊 hreflang、canonical 跨語言、測試電郵外洩。未確認 ≠ 通過。
下載完整 SVG 流程圖下表是組合示例，不是你的商店定價或稅務建議。實際測試應按你的市場、語言、貨幣、付款網關和稅務設定裁剪，但至少每個準備開賣的語言×貨幣×目的地要有一條完整路徑。
| 語言 | 貨幣 | 目的地 | 客戶 | 稅顯示 | 要核對 |
|---|---|---|---|---|---|
| zh-Hant-HK | HKD | 香港 | 訪客 | 含稅 | 產品價、運費、結帳總額、訂單幣值 |
| en | USD | 美國 | 訪客 | 未稅 | 稅是否按地址加入、網關是否收 USD |
| en | GBP | 英國 | 已登入 | 含稅 | 會員價、稅、訂單電郵語言 |
| zh-Hans-CN | CNY | 中國內地 | 訪客 | 含稅 | 語言切換、貨幣符號、付款方式 |
| ja | JPY | 日本 | 訪客 | 含稅 | 零小數位、四捨五入、網關金額 |
| 同一語言 | 第二貨幣 | 同一目的地 | 已登入 | 含稅 | 切換貨幣後購物車是否重算、優惠券是否仍有效 |
每一條路徑要留同一組證據：URL、HTTP 狀態、HTML lang、hreflang 組、canonical、robots、產品價、購物車總額、結帳總額、訂單 ID、訂單幣值、付款網關測試 ID、稅項明細、電郵記錄和截圖。只有「見到價格」不算完成。
高風險邊界
- 訪客 vs 已登入：同一貨幣但不同稅／運費；
- 語言切換後購物車重置或重新定價；
- 貨幣切換後優惠券由固定金額變成另一個幣值；
- 免運門檻在換算後剛好跨過或未跨過；
- 付款網關不支援某貨幣時，是否隱藏、退回 base currency 或顯示錯誤；
- 退款、部分退款、訂單電郵和發票的幣值與語言；
- 舊訂單在搬遷後是否保留原幣值和原語言記錄。
七、安全 staging 隔離：不要在正式站試真付款或真電郵
WooCommerce 官方測試訂單文件提醒：測試訂單沒有特殊狀態，看起來可以和正式訂單一樣，亦可能觸發訂單電郵和進入分析；其他外掛或服務未必分得清測試與正式訂單。官方要求測試付款與結帳應在 staging 進行，完成後刪除測試訂單 [10]。
搬遷後的多語系／多貨幣測試，起碼要做到：
- 獨立環境：staging 用獨立域名或子域名、獨立資料庫和獨立 uploads；不要連正式資料庫。
- 封鎖索引：staging 用 basic auth 和 noindex，不要讓搜尋引擎收錄。要驗 production 的 hreflang，應在受控 preview 或直接 parse rendered HTML，不要把 staging 開放給 Google。
- 測試付款：只用付款網關的 test mode／sandbox key；不要用 live key，也不要輸入真實信用卡。
- 封鎖電郵：停用或導入郵件 sink；不要寄給真實客戶，亦要留意 SMTP 外掛可能繞過「停用電郵」設定。
- 切斷對外整合：webhook、CRM、ERP、物流和 analytics 指向測試端點或停用，避免測試單進入正式流程。
- 獨立快取與排程：staging 用獨立 cache／CDN；逐一列出 cron、Action Scheduler、訂閱續期和其他會接觸正式資料或外部端點的工作，將它們停用、改指向測試端點或隔離。保留測試所需的購物車、訂單、稅務、電郵 sink 與會話工作，否則你測不到完整路徑；不要用一個 blanket 停用清單代替檢查。
- 測試商品與庫存：用獨立 SKU 或複製商品，避免測試單扣正式庫存。
- 清理與記錄：測試後刪除 staging 訂單，保留測試證據；不要把測試訂單匯入正式站。
如果 staging 是正式站的完整 clone，search-replace 後仍要檢查序列化資料、外掛設定、授權 domain、快取和付款回呼。不要用一個模糊的萬用 redirect 或「先上線再算」來跳過隔離。
相關閱讀：WordPress 網站遷移、促銷開賣前營運演練與更多網誌文章。
八、Go／No-Go：未確認不等於通過
| 狀態 | 條件 | 行動 |
|---|---|---|
| 通過 | 每個關鍵語言×貨幣路徑的 hreflang、canonical、indexability、顯示價、結帳價、訂單幣值、稅額、網關金額和電郵語言都有證據 | 可按既定範圍上線 |
| 待確認 | 只影響非關鍵語言、次要貨幣或格式，交易金額與稅務未受影響 | 暫緩受影響市場／貨幣，補測後再決定 |
| 阻擋 | 錯幣收款、錯稅、結帳退回未經批准的 base currency、hreflang 單邊／舊域名、canonical 指向另一語言、測試電郵寄給真實客戶 | 暫停受影響範圍，修正後重測 |
未確認不等於通過。若關鍵項未確認，應由店主或獲授權人員決定暫停哪個語言、貨幣或結帳範圍；不要自行刪除舊站、舊 DNS、舊訂單或測試證據。
九、常見問題
hreflang 可以當貨幣切換器嗎？
不可以。hreflang 只描述語言／地區替代版本，不會改變價格、貨幣或結帳幣值。貨幣切換要靠多貨幣外掛、session、cookie 或你設計的 URL 狀態，並要另外測試。
每個語言版本一定要列出自己嗎？
要。Google 要求每個語言版本列出自己以及所有其他版本；self entry 是必要條件，不是重複錯誤。缺少 return link 亦可能令註解被忽略。
Canonical 可以指向另一個語言嗎？
不建議。Canonical 應指向同一語言版本，或同一語言不存在時最接近的替代語言。跨語言 canonical 會造成矛盾訊號；Google 可能忽略它或選擇其他版本，不能保證合併或保留哪個版本。
WordPress Site Language 會自動翻譯前台內容嗎？
不會。Site Language 是 WordPress 介面／dashboard 語言；前台內容翻譯要靠主題、翻譯檔或多語系外掛。WooCommerce 也要有對應語言的翻譯檔。
WooCommerce 核心支援多貨幣嗎？
核心每個商店只有一個 base currency；要顯示或收取其他貨幣，需要 multi-currency 外掛或擴充。有些工具只改顯示，有些可以改變結帳幣值，行為要看外掛。
顯示幣和結帳幣可以不同嗎？
可以，但只限於顯示層與交易層的分工：只改顯示的換算器可令產品頁顯示幣與結帳幣不同。客人確認結帳後，結帳頁、訂單記錄和網關實際收取的幣別與金額必須互相對得上；網關的換算、手續費或稅項差異要有紀錄解釋，不能把無解釋的差額當正常。商戶結算幣是另一個層次，可能與客戶支付幣不同，應分開核對。
改 base currency 會自動換算舊訂單嗎？
不會。WooCommerce 官方文件說，改 base currency 不會替你換算金額；產品價格數字保持不變，舊訂單保留原本貨幣、符號和總額。要自己更新價格並核對舊訂單。
搬遷後 hreflang 最常見的錯誤是甚麼？
舊域名未清、缺少 self entry 或 return link、語言碼格式錯、canonical 指向另一語言、把 noindex 頁放進語言簇，以及只用 cookie／redirect 而沒有獨立 URL。
資料來源
Google Search Central — Tell Google about localized versions of your page
Google Search Central — Managing multi-regional and multilingual sites
搬遷後，先把語言與交易層分開核對
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正處理搬遷後的多語系、多貨幣、稅務與 WooCommerce 結帳設定，需要按實際站點、外掛、付款網關和稅務設定整理驗收清單，可先確認支援邊界。
聯絡 Managed-WP.™ PRO若你需要按實際 WooCommerce 語言、貨幣、稅務與付款流程整理搬遷後測試紀錄，可聯絡 Managed-WP.™ PRO。
編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理。標示為實務建議的內容不是 WooCommerce、付款網關、多語系／多貨幣外掛或稅務處理的功能保證；版本、介面、外掛與供應商行為可能變更，請以實際環境及最新官方文件為準。本文不是稅務建議，也沒有指示在正式站建立測試訂單、寄出真實電郵、使用 live 付款金鑰或把 staging 開放給搜尋引擎。