多語系網站架設:子目錄、子網域與 hreflang 設定

老闆開完會,丟下一句:「我們的官網要做英文、日文、西班牙文、德文,最好再加個阿拉伯文。」業務點頭,設計師開始找多語系外掛,工程師問了一句沒有人答得出來的問題:「網址要怎麼排?是 en.公司.com,還是 公司.com/en/?」三個月後網站上線,英文版還算完整,日文版只有首頁,德文版的產品頁有一半還是英文,阿拉伯文版的選單整排擠在錯的那一側。

這個場景在台灣外銷製造業並不少見。問題通常不在翻譯品質,而在更前面的架構決策:要做幾個語言、網址怎麼安排、搜尋引擎怎麼知道哪一頁是哪一頁的翻譯版、訪客怎麼切換語言。這些決定一旦做錯,事後要改的成本,往往比當初多做一個語言還要高。

這篇文章只談架構。多語系內容要怎麼用 AI 半自動產出、怎麼排定每週的產出節奏,我們在外銷製造業 AI 多語系 SEO Playbook已經寫過,這裡不重複;如果你還在更早的階段,連網站要不要重做都還沒決定,可以先看外銷網站從零到上線的完整指南。本文所有關於 Google 的說法,都以 Google Search Central 的官方文件為準,出處直接放在每一段裡,讓你可以自己查證。

先給一個背景數字,說明為什麼這件事對台灣廠商特別重要。依財政部統計處的〈114 年我國出進口貿易概況〉,2025 年台灣對美國出口達 1,983 億美元,占總出口的 30.9%,是近 35 年來最高,美國也重新成為台灣最大的出口市場。同一份報告也提醒,這波成長主要由資通與視聽產品、電子零組件帶動,塑橡膠、基本金屬製品等傳產貨類仍普遍面臨產能過剩與低價搶單的壓力。換句話說,對傳產外銷廠來說,北美市場的份量變重了,競爭卻沒有變輕鬆——一個讓美國採購看得懂、找得到的英文網站,是這場競爭的入場券,而不是加分題。

一、要做幾個語言?從買家名單倒推,不是從野心往外推

直接回答:語系數量應該由「現有與目標買家實際用什麼語言做採購決策」來決定,而不是由「我們想賣到多少國家」來決定。每多一個語系,產品頁、規格表、常見問題、認證文件、價格說明都要多維護一份;維護不動的語系,不如不做。

很多老闆把語系數量當成國際化程度的象徵,好像語言越多,公司看起來就越大。但網站上的每一個語言版本,都是一份需要長期照顧的資產。以我們公開的H 製造商四語系官網重建案例為例,118 個產品乘上四個語系,就是 472 個產品頁,加上分類頁之後全站約 660 頁。從此以後,每新增一個型號、每修改一次規格,都是乘以四的工作量。這不是勸你不要做多語系,而是提醒你:語系數量是一個乘數,它會放大你往後所有的內容維護成本。

北美市場:英文是基本盤,西班牙文看通路

如果你的主力市場在北美,英文版是必要條件,而且英文能涵蓋的範圍比很多人想像的大。美國人口普查局依 2018 至 2022 年美國社區調查發布的統計指出,全美 5 歲以上人口有 78.3% 在家只說英文;在家說其他語言的 18 至 64 歲人口中,61.0% 說西班牙文,而這群說西班牙文的人當中,有 58.3% 表示自己英文說得「非常好」。對 B2B 採購來說,這代表一個好的英文版足以涵蓋大多數美國買家;要不要加西班牙文,取決於你的通路——例如你的經銷商主要服務西語系的終端客戶,或者你同時想經營墨西哥與中南美洲市場。

加拿大的情況不一樣。魁北克的法律教育機構 Éducaloi 說明,如果企業在魁北克有地址,並且向魁北克人提供產品或服務,就必須有法文版網站。多數台灣工廠在當地沒有據點,這條規定未必直接適用於你;但如果你的魁北克經銷商要轉用你的產品資料,法文資料的需求很快就會浮現。這類涉及當地法規的判斷,請以當地律師的意見為準。

看數據而不是看感覺:三個判斷來源

判斷要不要多做一個語言,可以看三個來源。第一是詢價紀錄:過去兩年的詢價信、展會名片、阿里巴巴國際站詢盤,買家用什麼語言寫信、來自哪些國家。第二是 Google Search Console 與 GA4 的國家與語言分布:哪些國家的訪客已經在看你的英文版,停留時間與詢價轉換的表現如何。第三是業務團隊的實際溝通能力:網站做了日文版,買家用日文寫信來詢價,公司裡有沒有人能用日文回覆?如果沒有,日文版帶來的反而是一次令人失望的接觸。

語言偏好確實存在。翻譯與在地化研究機構 CSA Research 在 2020 年調查了 29 個國家、8,709 位線上消費者,發現 76% 偏好購買有母語資訊的產品,40% 表示從不在其他語言的網站上購買。但要注意,這是消費者調查,不是 B2B 採購調查;工業品買家通常具備專業英文閱讀能力,而且採購決策由多人參與。這個數字適合用來提醒「語言會影響信任」,不適合拿來當作「每個市場都要做母語版」的依據。

語系決策表

下面這張表整理了幾種常見情境與我們的建議。它不是公式,而是讓你在內部開會時有一個共同的起點。

破除一個常見迷思:很多人以為「語言越多,搜尋流量就越多」。微軟 Bing 團隊的 Fabrice Canel 在 2020 年就曾公開建議,不要只為了標上不同語言市場而複製網址,並直言「少即是多」。內容單薄、翻譯不完整的語系頁,不會替你帶來流量,只會稀釋網站品質,也消耗負責維護的人的精力。

組織面:誰負責每一個語系?

多語系網站最常見的衰敗方式,不是技術出問題,而是沒有人負責。上線那天每個語系都很完整,半年後中文版新增了十個產品,英文版補了五個,西班牙文版一個都沒補。建議在決定語系數量的同時,就把「每個語系的內容負責人」與「新增產品時的翻譯流程」寫進內部作業規範:新產品上架前,各語系版本要同時到位,或者明確標示哪些語系暫不上架。這個規範比任何外掛都更能決定你的多語系網站能活多久。

什麼情況下,你暫時不需要多語系

如果你的海外訂單幾乎全部透過貿易商或代理商,而且買家很少直接上你的官網,那麼先把一個英文版做完整,比同時做五個語言重要得多。如果你的網站連英文版都還停留在五年前的型錄,先處理英文;等詢價紀錄顯示某個非英語市場確實在成長,再加第二個外語。這個順序能讓你用最少的成本,驗證每一個語系的價值。

二、網址結構三選一:子目錄、子網域、國碼網域怎麼選

直接回答:Google 官方文件把子目錄(example.com/de/)、子網域(de.example.com)、國碼網域(example.de)列為三種可行做法,各有優缺點,並沒有說哪一種排名一定比較好;唯一明確標示「不建議」的,是用網址參數(?loc=de)區分語系。對多數中小製造商來說,子目錄的維護成本最低。

Google Search Central 的〈Managing multi-regional and multilingual sites〉用一張表比較了這幾種網址結構。我們把官方列出的優缺點照實整理成下表,並補上三個中小企業最在意的維運面向。為了避免誤導,「Google 官方」兩列是照文件整理;「維運觀察」幾列是我們的實務經驗,不是 Google 的評分。

破除迷思:子目錄不是 Google 給的「加分」

網路上常看到「子目錄一定比子網域好」「子網域會被當成另一個網站、權重從零開始」這類說法。請注意,Google 的官方文件並沒有這樣寫,它只是列出各自的優缺點。我們之所以建議多數中小製造商用子目錄,理由是維運面的:一套系統、一個網域、一份報表,人手有限的團隊比較管得動;而不是因為 Google 會替子目錄加分。如果你已經用子網域經營多年、索引與詢價都穩定,沒有必要為了這個說法重做網址結構。

Google 怎麼判斷一個頁面要給哪個國家的人看

同一份官方文件列出了 Google 判斷目標地區的訊號:國碼網域是「強烈訊號」;hreflang 標註,不論寫在標籤、HTTP 標頭或網站地圖;伺服器位置,但因為很多網站使用內容傳遞網路,所以「不是決定性訊號」;以及頁面上的當地地址與電話、當地語言與貨幣、其他在地網站的連結等其他訊號。文件也明說,Google 會忽略 geo.position 這類地理位置標籤。

還有一個很多人不知道的變化:Search Console 過去有一個「國際指定目標」報表,可以替整個網站指定目標國家。Google 已經停用這個報表,理由是這種國家指定功能被認定對整體生態「價值不高」,但 hreflang 仍持續支援;依 Search Engine Roundtable 的報導,停用是在 2022 年宣布的。實務上的意思是:如果你用子目錄或子網域,後台已經沒有開關可以「告訴 Google 這個目錄是給美國的」,你能做的,是把 hreflang 與頁面內容做對。

台灣廠商特有的問題:英文站放在 .com.tw 底下

很多台灣工廠的官網網域是 .com.tw,英文版就直接放在同一個網域下。依 Google 的說法,國碼網域對使用者與搜尋引擎都是「這個網站是給特定國家看的」強烈訊號,而 .tw 並不在 Google 視為通用網域的例外清單裡——那張清單包括 .io、.co、.ai、.me、.tv 等國碼網域,Google 會把它們當成通用網域處理,因為使用者普遍把它們看成通用網域。所以當你的主要買家在北美,英文頁放在 .com.tw 底下,等於送出一個跟目標市場不一致的地區訊號。

這不代表 .com.tw 的英文頁在美國一定排不上去,語言、內容品質、外部連結都還在起作用;也不代表你應該馬上換網域。換網域是一次完整的網站搬遷,每一個舊網址都要做 301 轉址並逐筆驗證,否則過去累積的搜尋權重會流失——這部分的判斷,可以參考網站改版還是打掉重做的決策框架。我們的建議是:如果你正要重建網站,而且外銷佔營收大宗,值得把「主站改用 .com、中文版放在 /zh/」納入評估;如果網站運作正常、英文版也有穩定的詢價,就不必為了這一個訊號大動干戈。

另外兩種做法:網址參數與 Cookie

有些網站用網址參數切換語言,例如 ?lang=en;也有網站乾脆在同一個網址上,依照 Cookie 或瀏覽器設定顯示不同語言。Google 對這兩種做法都不建議:官方表格把網址參數標為「不建議」;文件也寫明,Google 建議每個語言版本使用不同的網址,而不是用 Cookie 或瀏覽器設定來調整頁面語言。原因很單純:同一個網址只會被索引成一個版本,其他語言對搜尋引擎來說等於不存在。有些翻譯外掛是在同一個網址上即時切換文字,選用前一定要確認它會不會替每個語言產生獨立網址。

網址裡的文字要不要翻譯

另一個常被問的細節是網址本身的文字。Google 表示,在網址中使用在地化的文字是可以的,但要使用 UTF-8 編碼,並在連結時正確跳脫。實務上,中文網址在分享時常被轉成一長串百分比編碼,貼到電子郵件或通訊軟體裡很難閱讀。我們通常建議各語系共用同一組英文代稱,例如 /zh/products/valve-a 與 /en/products/valve-a,方便團隊比對與維護;若是西班牙文或德文這類拉丁字母語言,想用當地語言的代稱也沒有問題,重點是一旦決定就不要再改。

子網域與國碼網域的管理成本,從 Search Console 就看得出來

一個具體的差異:Search Console 的「網域資源」可以涵蓋同一個網域底下的所有子網域與通訊協定,但頂級網域是資源名稱的一部分,所以 example.com 的網域資源不會包含 example.org。換句話說,子目錄與子網域可以在同一個資源底下看數據,國碼網域則每一個都要另外驗證、另外看報表。對只有一兩個人管網站的中小企業,這是實實在在的日常負擔。

三、hreflang 怎麼設:用途、x-default 與雙向互指

直接回答:hreflang 是用來告訴 Google「這幾個網址是同一份內容的不同語言或地區版本」的標註。每一個語言版本都必須列出自己與所有其他版本,而且必須雙向互指,否則標註可能被忽略;另外建議加上 x-default,作為語言不符時的預設頁。

hreflang 能做什麼、不能做什麼

依 Google 官方文件〈Tell Google about localized versions of your page〉,hreflang 的作用是讓 Google 理解這些頁面是同一份內容的在地化版本,進而在搜尋結果中把使用者導向最適合的語言或地區版本。但它有兩個常被誤解的地方。

第一,hreflang 不是用來判斷頁面語言的。Google 明說,它不會用 hreflang 或 HTML 的 lang 屬性來偵測頁面語言,而是用演算法判斷;另一份文件說得更具體:Google 依據頁面上看得到的內容判斷語言,不使用 lang 屬性或網址這類程式碼層級的語言資訊。所以,如果你的英文頁有一半內容還是中文,hreflang 標得再正確,也無法讓它成為一個好的英文頁。官方建議每一頁的內容與導覽都使用單一語言,避免中英對照並排。

第二,翻譯過的頁面不算重複內容。Google 在同一份文件中寫道,在地化版本只有在主要內容沒有翻譯時,才會被視為重複。很多人擔心中英文版會被當成重複內容「互相打架」,這個擔心對真正翻譯過的頁面並不成立;真正需要擔心的,是只翻了選單與頁尾、正文仍是同一種語言的頁面。

三種設定方式,擇一即可

Google 支援三種方式宣告語言版本:HTML 的 link 標籤、HTTP 標頭、XML 網站地圖。官方說明這三種方式對 Google 來說是等價的,同時使用三種在搜尋上沒有額外好處,反而更難管理。一般網頁用 HTML 標籤或網站地圖都可以;HTTP 標頭則適合 PDF 這類非 HTML 檔案——對製造業來說這一點很實用,因為你的英文規格書、中文型錄往往就是 PDF。

以一個有繁體中文與美國英文兩個版本的產品頁為例,兩個版本的 head 裡都要放入完全相同的一組標籤:

<link rel="alternate" hreflang="zh-TW" href="https://www.example.com/zh/products/valve-a" />
<link rel="alternate" hreflang="en-US" href="https://www.example.com/en/products/valve-a" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/products/valve-a" />

以本站為例,happycxo.com 每一頁都宣告 zh-TW、en-US 與 x-default 三組 hreflang,網站地圖裡也放了同樣的對應。官方說擇一即可,我們選擇讓網站地圖同步,是因為這樣方便用程式稽核。

設定規則:七條一次看懂

以下規則都來自 Google 官方文件:

1. 每一個語言版本都必須列出自己,以及所有其他語言版本。
2. 替代網址必須是完整網址,包含 https://,不能只寫 /en/page。
3. 替代網址不需要在同一個網域,所以國碼網域之間也能互指。
4. 如果兩個頁面沒有互相指向對方,這組標註會被忽略——這是為了防止其他網站任意宣稱自己是你的某個語言版本。
5. 語言代碼使用 ISO 639-1,地區代碼使用 ISO 3166-1 Alpha 2;不能只寫國家代碼。
6. 不在標準裡的代碼不支援,官方特別點名常被用來表示拉丁美洲西班牙文的 es-419;保留給其他用途的代碼,例如 EU、UN、UK,會被忽略,英國要寫 GB。
7. 繁體中文可以寫 zh-TW,Google 會從地區推導出繁體字;也可以用 zh-Hant 明確指定書寫系統。

官方文件還提到一個對中小企業很友善的彈性:如果要替每個語言維持完整的雙向連結很困難,可以在某些頁面省略部分語言,Google 仍會處理互相指向的那幾組;但新加入的語言版本,一定要和原本最主要的語言版本雙向互指。對產品很多、新語系只先翻譯核心頁的製造商來說,這代表你可以逐步擴充,而不必一次把所有頁面翻完。

x-default:給「語言對不上」的訪客一個落點

x-default 是一個保留值,用在訪客的瀏覽器語言設定與你所有語言版本都不符合的時候。Google 說明,x-default 可以用在任何頁面,但它原本是為語言選擇頁設計的,用在那裡效果最好。對中小製造商,常見做法有兩種:如果首頁是語言選擇頁,x-default 就指向它;如果沒有語言選擇頁,就指向你最主要的外銷語言版本,通常是英文。

常見錯誤對照表

hreflang 的設定看起來簡單,實際上很容易出錯。Ahrefs 研究了 374,756 個網域的 hreflang 設定,發現 67% 的 hreflang 實作有問題。下表整理了 Google 官方文件點名的錯誤,以及我們在網站健檢中常遇到的情況。

表中 canonical 那一列需要特別說明。Google 的重複網址整併文件寫明,如果你使用 hreflang,canonical 要指定同一種語言的頁面,沒有同語言版本時,才用最接近的替代語言。有些外掛或範本預設把所有語言的 canonical 都指向主語言,這等於請 Google 把你的翻譯頁合併到主語言頁裡。

如果你想先確認現有網站有沒有這些問題,可以對照我們整理的中小企業網站 9 個常見技術問題自我檢查。

四、不要依 IP 自動轉址:語言切換器怎麼設計

直接回答:Google 官方建議避免依照你猜測的使用者語言,把訪客自動從一個語言版本轉到另一個語言版本,也建議不要用 IP 位置分析來調整內容。正確做法是每個語言版本各有固定網址,並在每一頁放上清楚的語言切換連結,讓使用者自己選。

為什麼自動轉址會讓你的網站「消失一半」

Google 在多語系文件中寫得很直接:避免自動把使用者從一個語言版本轉到另一個語言版本,因為這類轉址可能讓使用者與搜尋引擎無法看到網站的所有版本;同一份文件也說,不要用 IP 分析來調整內容,因為 IP 位置分析很困難,而且通常不可靠。

背後的技術原因是爬蟲的位置。Google 說明,對於會依訪客所在地或語言回傳不同內容的網站,Googlebot 預設的 IP 位址看起來位於美國,而且爬蟲送出請求時不會設定 Accept-Language 標頭,所以 Google 可能無法替不同地區爬取、索引所有內容。雖然 Google 也會從美國以外的 IP 爬取,但如果你的網站把「美國 IP」一律轉到英文版,Googlebot 大多數時候就只看得到英文版,中文版可能很少被看見。Google 在這份文件中的建議很明確:使用分開的語言網址,並用 hreflang 標註。

對台灣外銷廠還有一個很實際的情境:美國採購人員出差到台灣看廠,在飯店用手機打開你的網站,如果你依 IP 把他轉到中文版,他得自己找切換按鈕;如果切換按鈕做得不明顯,他很可能就直接關掉了。IP 只能告訴你對方「在哪裡」,不能告訴你對方「讀什麼語言」。

網際網路標準組織的觀點:協商可以,但一定要能改

全球資訊網協會(W3C)國際化工作組的看法稍有不同。它認為依瀏覽器的語言偏好(Accept-Language)引導讀者到偏好的語言版本通常是有幫助的,但也強調每一頁都要加上語言連結,讓使用者能輕鬆切換,並且記住使用者的選擇。把 Google 與 W3C 的說法放在一起,可以得到一個兩邊都能接受的做法:不做強制轉址;如果真的想依瀏覽器語言給提示,改成在頁面上方顯示一條「看起來你偏好英文,要切換嗎?」的提示列,讓使用者自己決定。

語言切換器的六個設計原則

1. 用語言名稱,不要用國旗。 W3C 的說法是,國旗代表國家,不代表語言:很多國家說同一種語言,也有很多國家有不只一種官方語言。英文不是只屬於美國,西班牙文也不是只屬於西班牙。
2. 每個語言用它自己的寫法:English、繁體中文、Español、العربية,而不是全部用中文寫成「英文、西班牙文」。
3. 切換後停在對應的同一頁,而不是被丟回首頁。一個正在看某支閥門規格的買家,切換語言後應該看到同一支閥門。
4. 如果對應頁不存在,就導到最接近的上層頁,例如同一個分類頁,並清楚告知,不要導到 404。
5. 位置固定:頁首右上角與頁尾各放一個,每一頁都一樣。
6. 記住選擇,但不要覆蓋網址:可以用 Cookie 記住使用者上次選的語言作為提示,但每個語言版本的網址本身必須固定,這樣分享出去的連結才會開出同一個語言。

五、翻譯不等於在地化:北美買家要的是換算好的規格

直接回答:把中文頁翻成英文只是第一步。北美買家要看的是用他熟悉的單位、標準、認證名稱與論述順序寫成的頁面:公制與英制並列、標明符合哪一個標準、分清楚北美與歐盟的認證、日期寫成不會誤讀的格式,並且把規格與應用放在公司沿革前面。

單位:美國不強制使用公制,所以兩套都要給

美國國家標準暨技術研究院(NIST)說明,美國並不強制公制化,所以很多企業同時使用國際單位制與美國慣用單位,而同時使用兩套單位經常造成換算錯誤。對規格頁的意義很直接:如果你的產品規格只寫毫米、公斤、bar,美國工程師就要自己換算成英寸、磅、psi;每換算一次,就多一次出錯的機會,也多一個「這家供應商不懂我們」的印象。建議做法是公制與英制並列,並在規格表中明確標示哪一個是設計基準值、哪一個是換算值,換算的小數位數也要由工程部門決定,不要交給翻譯人員。

標準與認證:不要把 CE 當成北美通行證

認證名稱是翻譯最容易「字翻對了、事講錯了」的地方。歐盟執委會說明,CE 標示是製造商替要進入歐洲經濟區單一市場的產品完成符合性評估後加貼的標示——它是歐洲的規則。在美國,職場使用的電氣設備則涉及美國職業安全衛生署(OSHA)的國家認可測試實驗室計畫,由獲得認可的民間實驗室,依其認可範圍內的標準進行產品驗證,並使用各自註冊的驗證標章。

所以英文版不能只把中文頁上的「通過 CE 認證」翻成英文就結束。你要問的是:我的產品在北美需要哪些認證?我實際拿到了哪些?網站上寫的每一個認證,都要有證書編號或可以查詢的資料,絕對不要寫你沒有的認證。同樣的邏輯也適用於材料與測試標準:如果你的產品是依 JIS、CNS 或 DIN 製造,英文版要寫清楚依據的是哪一個標準,不要讓買家自己猜是否等同於 ASTM 或 ASME 的對應規格;是否等同,要由你的工程部門確認後才能寫上去。

日期、貨幣與文件格式

W3C 指出,月/日/年的日期格式是美國特有的,加拿大有時也會使用,而歐洲多數地區用的是日/月/年。「03/04/26」在美國讀者眼中是三月四日,在歐洲讀者眼中是四月三日。交期、報價有效期限、文件版本日期這類資訊,建議改用國際標準的 2026-04-03 寫法,或直接寫出月份名稱。貨幣也一樣,如果頁面上有價格或運費說明,就標明幣別與貿易條件,不要只寫一個數字。

論述順序:北美買家先看規格,再看沿革

這一點沒有官方數據,是我們協助外銷廠商改寫網站時反覆看到的現象。很多台灣廠商的中文官網,首頁第一段是「本公司創立於某年,秉持誠信、品質、服務的精神……」,英文版就照著翻。但北美採購打開產品頁,最先想知道的通常是:這個東西能不能用在我的應用上、規格與公差是多少、材料是什麼、最小訂購量與交期多久、有哪些認證。公司沿革是信任訊號,但它應該放在「關於我們」,而不是擋在規格前面。北美買家重視哪些信任訊號,可以延伸閱讀北美買家信任訊號指南;產品頁要怎麼寫才讓 AI 搜尋也讀得懂,可以看產品頁 AEO 指南。

翻譯與在地化對照表

最後一列的詢價表單,是在地化最常被遺漏的地方。表單欄位要怎麼設計才不會嚇跑海外買家,我們在B2B 詢價表單設計有完整的拆解。

至於機器翻譯:它可以是很好的初稿工具,但上線前必須由懂產業的人校稿。多語系內容要怎麼用 AI 產出、怎麼安排人工把關的節點,請回到AI 多語系 SEO Playbook,這裡不再重複。

六、阿拉伯文等右至左語言:版面要從第一天就支援

直接回答:阿拉伯文是從右往左書寫的語言,整個頁面的版面方向都要跟著鏡像翻轉:選單、麵包屑、表格欄位順序、表單輸入位置都會改變。這件事必須在網站架構與樣式設計階段就處理,不是裝一個翻譯外掛就能解決。

右至左不是「文字靠右對齊」而已

W3C 的國際化文件列出了在 html 標籤加上 dir="rtl" 之後會發生的變化:段落與區塊靠右、雙向文字正確地由右往左排列、標點出現在正確位置、表格欄位由右往左排列、表單輸入從右邊開始,而且只要樣式表寫得正確,整個版面就會自動鏡像。這份文件同時給了三條關鍵原則:

1. 用 HTML 的 dir 屬性設定方向,不要用 CSS 設定基本方向,因為方向資訊屬於內容語意,即使樣式表沒有載入也要存在。
2. 樣式使用「邏輯屬性」:用 start、end 取代 left、right,例如用 margin-inline-start 取代 margin-left。這樣切換到右至左時,樣式表不必整份重寫。
3. lang 屬性不代表方向:宣告了阿拉伯文的 lang,並不會自動讓頁面變成右至左,方向一定要另外用 dir 宣告。

這三條原則的共同點是:它們都要在寫樣式表的第一天就遵守。如果你的網站已經大量使用 left、right、絕對定位與寫死方向的圖示,事後才要支援阿拉伯文,等於要把整份樣式表翻修一次。

案例 H:四語系含阿拉伯文的重建

我們公開的H 製造商案例是一家汽車美容化學品製造商,同時經營自有品牌與 OEM/ODM。舊站的稽核結果顯示,HTML 沒有宣告語言,英文版網站地圖直接回傳 404,網站地圖列出的網址裡沒有任何一筆是英文頁面,另外還有十幾個中文頁面根本沒有對應的英文版。對一家以外銷為主力的製造商,這代表在買家使用的語言裡,幾乎是查不到的。

重建時,新站以靜態產生的方式做出英文、繁體中文、西班牙文與阿拉伯文四個語系,118 個產品共 472 個產品頁,加上分類頁之後全站約 660 頁。其中阿拉伯文需要完整的右至左版面處理,這件事不能靠翻譯外掛解決,版面本身要從一開始就支援。搬遷之前,我們先把舊站 360 個網址完整抓下來,避免任何既有內容在搬家時悄悄消失;上線時,約三百筆轉址逐一驗證,確認落點是正常頁面,不是 404,也不是繞了好幾層的轉址鏈。

這個案例說明了一件事:多語系的問題,很少只出在翻譯本身。英文網站地圖壞掉、語言沒有宣告、頁面缺少對應版本,這些都是架構問題;右至左版面則是一個如果沒有在第一天規劃,事後就很難補救的架構決策。

阿拉伯文版上線前,多檢查這幾件事

• 產品型號與數字:阿拉伯文段落裡夾著英文型號與數字時,屬於雙向文字,要實際在瀏覽器裡檢查顯示順序,尤其是規格表。
• 有方向性的圖示:「下一頁」箭頭、麵包屑分隔符號、輪播方向,在右至左版面都要反過來。
• 表單:使用者輸入內容的方向不一定,W3C 建議在表單欄位使用 dir="auto",讓瀏覽器自動判斷方向。
• 字型:確認阿拉伯文字型在各種裝置上都能正常顯示,不要依賴訪客電腦剛好有安裝。
• PDF 型錄:阿拉伯文版的 PDF 也需要右至左排版,不能只替換文字。

最後提供一個數字作為參考。W3Techs 在 2026 年 9 月 28 日的統計顯示,在可辨識內容語言的網站之中,阿拉伯文網站只佔 0.6%,英文佔 49.5%。這個數字不能直接換算成商機,但可以提醒你:用阿拉伯文把產品規格寫完整的供應商並不多見。如果你確實有中東客戶,這是一個做好就會被記住的地方;如果你沒有,就不需要為了看起來國際化而勉強去做。

七、多語系上線前檢查表

直接回答:多語系網站上線前,至少要逐項確認語系範圍、網址結構、hreflang、canonical、網站地圖、轉址、語言切換、在地化內容與追蹤設定這幾大類。下面這張表可以直接貼進你的驗收文件,每一項都有明確的通過標準。

表中網站地圖那一列,正是案例 H 舊站的問題:英文網站地圖直接回傳 404。這種錯誤不會在網站畫面上顯示,老闆與業務每天看網站都覺得正常,只有用工具檢查才會發現。建議把這張表併入你的網站發包驗收文件,寫法可以參考網站發包需求規格書與驗收清單。

上線之後的前幾週,也要持續觀察各語系的索引與曝光狀況,確認英文頁真的被收錄、流量來自預期的市場。上線後該看哪些數字、什麼時候該調整,可以參考外銷網站上線後的前 90 天。

結語:先把一個語言做對,再決定要不要做第二個

多語系網站的架構決策,歸納起來只有四件事:語系數量由買家決定;網址結構照 Google 官方說法各有取捨,中小製造商多半選子目錄;hreflang 要雙向互指,canonical 要指向同語言;語言讓使用者自己選,不要依 IP 替他決定。其餘的在地化細節——單位、認證、日期、論述順序、右至左版面——則決定了買家讀完之後,是覺得「這家供應商懂我們」,還是「這只是一份翻譯」。

如果你的產品還有大量型號需要規劃成網站結構,可以接著看製造業產品型錄網站規劃;如果你還在想已經有阿里巴巴國際站了,是不是還需要自己的多語系官網,可以先看有阿里巴巴了還需要官網嗎。

HappyCXO Studio 的網站架設服務就是從這些架構決策開始:先盤點你的買家與既有網址,再決定語系、網址結構與 hreflang 的做法,最後才進入設計與翻譯。不論你最後是否找我們合作,都建議在動工前把本文的檢查表跑過一次——多語系網站最貴的錯誤,通常不是做錯一個頁面,而是在第一天選錯了架構。