AO2 GUIDE 26 · 搜尋與量測
多語網站 SEO 先確認目標市場、語言需求與維護能力，再安排網址、在地化內容及 hreflang。同步術語、產品條件與各語版本更新。
本篇提供品牌商與技術型企業可採用的多語規劃方法，包含資料底稿、在地表達、語言切換與技術驗收。文中的市場與流程是示意，實際語言與地區安排仍需依企業服務範圍確認。
多語網站 SEO：先分清楚語言版本與市場版本
同樣使用英文的市場，可能有不同產品、單位、供應與合作條件；同一個市場，也可能需要多種語言。請先列出要服務的讀者、可提供的產品與後續窗口，再決定哪些內容共用、哪些需要分開，不能只用國旗代替全部判斷。
例如某產品在不同市場有不同配置，就需要清楚對照，而不是只翻譯同一段規格。若企業還沒有當地供應或回覆安排，也應在規劃時確認，避免網站語言讓讀者誤以為所有服務都已能在當地提供。
這些條件會影響內容與詢問路徑。先整理市場範圍，再依 B2B 採購旅程 確認讀者要完成的判斷，會比先大量翻譯所有舊文章更容易掌握工作價值。
建立共用主資料，保留各市場的必要差異
產品正式名稱、識別、核准規格、來源與版本，可以先建立共同底稿；各市場的單位、用語、供應與文件，則保留適合的對應欄位。共用不代表每個市場都一樣，而是差異有明確來源，不必各自保存一份無法追溯的答案。
遇到資料衝突時，先確認產品版本與適用範圍，再安排翻譯。若原稿本身沒有說清楚限制，翻譯後通常只會讓問題擴展到更多頁面。多語內容的第一個品質關卡，仍是來源是否可靠，而不是文句是否流暢。
可以結合 企業知識庫整理 建立核准、版本與更新責任。當某個規格變更時，團隊才知道哪些語言、圖片、文件與問答需要同步回查，而不是只更新中文頁面。
翻譯之外，還要還原當地讀者的問題
不同市場使用的產品名稱、應用情境與查詢語言，可能不完全對應原文。請用當地客戶、業務與可信資料核對用語，再整理內容。不要只把字面翻對，就假設讀者會用相同方式找資料或理解專業詞。
例如原文以某個產業俗稱介紹產品，另一語言可能需要先說明正式類別與用途。內容可以調整開頭、例子與段落順序，但不能在在地化過程新增沒有核准的功能。表達可以變，事實與適用邊界仍應一致。
研究方法可參考 關鍵字與搜尋意圖指南，再由適合的語言與市場人員確認。工具可以提供候選問法，但不能替企業證明這些問題真的符合當地採購情境。
先決定頁面範圍，再安排網址與版本對照
多語網站可以有不同網址架構，但應使用穩定、可維護的方式，讓每個需要被找到的版本有適合入口。規劃時先列出對應頁面，再由網站人員依既有架構確認實作，不需要為了套用某種形式而任意重做全站。
| 規劃項目 | 要回答的問題 | 驗收重點 |
|---|---|---|
| 內容範圍 | 哪些頁面真的需要此版本 | 對應產品與市場任務 |
| 網址安排 | 每個版本如何穩定到達 | 不靠難以追蹤的狀態切換 |
| 語言切換 | 使用者會被帶到哪一頁 | 保留相關產品與文章情境 |
| 更新責任 | 原資料變更時誰處理 | 對照、核准與回查紀錄 |
不需要所有頁面都同時具備所有語言，但缺少版本時應有清楚的處理方式。不要讓語言選單看起來提供對應，實際卻把人送到無關首頁，讓讀者重新尋找同一項產品。
hreflang 描述版本關係，不能代替內容品質
Google 提供 hreflang 等方法，協助表達頁面的語言與地區版本。實作時，需要核對適合的語言代碼、對應網址與回連關係，並依官方文件確認。標記寫上去，不代表平台一定採用，也不能補救沒有翻譯或內容不相關的頁面。
例如同一產品有中文與英文版本，就應確認它們真的互為相關頁面，並依選定方法維持一致對照。不要把所有英文頁都指向同一個中文首頁，也不要把不同產品只因語言不同就配成一組。
hreflang 與 canonical 也有不同用途。前者描述版本關係，後者表達重複或相近內容的標準網址偏好；不能把所有翻譯頁都當成同一份需要消失的重複內容。實際設定應由網站人員依頁面與官方規範核對。
語言切換與導覽，要保留使用者的任務
讀者在某項產品頁切換語言時，通常希望繼續看同一項產品，而不是回到網站起點。請保存版本對照，讓切換能維持合理情境。沒有對應頁時，也應清楚說明或提供適合的替代，避免讓人誤以為內容不見了。
選單、麵包屑、相關閱讀與詢問入口，也需要使用合適語言與市場資訊。中文文章突然連到另一市場不適用的商務條件，可能造成理解落差。連結驗收可以依 站內閱讀路徑指南 一起處理。
手機版尤其要檢查較長的語言名稱、標題與按鈕。不要只測原文畫面，因為不同文字長度可能造成換行、裁切或元件位移。語言版本應各自完成主要任務，而不是只確認選單能切換。
圖片、文件與表單，也屬於多語內容
產品圖上的文字、圖表單位、下載文件與影片字幕，都可能影響理解。若頁面已翻譯，附件仍是另一語言，請確認讀者是否能辨認用途，並提供必要說明。不要只翻內文，卻留下沒有適用資訊的舊文件。
多市場圖表要核對單位與數據前提，不是只換文字。圖片工作可參考 品牌圖片與網站 SEO，避免在地化後的圖文出現不同承諾。精確圖面與產品標示，仍應使用核准資料。
表單則確認欄位、錯誤提示、成功訊息與接收窗口。不同語言詢問進來後，是否有人能接手，也應列入規劃。相關方法可見 詢問表單指南，讓前台語言與後續流程一致。
驗收要同時看語言、事實與技術
語言審查確認自然與清楚，產品審查確認型號、條件與範圍，網站審查則核對網址、版本關係、連結與手機流程。這三層可以分工，但應使用同一份工作單，避免每個人只確認自己看到的部分。
例如語句很流暢，卻把可選功能寫成標準功能，就需要回到來源；頁面內容正確，但切換語言後到了錯誤產品，也不能算完成。驗收任務應讓測試者從入口找到必要條件，再走到適合的下一步。
如果有既有網址或架構變更，也要核對移轉與轉址。可依 網站改版與 SEO 保存對照，不要在翻譯工作中順便改路徑，卻沒有安排舊入口承接。
成效觀察，要依市場與任務分開
不同語言頁面的搜尋量、產品範圍與服務成熟度可能不同，不能直接用總流量排名決定哪個版本成功。先確認觀察市場、相關頁面與需要的行為，再比較合適的期間與條件。
Search Console 可以提供國家、查詢與頁面等線索，網站端則看內容使用與有效詢問。兩邊資料需要分清定義，相關方法可見 Search Console 企業指南。資料量不足時，先確認內容與流程是否正確，不急著給出全面結論。
也可以蒐集當地業務反覆收到的問題，回查哪些內容缺少說明。若不同市場對同一項規格有不同理解，就修正表達與必要條件，而不是只把原文再翻一次。
更新流程要有版本對照與負責人
原資料修改後，先列出受影響的市場頁面、圖片、文件與問答，再由對應人員確認。可以區分必須同步更新與需要另外評估的項目，保留原因，避免所有語言版本各自等待，卻沒有人知道目前狀態。
知識與翻譯記錄也應能交接。新同事需要知道正式名稱、常用術語、核准來源與例外，不只是拿到一份舊譯文。這些底稿能減少反覆確認，也讓後續 AI 協作有較可靠的使用範圍。
需要整合市場、內容與網站時，可了解 多語與全球內容服務。比較穩定的起點，是先完成一個產品或服務的完整版本循環，再依團隊資源擴大，不必一開始就翻遍所有歷史內容。
常見問題
多語網站一定要用不同網域嗎？
不一定。可依既有網域、團隊、目標市場與維護能力評估不同網域、子網域或子目錄。先比較權限、部署、翻譯更新與量測需求，再決定能長期維護的架構。每個版本都應有穩定入口與明確語言關係，內容和服務範圍也要相符。架構選定後用核心產品走完整個切換、文件與詢問任務，不只檢查網址長得像多語網站。
加上 hreflang，就代表在地化完成了嗎？
沒有。hreflang 描述語言或市場版本關係，仍需確認頁面內容、相互對應、語言切換和技術輸出符合規則。產品條件、單位、文件、供應與回覆窗口則需由內容與營運核對。用目標語言的實際選型任務驗收，確認不會跳到錯版本或取得不適用手冊。標記可以描述版本關係，不能自動完成翻譯品質或市場適配。
預算有限時，應先翻哪些頁面？
先完成一條可使用路徑：核心產品或服務、必要規格與限制、關鍵文件、公司與合作資訊，以及能回覆該語言的聯絡入口。用真實市場問題排序，不按中文頁數等量翻譯。術語與來源先整理，再安排語言及產品核對。若無法維護全部內容，明示提供範圍並設定更新責任；大量翻出英文草稿卻讓文件與接手流程缺席，不能算完整上線。
參考資料
本文為 AO2 獨立編寫的企業實作指南。工作情境與清單為方法示例；平台功能與技術規範請以所列官方文件為準。
