多語言 SEO 通常被講成一個翻譯問題，外加一點技術標記。但把這個網站用十二種語言營運下來，也就是英語、阿拉伯語、德語、法語、匈牙利語、義大利語、日語、韓語、羅馬尼亞語、越南語，再加上中文的兩種書寫形式，我們很清楚地看到：翻譯才是簡單的那一半。

難的那一半在於，你在英語裡習以為常的每一條規則，都有一個依文字系統而變的版本，而你原本並不知道它存在。長度上限不一樣。結構會跑掉。數字會被一個想幫忙的譯者寫成國字，從那一刻起就不再和原文對得上。這些問題在有東西去檢查之前，一律看不見。

真正讓它跑得起來的是自動化，不是努力。 在任何內容上線之前，有十一項獨立檢查會從頭到尾掃一遍：語言涵蓋率、原文與各譯文之間的結構一致、數字一致性、標題層級順序、失效連結，以及依文字系統區分的中繼資料長度。每一項都是在對應的錯誤已經進了生產環境之後才寫出來的。關於一個多語言網站如何維持正確，這是誠實的版本。

多語言 SEO 從 hreflang 開始

hreflang 的作用比大多數指南暗示的要窄得多。它不決定哪一種語言能排上去。它只是告訴搜尋引擎，這幾個網址是同一份內容的不同語言版本，好讓合適的版本呈現給合適的使用者，而不是讓它們互相競爭。把它理解成版本之間的對照表，比理解成排名因素更準確。

真正重要的規則有三條，其餘都是細節。

標註必須互指。 如果英文頁指向德文頁，德文頁也必須指回來。單向宣告通常會被忽略，而這是所有實作錯誤裡出現頻率最高的一種，而且遙遙領先。如果單向宣告也算數，任何人都可以宣稱別人的頁面是自己的譯本，所以搜尋引擎不採信沒有回指的宣告。Google 在說明文件中寫明了這項要求，並列出了宣告它的三種方式。

每一組都必須包含自己。 頁面自身的網址也屬於它自己的那份清單。

用 x-default 指定當使用者的語言無法比對時該給他哪一頁。少了它，備援版本就只是猜的。

底下那個結構性的決定，是這些語言放在哪裡。這個網站採用的是同一個網域底下的子目錄，好處是所有東西都留在同一個主機名稱上，權重不會被切成十二份。依國家分開建立獨立網域，只有在業務本身確實彼此獨立時才成立，其他情況下很少成立。獨立網域各自算獨立資產，外部連結和累積起來的信任都不共用，等於同一份工夫要重做十二遍。

翻譯品質是一個排名問題

讀起來像機器翻譯的機器翻譯表現很差，原因不是搜尋引擎認出了工具。原因是產出很籠統，而籠統的內容一旦和更具體的東西放在一起比較，就會輸掉。讀者那一邊也一樣，彆扭的譯文在開頭幾行就會失去信任，而這個跳離會反過來影響評價。

有兩種失敗反覆出現。關鍵字的翻譯。 把英文片語直譯過來的說法，往往不是那個語言的人真正會搜的說法，於是一個翻譯得很正確的頁面，瞄準了一個沒人會輸入的字詞。關鍵字研究必須按語言分別做，而不是用英語做一次再翻譯過去。

文化與法規上的偏移。 幣別不對的價格、在那個市場根本不適用的法規、當地沒人認得的例子，都屬於這一類。一篇談英國資料保護義務的頁面，不做任何調整直接譯成日語，既準確又沒有用處。

真正需要判斷的是到底該翻什麼。全部翻譯成本很高，還會堆出一批那個市場沒人想看的頁面。挑最強的幾頁去翻，而且是依當地情況改寫而不是單純轉換，通常比把所有頁面都逐字譯過去更划算。

沒人提起的依文字系統的規則

這是最讓我們意外的一部分，而且完全是機械性的。

元描述的長度不是一個數字。 一段在英語裡長度剛好的描述，到了德語和羅馬尼亞語會偏長，因為同樣的意思在那裡需要更多的詞；到了日語或中文則會長得離譜，因為那裡每一個字承載的意思要多得多。分開之後我們才發現，中文和日語的描述用不到英語一半的字數就能把同樣的意思說完。所以我們最後依文字系統設了不同的區間，而不是用一個全域上限，因為單一上限對這一組裡的大多數語言都是錯的。

正文長度的下限也是同樣的道理。 一篇日語文章要傳達和一篇 1,100 詞英語文章相同的內容，詞數只有其中一小部分，字元數則完全是另一個量級。用詞數去衡量 CJK 內容沒有意義，所以日語和中文我們檢查字元數，其他語言檢查詞數。

標點不一樣。 問號並不是到哪裡都寫成 ?。阿拉伯語有自己的問號，中文和日語用全形形式，而日語的疑問句經常直接以句號收尾。一個靠 ASCII 問號去找問句的檢查程式，會安安靜靜地回報說每一個非英語頁面都沒問題，我們的程式在修好之前正是如此。

數字會在翻譯中漂移。 在英文用阿拉伯數字的地方把數寫成國字的譯者並沒有犯錯，但那一頁已經和它的原稿對不上了，而且當其中一邊更新時，另一邊不會跟著更新。所以我們會檢查每一份譯文裡的數字是否和原文一致。

結構必須對得上

我們跑的檢查裡最有用的一個，是拿每一份譯文和它的原文逐項比對結構：標題數量是否相同，清單和表格數量是否相同，表格列數是否相同，常見問題條目數量是否相同。原文裡的表格如果在譯文裡變成了段落，它就會在那裡把批次擋下來。

它能抓到別的手段抓不到的東西。把兩個短小的段落合併成一個的譯者，寫出了不錯的文字，同時也破壞了頁面和它的結構化資料之間的對應關係。少一條常見問題，意味著看得見的頁面和 FAQPage 標記互相矛盾，而這種矛盾降低信任，而不是提高信任。

它也能抓到遺漏。一個因為難翻而被悄悄丟掉的段落，人工複核時看不出來，對一個計數程式卻一目了然。

這要花多少代價，值不值得

說實話：十二種語言是很多，維護成本是實實在在的。每一篇文章就是十二個檔案，每一次修正就是十二次修正，每一項檢查都要跑完全部。就算真正能做生意的只有其中幾種語言，維護費用還是照十二種語言算。

值不值得，完全取決於你是不是真的在那些市場裡賣東西。一個你根本服務不了的語言帶來的流量只是虛榮指標，同樣的力氣花在把一種語言的權威做厚，對營收通常更有幫助。做這件事的理由是市場進入，不是曝光數。

如果你確實決定要做，讓它可持續的唯一一件事，是檢查被自動化了，而且在發布之前就跑。只靠自律去維護的十二種語言，一季之內就會散掉。有一道閘門、拒絕放行不一致內容集合的十二種語言，不會散。

Mecanik 在網站開發工作中建置並維護多語言網站，而第一項交付物通常不是內容，是那些檢查。

常見問題

hreflang 到底做了什麼？ 它告訴搜尋引擎，這幾個網址是同一份內容的不同語言版本，好讓合適的版本送到合適的使用者面前，而不是讓它們互相競爭。它不決定哪一種語言能排上去。標註必須互指，每一組都必須包含頁面自己，並且應該由 x-default 指出備援版本。

每一種語言都應該有自己的網域嗎？ 通常不該。同一個網域底下的子目錄把權重留在同一個主機名稱上，而不是切分到若干個彼此獨立的資產裡。依國家劃分的網域只有在業務本身確實彼此獨立時才成立，其他情況下很少成立。

機器翻譯會影響排名嗎？ 會，但是間接的。問題不在於工具被辨識出來，而在於產出很籠統，而籠統的內容一旦和更具體的東西放在一起比較就會輸掉。更大的失敗是關鍵字的翻譯：把英文片語直譯過來的說法，往往不是那個語言的人會搜的說法，所以關鍵字研究必須按語言分別做。

元描述的長度限制會因語言而異嗎？ 會，把它當成一個數字對多語言集合裡的大多數語言都是錯的。同樣的意思在德語或羅馬尼亞語裡需要更多的詞，在日語或中文裡則只需要少得多的字元，因為那裡每個字承載的意思更多。依文字系統分區間，比一個全域上限管用。

大規模維護時怎麼確保譯文一致？ 靠在發布前執行的自動檢查，而不是只靠自律。把每一份譯文和它的原文比對結構一致性，也就是標題、清單、表格和常見問題的數量是否相同，再確認數字對得上。這兩項都能抓出讀起來完全通順的缺陷，例如被合併的段落，或者被寫成國字的數字。