多語言網站架構怎麼選？優缺點完整比較

想像一下：你的中文網站好不容易在台灣做起來了，自然流量穩定、名單也進得來。然後老闆丟來一句「我們明年要打日本跟東南亞市場，網站弄個英文版跟日文版應該很快吧？」這類情境的結論往往很簡單：多語言網站從來不是「把中文翻成英文上架」這一件事，它是一個架構決策。你選錯 URL 結構、漏掉語言標記、或讓兩個語言版互相搶排名，三年累積的權威可能半年就被自己人吃掉。這篇要帶你從架構層把多語言網站一次想清楚。

先給你一個能秒用的結論：多語言網站的架構設計，核心只有兩件事：第一是用哪一種 URL 結構來區分語言與地區（子目錄、子網域、ccTLD），第二是用 hreflang 把這個區分講給 Google 聽。把這兩件事做對，後面的內容、連結、報表才會通；做錯，再多翻譯量都只是把同一個錯誤複製到更多語言。順帶一提，如果你要的是 hreflang 標記本身的逐行設定與錯誤排查，站上已有另一篇更深入的 Hreflang 多語系 SEO 完全手冊，這篇刻意把鏡頭拉到「架構」這一層，不重複講標記細節。

多語言 SEO 的第一個岔路：你到底是要分「語言」還是分「地區」

多語言專案第一個要釐清的問題不是「要做幾種語言」，而是「要分語言，還是分地區」。這兩件事看起來像，其實是兩個完全不同的訊號，混在一起就是你後面所有架構錯誤的源頭。

語言（language）回答的是「這個頁面是用什麼語言寫的」，地區（region）回答的是「這個頁面是寫給哪個市場的人看的」。英文是一種語言，但英國人、美國人、新加坡人、印度人都講英文，他們搜尋的關鍵字、預期的價格貨幣、習慣的用語卻天差地遠。你若只標了語言沒標地區，Google 就只能用「大致是英文使用者」這個模糊訊號去排名，結果就是你的美國英文頁面跑到英國搜尋結果裡，轉換率自然一塌糊塗。反過來看，如果你的內容對所有英文讀者都一樣，硬切出 en-US、en-GB、en-AU 三個幾乎相同的版本，只會製造大量重複內容，拖累每個版本的排名。語言與地區該分多細，完全取決於你的內容與商業模式在各市場之間真的有多不一樣。

Google 自己在 國際化文件裡講得很直白：多區域與多語言是兩個獨立的問題，可以用不同的策略組合處理（2026）。所以你在設計架構之前，先回答這個小表格對應的問題，答案會直接決定你後面要挑哪一種 URL 結構。

你的真實情境	要處理的是	訊號需求
內容只需一套繁體中文，不區分市場	語言為主	一個 zh-Hant 版本即可
台灣 + 日本，兩個市場語言完全不同	語言＋地區	zh-TW、ja-JP 各一版
同樣是英文，但要分美國、英國、澳洲三個市場	同語言、不同地區	en-US、en-GB、en-AU 三版
中文也要分繁體（台灣）與簡體（中國）	同語言家族、不同書寫	zh-TW、zh-CN（或 zh-Hans）

把這個表填完，你就知道你的站其實需要幾個「語言地區版本」（業界簡稱 locale）。版本數量一旦確定，接下來的架構選擇才有意義。

四種 URL 結構攤開來比：ccTLD、子網域、子目錄、參數

多語言網站的「骨架」就是 URL 結構。市面上主要有四種選擇，各有代價。多語言 SEO 最容易被一刀切下錯結論，很多教學會直接說「子目錄最好」，但沒有一種結構是全方位最佳，只有最適合市場結構與資源的選擇。

架構	範例	SEO 權威	地區訊號強度	部署與維運成本	適合誰
ccTLD（國碼頂級網域）	example.tw、example.jp	完全分散，各站獨立養	最強（網域本身就是國別）	最高（多網域、多 GSC、多 CDN）	每個市場都有在地團隊、預算充足的大型品牌
子網域（subdomain）	tw.example.com、jp.example.com	可分開管理，連結訊號仍依實際連結傳遞	中（搭配 hreflang）	中（技術設定較分散）	各市場內容差異大、需要分開經營的團隊
子目錄（subdirectory）	example.com/tw/、example.com/jp/	同一網域，較容易集中維運與內鏈	中（搭配 hreflang）	低（一個網域，可集中管理）	大多數中小型站、剛起步的跨境品牌
網址參數（parameter）	example.com/?lang=ja	同網域，但管理與追蹤較複雜	較弱	看似較低，長期除錯成本高	通常不建議作為長期架構

幾個關鍵差異要特別點出來。ccTLD 的網域字尾 .tw、.jp 本身就是清楚的國別訊號，但每個網域需要分別建立內容、連結與品牌需求。子目錄位於同一網域，較容易共用技術設定、導覽與 內部連結；首頁或其他頁面的外部連結不會無條件把等量「權威」分給每個子目錄，訊號仍依網站架構與實際連結傳遞。

子網域是介於兩者之間的折衷。它的工程彈性高，每個子網域可以部署不同後端與 CDN 規則，也能分開驗證 Search Console。Google 能處理子網域與子目錄，差異主要在維運與網站如何互相連結，不能只用一條固定的「權威傳遞」公式判斷。你可以參考 子網域 vs 子目錄的完整取捨。

網址參數通常不適合長期多語言架構。它看起來簡單，但更容易造成追蹤、內鏈、canonical 與 重複網址管理負擔。這不是 Google 對重複內容的處罰，而是搜尋引擎可能自行整併版本，導致你偏好的語言網址沒有單獨呈現。

順帶一提，URL 結構的選擇還會連帶影響你的 Search Console 與數據追蹤設定。子目錄架構下，所有語言版本共用同一個 GSC Property、同一份報表，你只要在報表裡用網址前置字串篩選就能分市場看；子網域與 ccTLD 則需要為每一個語言版本各自建立、各自驗證一個 Property，報表也會完全分開。這聽起來只是行政作業，但當市場從兩個長到十個，分散的報表會讓跨市場比較變得很痛苦，這也是中央統一管控的團隊往往偏好子目錄的一個現實理由。

怎麼選：用「市場自主權 × 權威集中度」兩軸決定架構

這是在實務上反覆驗證下來的決策方式，給你當參考。不要再用「哪種結構 SEO 最好」這種問法，它沒有標準答案。改成問自己兩個問題：你的各個市場需要多大的「自主權」，以及你多在意「權威集中」。

把這兩個答案放進一個二維矩陣，架構幾乎就自動跳出來了：

	權威集中度：低（不在意主網域共享）	權威集中度：高（要主網域共享權威）
市場自主權：高（各地團隊自己決定內容、技術、上線時程）	ccTLD	子網域
市場自主權：低（中央統一管控內容與發版）	子網域（過渡用）	子目錄

舉個實務上怎麼判斷的情境。一家做寵物用品的台灣電商想跨境到日本與美國，但三個市場的品項、定價、在地文案都由總公司統一改，市場自主權低，且他們需要主網域累積的權威同步灌溉新市場，這個組合直接落在「子目錄」那一格。反過來，如果他們日本市場交給東京在地團隊全權經營，連首頁設計、商品組合都不一樣，那日本市場就值得獨立拉一個 .jp 網域或 jp. 子網域，用 ccTLD 或子網域把自主權做出來。

實務上多數時候會從子目錄起手。理由很實際：子目錄的部署成本最低、權威共享最直接，而且當某個市場後來真的長大到需要獨立時，你隨時可以把 example.com/jp/ 用 301 轉出到 jp.example.com，這是一條單向、可控的演進路徑。反過來從 ccTLD 要整併回子目錄，工程與 SEO 風險都大得多。對大多數還在摸索跨境的站，子目錄是「先把事做對、未來還能升級」的穩當選擇。

這裡也要提醒一個常被輕忽的配套：不管你選哪一種結構，每一個語言版本的根網域層級都要做好基礎的網域與網址一致性設定，例如固定 www 或非 www、統一 HTTPS。專案開始時就應確定 www、HTTP 與 HTTPS 的正規化規則，避免每增加一個語言版本，就多出一組重複網址。

Hreflang：把你的語言地區訊號翻譯成 Google 聽得懂的標記

選好 URL 結構只是把骨架搭起來，hreflang 才是把骨架上的語言地區訊號「正式遞交」給 Google 的那一道手續。說穿了，hreflang 的目的只有一個：明確告訴搜尋引擎「這一頁是寫給哪個語言、哪個地區的人看的，而且它還有其他語言版本的兄弟頁在這裡」。沒有它，Google 就只能用猜的，而它的猜測在多語言情境下經常出錯。

hreflang 的基本形式是一組成對標記，每個語言版本都要宣告自己跟所有兄弟頁的對應關係。例如中文版（zh-TW）指向日文版（ja-JP）時，日文頁也必須回指中文頁；缺少回指的那組標記可能被 Google 忽略。各頁同時列出自身版本，有助於維持完整群組（見 Google 對本地化版本標記的說明，2026）。

hreflang 的宣告位置有三種，你可以擇一或混用：放在 HTML 的 <link rel="alternate" hreflang="...">、放在 HTTP 標頭（適合非 HTML 檔，例如 PDF）、或放在 XML Sitemap 裡。三種都實務可用，優先順序通常這樣抓：靜態、頁數不多的站用 HTML link；頁數破千或頻繁自動產生的站，實務上強烈偏好用 Sitemap 集中管理 hreflang，因為它把標記從頁面裡抽出來，改版與除錯都乾淨很多。

hreflang 的值也有規矩。它可以是純語言（en）、語言加地區（en-GB）、或是修飾版（zh-Hant、zh-Hans）。你不需要每種排列組合都做，但同一組語言地區用什麼值要從頭到尾一致，混用 zh-TW 與 zh-Hant-TW 是很常見、卻很難被抓出來的錯誤。再加上一個 hreflang="x-default"，用來兜底所有沒有對應到明確版本的訪客，這通常是你的英文版或最通用的版本。x-default 很多人會漏，但它其實是整組 hreflang 能正常運作的保險絲。

如果你想看完整的標記寫法、常見錯誤碼與排查工具，前面提過的那篇 Hreflang 多語系 SEO 完全手冊有更細的逐行示範，這裡就不重複展開，把焦點留在架構層的決策。

Hreflang 與 Canonical 的共舞：兩個標記不能互相打架

多語言站很容易在 hreflang 與 canonical 之間產生矛盾。Hreflang 描述不同語言或地區版本的對應；canonical 則提示哪個網址是重複內容組的代表版本。若英文版 canonical 指向中文版，卻又把兩者列為 hreflang 版本，Google 可能忽略部分標記或選擇不同標準網址。

重複出現的典型錯誤長這樣：工程師為了「統一網址」，把英文版的 canonical 指向中文版（或反過來），心想反正內容差不多。這一指，等於告訴 Google「英文版只是中文版的分身，不用單獨排名」，你辛辛苦苦做的英文版直接從索引裡消失。正確做法是：每一個語言版本的 canonical 都應該指向自己（self-referencing canonical），再用 hreflang 來表達語言之間的兄弟關係。canonical 管同語言內的重複，hreflang 管跨語言的對應，兩者各司其職、不越界。

這裡也順帶講一個進階但很實用的情境：當你同一個語言地區有不只一個重複網址（例如帶追蹤參數的版本、或 AMP 版本），你應該用 rel canonical 把這些重複版收斂到一個主網址，再讓這個主網址參與 hreflang 群組。順序很明確：先在單一語言內部把重複解掉，再跨語言做對應。把層次分清楚，除錯的時候你才不會在兩個標記之間來回打轉。

除了 hreflang，這些頁面層的語言訊號也不能漏

hreflang 是跨頁面的語言對應訊號，它解決的是「這一頁跟那一頁是什麼關係」。但單一頁面自己也有幾個「就地」的語言聲明，做齊了 hreflang 才有加乘效果。把這些頁面層訊號當成 hreflang 的地基，地基不穩，跨頁標記再標準也站不直。

第一個是 HTML 的 lang 屬性。每個語言版本的根 <html> 標籤都應帶上對應語言值，例如繁中可用 <html lang="zh-Hant-TW">、日文用 <html lang="ja">、美式英文用 <html lang="en-US">。它主要服務瀏覽器、螢幕閱讀器、字型與翻譯功能。Google 表示其語言判定主要依可見內容，不依賴 lang 屬性，因此這項設定重要，但不能替代正確內容與 hreflang。

第二個是結構化資料裡的 inLanguage 欄位。若所用 Schema 類型支援這項屬性，可以標註內容語言，作為語意描述的一部分。它不是 Google 多語言定向的必要標記，也不能取代可見內容、獨立 URL 或 hreflang。

第三個是看得見的語言切換器。很多團隊習慣把語言切換做成國旗圖示，但國旗對應的是國家，對應不到語言：一面加拿大國旗沒辦法告訴讀者點下去會看到英文還是法文，一面瑞士國旗更是同時涵蓋德法義三種語言。比較穩妥的做法是用文字標示語言名稱（例如「中文」「English」「日本語」），並確保每個語言版本都有獨立的、可被連結的 URL。這個切換器同時也是一個輕量的內部連結訊號，告訴 Google 這個頁面還有其他語言兄弟頁存在。

把可見內容、獨立 URL、語言切換器與 hreflang 串起來，能讓讀者與搜尋引擎更容易找到正確版本。lang 與 inLanguage 可補充文件語意，但沒有「層次越多就必然提升排名或收錄」的公式。

內容本地化的 SEO 真實成本：為什麼機器翻譯會拖垮你的國際流量

架構與標記做對之後，內容本身仍會決定國際流量能否成長。Ahrefs 在 2023 年的研究估計，96.55% 的受測網頁沒有取得 Google 自然搜尋流量（〈96.55% of Content Gets No Traffic From Google〉）。這項第三方流量估值不能證明翻譯內容一定失敗，但提醒團隊：若原頁缺乏需求、品質或競爭力，整批翻譯不會自動解決問題。

機器翻譯在多語言 SEO 裡的問題，不只是文法。若沒有校對價格、法規、服務範圍、用語與搜尋意圖，內容可能無法滿足當地讀者。Google 沒有公開一個專門衡量「跨語言資訊增益」的分數；真正可驗證的是譯文是否正確、有用，並符合目標市場需求。

因此「本地化」（localization）跟「翻譯」（translation）的差別可以這樣定義：翻譯是把字從一種語言換成另一種語言，本地化是讓內容真正服務那個市場的人。本地化包含把價格換成當地貨幣、把案例換成當地讀者熟悉的場景、把法規與物流說明換成當地適用的版本、甚至把搜尋關鍵字重新做一次當地的搜尋意圖研究。同一個產品，台灣人搜的關鍵字跟日本人搜的關鍵字經常是兩個完全不同的字，你得為每個市場重新做關鍵字研究，別只是把台灣的字翻過去就算數。

舉個具體的例子來感受這件事。「寵物用品」這個品項，台灣消費者可能搜「狗飼料推薦」，日本消費者搜的是「ドッグフード おすすめ」，美國消費者搜的可能是「best dog food reviews」。這三組字並非彼此的翻譯，它們背後代表的是三個不同的搜尋意圖、三種不同的競爭強度、三種不同的價格區間與評比文化。你若只把「狗飼料推薦」逐字翻成英文丟上去，等於在美國市場用一個根本沒人搜的字去競爭，再完美的 hreflang 與網址結構也救不回這種內容層的失準。回過頭，前面不斷強調的一點是：每個市場的關鍵字研究必須獨立做，它是本地化的起點，不該被當成翻譯流程的附屬品；漏掉這一步，後面的架構功夫做得再扎實都是空的。

較穩妥的方式是分階段推進多語言內容。先把資源集中在最重要的一到兩個市場，完成當地關鍵字研究、案例、貨幣、法規與客服支援，再依流量與轉換決定是否擴張。一次開十個只有機器翻譯的薄弱版本，會分散工程、內容與維運資源。

因此，「用 AI 一鍵產生多語言內容」仍要保留人工查核。AI 可以協助初稿、術語表與在地化檢查，但涉及法規、文化、產品承諾與搜尋用語時，仍需要熟悉當地市場的人確認。Google 不會因內容使用 AI 就自動處罰，風險在於大量發布未查核、低價值或以操控排名為目的的內容。

讓 Google 確實讀懂你的多語言站：Sitemap、驗證與檢索管理

架構、標記、內容三件事到位之後，還有一道工程層的手續：讓 Google 真的能有效率地把你的多語言站爬完、並在報表裡看到每個市場的表現。這一步很多團隊會跳過，結果就是做了一堆語言版本，卻在 Search Console 裡看不到任何一個市場的數據。

第一件事是 Sitemap。前面提過，頁數一多實務上就偏好把 hreflang 寫進 Sitemap。具體做法是為每個語言版本準備獨立的 Sitemap（或同一份 Sitemap 裡用 xhtml:link 宣告 hreflang），然後在 Google Search Console 裡分別提交。這樣做的好處是 Google 一次就能拿到完整的語言對應關係，不用等爬蟲慢慢發掘。對大型多語言站來說，這也是管理 檢索預算的關鍵，你希望 Google 把有限的檢索資源集中花在每個語言的「主版本」上，避免在參數變體之間空轉。

第二件事是驗證 hreflang 與索引狀態。Search Console 的舊版〈國際定向〉報表已於 2022 年停用，不能再拿它當錯誤清單（見 Google 的停用公告）。上線後可抽樣使用網址檢查、檢視 Google 選定的 canonical，搭配 XML Sitemap、伺服器記錄與 hreflang 爬取工具檢查雙向回指；Search Console 成效報表則依頁面、國家與查詢觀察各版本表現。

第三件事是行動版本的一致性。Google 已全面採用行動優先索引（mobile-first indexing），主要使用行動版內容進行檢索與索引；這是索引機制，不是行動版自動取得排名加分；Google 在 2023 年 10 月的公告中說明了這項轉換。行動流量占比會依市場與期間而變，Statista 的全球趨勢（2026 年 4 月）可作為裝置測試背景，不是排名規則。多語言站要確認行動版保留完整內容、hreflang 與 canonical，也要測試語言切換和 JavaScript 渲染是否能讓爬蟲取得各版本 URL。

如果你想更全面地檢查整個多語言站的技術健康度，建議把這些項目併入你的 技術性 SEO健檢清單裡，跟爬蟲溝通、索引、結構化資料一起看，才不會見樹不見林。

多語言網站在 AI 搜尋時代的新意義：答案引擎更需要語言地區訊號

這裡把視角拉高一層來看。多語言架構在 2026 年的意義，已經不只是「讓 Google 在不同國家的 SERP 上排名」，它還多了一個全新的戰場：AI 搜尋與答案引擎。

AI Overviews 與 AI Mode 建立在 Google 搜尋索引上，因此可檢索、可建立索引及符合摘要資格仍是基礎；Google 沒有要求 AI 引用專用 Schema。Hreflang 有助於 Google 搜尋提供適合的語言或地區版本，但不能假設 ChatGPT、Gemini 等所有產品都用相同方式解讀它。對所有平台都成立的基本功，是每個版本都有獨立 URL、可見的在地語言內容與清楚來源。

在資源有限時，先把少數核心市場的內容做完整，通常比同時維護十個薄弱版本務實。這是內容品質與維運能力的取捨，不是已公開的答案引擎引用門檻；成效仍要用各市場的曝光、引用、導流與轉換驗證。

這也是前面反對「一鍵機器翻譯上架多語言」的另一個深層理由：在答案引擎時代，淺薄的跨語言內容不只排名不起來，連被 AI 引用的資格都拿不到。深度本地化的少數市場，會贏過粗糙本地化的全面市場。

怎麼衡量多語言架構真的成功了：每個市場該盯的三個指標

架構上線之後，最常見的錯誤是只看總流量數字，然後下結論說「多語言做不起來」。真正的問題多半出在測量方式：你沒有把數據拆到每個語言地區版本來讀。多語言站的成績單必須分版本來看，全部混成一鍋只會把真正的問題藏起來。

建議盯三個指標。第一個是每個語言版本的自然搜尋流量與索引頁數。在 Search Console 裡用網址前置字串或篩選器，把日文版 example.com/jp/ 的數據單獨拉出來看。若重要頁未被索引，先檢查可抓取性、canonical、內容品質與 sitemap；hreflang 用來協助選擇語言或地區版本，不是索引指令。索引正常但流量沒有成長時，再檢查需求、搜尋意圖、競爭與內容。

第二個是每個市場曝光與點擊的國家分佈。Search Console 的國家報表能顯示搜尋表現來自哪些國家。若日文版的目標是日本，卻長期主要在其他國家取得曝光，可以檢查 hreflang、內部連結、內容在地性與實際市場需求；國家分佈本身不能單獨證明語言地區訊號設定錯誤。

第三個是每個語言版本的轉換率與名單品質。SEO 帶來流量只是上半場，跨境的最終目的是拿到對的客戶。把每個語言版本的表單送出、結帳完成、詢問信件分開追蹤，你會發現有些語言版流量漂亮但轉換極差，這通常意味著你的本地化只做到表面，價格貨幣、物流選項、信任元素都還沒到位。流量與轉換一起看，你才能判斷某個市場到底值不值得繼續投入資源。

這三個指標可以排成一張每個月更新的小表，每個語言版本一欄，你會很清楚地看到哪個市場在起來、哪個市場在空轉、資源又該往哪裡搬。多語言 SEO 從來不是「上架完就結束」的專案，它需要你持續量測、持續微調，跟所有白帽 SEO 一樣，是長期累積資產的工程。

五個實務上重複出現的多語言 SEO 地雷

把前面講的全部收斂成一份檢查清單，給你直接拿去對自己的站。這五個是實務上重複出現、會直接吃掉國際流量的地雷。

1. 自動轉址強迫訪客跳語言。很多站會用 IP 偵測強制把訪客跳到「對應」的語言版本，結果一台灣出差到日本的使用者，就被硬生生跳到日文版，連切回中文都困難。這種做法會傷害使用者體驗，也會影響爬蟲。正解是給提示、不強制，並保留一個明確、可被記住的語言切換器。
2. hreflang 只做單向。中文頁指向日文頁，但日文頁沒有回指，缺少回指的配對可能被忽略。每個版本應列出自身與所有對應兄弟頁。
3. canonical 跨語言亂指。把英文版的 canonical 指向中文版「統一網址」，等於告訴 Google 英文版不用單獨存在。每個語言版本的 canonical 都要指向自己。
4. 語言切換用 JavaScript 動態產生網址。點了切換按鈕才在瀏覽器端動態換語言，導致每個語言版本都沒有獨立、可被收錄的 URL。爬蟲看不到、答案引擎也引用不到。每個語言版本都必須有一個靜態、可連結的獨立網址。
5. 忽略網站搬家時的多語言網址。改版時，各語言舊網址都應以 301 對應到最相符的新網址，hreflang 群組也要同步更新。若其他語言版整批變成 404，既有流量與連結訊號可能受損。

這五個地雷的共同點是：它們都不是「很難的技術」，而是「以為沒事、其實默默流血」的細節。多語言 SEO 的勝負，多半就輸在這些細節上。

從零部署多語言架構：六步行動方案

把整篇濃縮成你下週就能開始動工的步驟。不管你現在是零語言版、還是已經亂做了一兩個版本想收拾，這個順序都適用。

1. 盤點你的語言地區版本。把前面那張「語言 vs 地區」表格填完，確定你到底需要幾個 locale、每個 locale 對應的語言代碼與地區代碼是什麼。這一步定了就不能亂改，後面全部跟著它走。
2. 決定 URL 結構。用「市場自主權 × 權威集中度」兩軸矩陣選出 ccTLD、子網域、或子目錄。多數中小型站建議從子目錄起手，保留未來升級的彈性。
3. 固定基礎正規化。每個語言版本的 www / 非 www、HTTPS、結尾斜線一次定死，搭配 self-referencing canonical。基礎不穩，多語言只會放大問題。
4. 部署 hreflang 與 x-default。每個版本自我宣告、雙向指向所有兄弟頁、補上 x-default。頁數多用 Sitemap，頁數少用 HTML link。細節逐行寫法看前面提過的 Hreflang 手冊。
5. 做真正的本地化，不是翻譯。為每個市場重新做關鍵字與搜尋意圖研究，調整貨幣、案例、法規、用語。寧可深度做兩個市場，也不要淺薄做十個。
6. 上線後持續抽樣驗證。用網址檢查、Sitemap、爬取工具與伺服器記錄確認 canonical、hreflang 雙向回指及行動版渲染；Search Console 舊版〈國際定向〉報表已停用。

如果你是用 WordPress 架站，W3Techs 的統計（2026 年 6 月）顯示 WordPress 仍占據全球網站將近一半的市占，多語言落地多半會靠外掛完成。這類外掛（例如 WPML、Polylang、TranslatePress）能幫你把子目錄、hreflang、語言切換器自動接好，可以省下大量工程時間；在 WordPress 架站實務上常用的視覺化方案是 TranslatePress，你可以在它的基礎上再把上面的六步跑一遍，別讓外掛的自動設定取代你對架構的理解。

多語言網站是一個會跟你一起長大的資產。選對骨架、把語言地區訊號講清楚、用真實的本地化內容填進去，你的國際流量才有機會像滾雪球一樣逐年累積。要特別記住一件事：架構是半永久性的決策。一旦你的多語言網址上線、被 Google 收錄、被外部網站連結指向之後，要回頭改動結構的成本只會越來越高，每一次大規模搬移都伴隨流量波動的風險。所以前期的版本盤點與結構選擇，值得你多花一個禮拜想清楚，這點時間投資遠勝過事後花半年收拾殘局。現在，先回到你那份語言地區版本表，把第一格填下吧。