Ahrefs 針對 374,756 個網域做的研究發現，67% 至少踩到一項 hreflang 常見錯誤，而且佔比最高的那一項，並不是多數教學反覆強調的「自我參照沒寫」，而是常被說成「次要，之後再補」的一個設定。
hreflang 是寫在頁面裡、告訴搜尋引擎「這頁是哪個語言版本」的對照宣告，Google 是把整組語言版本當一個叢集判讀，任何一個環節掉了，常常整組一起失效，而且不會跳警告提醒。這跟多數人的直覺不一樣，你可能以為標籤是逐頁獨立計分的，這頁寫對就這頁有效，那頁漏了頂多那頁沒效，實際上不是。這篇不想再排一份憑感覺編的清單，改照研究的實際出現頻率，把七個問題從最普遍排到最少見。
先從那個佔比最高、卻最常被低估的問題講起。
問題一：一半以上的網域，忘了設定 x-default
Ahrefs 這份研究裡，佔比最高的答案是 x-default，56.3% 的網域根本沒設定它。不少教學文章把它放在清單最後面，說它是補起來成本低、效益普通的小地方，實際數據卻完全相反，它是佔比最大的一項，遠遠超過其他任何一個錯誤。會被低估，多半是因為多數 SEO 檢查清單把重點放在「語言版本有沒有列全」，x-default 針對的卻是清單以外的訪客，容易被當成邊緣情境而略過，結果反而變成佔比最大的破口。
x-default 處理的是清單外的訪客，也就是使用者的瀏覽器語言、所在地區，剛好都沒有對應到任何一個已經設定過的版本。假設站上只做了中、英、日三個語言版本，某個訪客的瀏覽器介面是德文、人也不在這三個地區裡，Google 找不到吻合的版本時，會去看有沒有設定 x-default，有的話就把這個萬用版本端給他；沒有的話，Google 只能自己挑一個版本推送，猜錯的機率不低。
實務上，x-default 通常會指向兩種頁面：一種是讓使用者自己挑語言的選擇頁，另一種是拿一個通用版本頂著（常見做法是用英文首頁）。它的宣告不用加地區碼，直接這樣寫：
<link rel="alternate" hreflang="x-default" href="https://example.com/" />Code language: HTML, XML (xml)很多人把 x-default 想成是在跟 Google 說「這是我的主要語言版本」，於是直覺把它指向英文版，實際上這個理解正好反了。x-default 只有在找不到任何對應版本時才會被叫出來用，指向的應該是一個誰看了都不會太意外的通用落點，不是特別偏袒某個地區的語言版本。設定時也別忘了讓這個網址自己的 canonical 指回自己，並且能正常回傳 200，跟其他 hreflang 網址的要求一樣。
問題二：每五個網域，就有一個漏了自我參照
不少網站的 hreflang 是用外掛或程式邏輯自動產生的，規則寫成「列出其他語言版本的連結」，卻漏了「把當前這頁自己也算進清單」這一步，結果繁中頁的標籤組裡有指向英文版、日文版的連結，唯獨少了指向繁中頁自己的那一行。這種漏掉自我參照的失誤，佔了整體 18%。
Google 判讀這組關係時，做的事情類似點名。它要在每一頁裡都看到「我是誰」的宣告，不是只看到「這裡還有誰」。如果繁中頁的標籤組只列了英文版和日文版的網址，卻沒有把自己也列進去，等於這一頁在點名時缺席了，即使其他頁面都承認有繁中版存在，這組語言叢集也會因為自己不肯簽到而被判定不完整，連帶讓原本清楚的英文、日文對應關係一起打折扣。
修正方式不難，但要養成習慣。假設有繁中（zh-TW）、英文（en）、韓文（ko）三個版本，每一頁的標籤組都要完整列出這三個版本，包含自己那一個。以繁中頁為例，它應該同時放上指向繁中、英文、韓文的三行：
<link rel="alternate" hreflang="zh-TW" href="https://example.com/zh-tw/product/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />
<link rel="alternate" hreflang="ko" href="https://example.com/ko/product/" />Code language: HTML, XML (xml)英文頁、韓文頁也各自放上一模一樣的三行，差別只在每頁的 canonical 各自指向自己。記住「自己也是成員之一」，這個錯就不會再犯。
問題三：不少 hreflang，其實指向打不開的頁面
標籤格式都對，但 href 裡填的網址本身有問題，這種錯誤佔 16.9%，不會一眼看出來，卻會讓整組 hreflang 默默失效。Google 官方規定，hreflang 指向的每一個網址都必須能正常回傳 200 狀態，只要清單裡有一個網址落在下面幾種狀況，常常是整組一起失效，不是只有那一個網址被忽略：
- 網址回傳 404，代表頁面不存在或連結打錯
- 網址被轉址到別的地方（301 或 302）
- 頁面本身設了 noindex，等於要求搜尋引擎別收錄它
- robots.txt 直接擋住爬蟲抓取這個網址
另一個常被忽略的技術要求，是網址一定要用完整、帶有 https:// 開頭的絕對路徑。如果 href 裡貪方便寫成 /jp/ 這種相對路徑，搜尋引擎在跨網域比對版本時沒辦法正確解讀，等於這個對應直接失敗，必須寫全成 https://example.com/jp/ 才算數。
這種錯誤特別容易在網站動過大手術之後冒出來，換過網址結構、搬過主機、或砍掉舊頁面的那陣子，hreflang 清單裡卻還留著沒更新的舊網址，而那個網址早就打不開了。以一個做外銷的中小企業網站為例，如果英文版頁面因為改版被轉址，卻沒同步更新繁中頁指向它的 hreflang，結果就是繁中頁的宣告仍在，實際卻連不到有效的英文版，整組對應形同虛設。修正原則很單純，每次要動網址、搬頁面、設定轉址的時候，先花十秒查一下這個網址是不是還被哪個 hreflang 指著，清單跟著網址一起改，不要等網址先動了、清單事後才想起來補。
問題四：只有單方喊話，沒有回指的雙向配對
假設英文頁的 hreflang 清單裡列了繁中版的網址，但反過來查繁中頁的清單，卻找不到指向英文版的那一行，這種只有一邊承認關係存在的配對，Google 一律視為無效。這類缺少雙向配對的錯誤佔 15.3%。
hreflang 的配對邏輯類似雙向認證，不是單方面說「我認識你」就成立，對方也得說出同一句話，兩邊才算數。只要回指缺了一邊，這組宣告就會被忽略，而且常常是整組一起失效，不是只有漏掉回指的那一邊出問題。
這種情況常出現在網站分階段擴充語言版本的時候。假設某網站一開始只有中文和英文，半年後決定加開越南文版，越南文頁上線時通常會記得把中文、英文版的網址都列進去，但另一頭的中文頁、英文頁的標籤組，卻常常還停在半年前的舊版本，沒有人記得回去補上「現在也有越南文版」這一行。越南文頁單方面認了對方，對方卻沒認回來，這組配對從一開始就是破的。特別是網站擴張到第三、第四個語言版本時，最容易在趕上線的壓力下漏掉這一步。
要修好這一類問題，做法是把新增語言版本當成一次牽動全叢集的動作，而不是只改一頁。每加一個語言，就回頭巡一次同組的所有既有頁面，確認每一頁都被列進去、也都設定了回指，漏一頁就等於整組配對又破了一次。頁面數量多、光靠人工巡查容易漏掉時，下面會提到用 XML sitemap 集中管理是更省力的做法。
問題五：canonical 跟 hreflang 互相矛盾
hreflang 跟 canonical 標籤，有時候會給搜尋引擎矛盾的指令，兩個標籤分工不同，搞混了就會互相抵消。這類衝突佔比雖只有 8%，帶來的後果卻不輕。
canonical 要解決的，是同一個語言版本裡為什麼會有好幾個網址這種問題，例如同一頁因為排序參數、追蹤碼被搜尋引擎索引成好幾個不同網址時，canonical 負責告訴 Google 哪一個才是唯一該收錄的版本。hreflang 處理的是另一個完全不同的問題，它串起的是同樣內容在不同語言、地區之間的對應，立場正好相反，清單裡列出的每個網址都各自成立、沒有誰該被合併掉，只是分別服務不同語言的讀者而已。
實務上最常見的踩雷方式，是有人誤把 canonical 拿來做語言對應，把日文頁的 canonical 直接指向英文頁，想表達「這兩頁講的是同一件事」。這個設定一旦生效，Google 讀到的訊息卻是「日文頁只是英文頁的重複內容，不用收錄」，於是日文頁在搜尋結果裡消失，跟原本想達成的「兩個語言互相對應」完全是兩回事。
解法其實只有一條界線要守住，canonical 永遠只處理自己這個語言版本內部的重複，絕對不要拿它去指向另一個語言的頁面；需要把不同語言串起來，一律用 hreflang，不假手 canonical。判斷時只要記得問一句「這是同一種語言裡的重複，還是不同語言的對等版本」，答案會決定該用哪個標籤，兩個標籤從來不該互相取代。同樣的衝突也會出現在自動轉址上，如果網站依使用者所在地強制把訪客轉到某個語言版本，爬蟲可能只看得到單一版本，其他語言根本抓不到，要避免就別硬性轉址，讓使用者自己選，搭配前面提到的 x-default 引導。
問題六：語言代碼寫錯，或跟頁面實際語言對不上
第六類錯誤合計約 7.8%，分成兩個子問題，一個常被講，一個很少被提到。
比較常被提到的，是代碼格式寫錯，佔 4.6%。hreflang 遵循兩套國際標準：語言用 ISO 639-1 的兩碼寫法（zh、en、ja 這種），地區則是選填的 ISO 3166-1 Alpha-2 兩碼（TW、US、GB），中間用一個連字號串起來變成「語言-地區」的組合，像 zh-TW、en-US 都是這樣來的。規則本身不難記，但實際落筆時常常翻車，以下幾種最容易中招：
- 順序顛倒：把地區碼放在語言碼前面，例如寫成 tw-zh，正確寫法是先語言、後地區，也就是 zh-TW。
- 用了不存在的代碼：英國最容易寫錯，很多人直覺寫成 en-uk，但 UK 不在 ISO 3166-1 Alpha-2 的地區碼清單裡，正確寫法是 en-GB，GB 取自 Great Britain。
- 只寫地區碼、漏了語言碼：有些人會寫 jp 想代表日文版面，但 hreflang 的第一段一定是語言，不能只給地區碼，日文正確要寫成 ja，若要加地區則是 ja-JP。
- 繁簡版本混用：同樣是中文，台灣繁體對應 zh-TW，香港繁體對應 zh-HK，中國大陸簡體則是 zh-CN；另外還有一套依書寫系統分的 zh-Hant（繁體）與 zh-Hans（簡體），兩套邏輯不能混著用，例如不能同時把 zh-Hant 和 zh-CN 兜在一起當同一件事看待。
比較少被提到的，是 hreflang 宣告的語言，跟頁面 <html lang="..."> 屬性實際標的語言不一致，佔比雖然只有 3.2%，卻是多數教學漏講的一點。舉例來說，某頁 hreflang 標了 en-US，頁面 <html> 標籤卻寫著 lang=”zh-TW”，等於自己講的話兜不起來，搜尋引擎很難判斷該信哪一個。修正方式是把兩個標籤放進同一份檢查清單，改了 hreflang 就順手確認 html lang 有沒有跟著對上。自我檢查的方法不難，把全站用到的語言代碼列成一張表，逐一對照 ISO 639-1 語言碼與 ISO 3166-1 Alpha-2 地區碼，通常十幾分鐘就能抓出大半的代碼錯誤。
問題七：同一語言，卻重複對應到不同網址
同語言多頁參考，和同頁多語言參考，是這篇最後要補的兩個陷阱，合計約 5%，是 Ahrefs 研究裡佔比最低、卻也是多數文章完全沒提到的角落。
同語言多頁參考，是同一個語言代碼被拿去指了兩個不同的網址，好比 en 這個值同時出現在兩組不同的對照清單裡，各自指向不一樣的英文頁，Google 沒辦法判斷該採認哪一個，這個語言版本等於自我矛盾。同頁多語言參考剛好相反，是同一個網址被同時宣告成兩種互斥的語言，一個頁面不可能同時歸屬於兩個不同的語言版本。
這類錯誤通常出現在網站改版、多國站台合併，或不同團隊各自維護不同的 sitemap 卻沒同步的時候，舊清單和新清單疊在一起，同一個語言就被重複宣告了。檢查的方法也不難，把全站的 hreflang 清單匯出成一份表格，依語言代碼分組，只要同一組出現兩個以上不同的網址，就是踩到這個問題。修正原則很單純，每個語言、地區組合，全站只能對應唯一一個網址，定期用爬蟲工具抓一次全站 hreflang，比對有沒有出現重複值。
三種實作方式，選一種就好
處理完前面七個問題，剩下要決定的是 hreflang 標籤該擺在網站的哪個位置。這件事 Google 官方講得很明確：HTML head、XML sitemap、HTTP header 三種放法，判讀效力沒有高低之分，差別只在維護方不方便，重點是選定一種、確實做好，不要混用。
| 實作方式 | 怎麼放 | 適合誰 |
|---|---|---|
HTML <head> | 每一頁的 <head> 裡加上 <link rel="alternate" hreflang="..."> | 頁數不多（數十到數百頁）、用 CMS 建站、想要最直觀好驗證 |
| XML Sitemap | 在 sitemap 用 <xhtml:link> 集中標出各語言版本 | 頁數多、語言多，需要集中管理避免逐頁漏標的大型網站 |
| HTTP Header | 由伺服器在回應標頭裡傳遞 | PDF、DOC 等非 HTML 檔案 |
混用之所以危險，是因為兩套資料來源一旦內容兜不起來，Google 得在互相矛盾的兩份清單裡自己選一份採信，結果往往是兩份都不採信，最後除錯還得兩邊來回對照。與其事後花時間比對哪裡漏改，不如一開始就只留一個能改動的地方。
要選哪一種，看網站規模決定就好。頁面幾十到幾百頁，直接寫在 HTML head 裡最省事，改了馬上能在原始碼裡看到，除錯也直觀。語言版本一多、頁面動輒上千，逐頁改 HTML 遲早會漏掉幾頁，這時候把整個站的 hreflang 對應收進一份 sitemap 統一維護，會比追著每頁補行省力得多，也順便解決了問題四那種多加一個語言卻忘記回頭改舊頁的老毛病。
設定完怎麼驗證——舊的國際目標報告已經下架了
這點最多教學沒更新，卻最該講清楚。很多文章至今還在教讀者去 Google Search Console 的「指定國際目標」（International Targeting）報告查 hreflang 錯誤，但這個功能其實已經在 2022 年 9 月被 Google 關閉，現在點開左側選單根本找不到對應項目，照著舊文章操作只會白忙一場。
現在能用的驗證方式變得比較分散，大致可以分成四個層次來做。
第一步用 Search Console 內建的「網址審查」功能，直接貼上要查的語言頁網址，它會回報這頁目前的索引狀態，還有 Google 實際認定的 canonical 網址是哪一個。要是這裡顯示的 canonical 和原本設定的兜不起來，八成就是問題五提過的 canonical 衝突，或者這個網址本身沒有正常回傳 200。
第二步翻「網頁索引」報告，這裡雖然沒有專屬的 hreflang 分類，但裡面列出的替代網址索引失敗、noindex、或抓取受阻等紀錄，幾乎都是連帶拖垮 hreflang 的元兇，值得對照著查。
頁面數量龐大的站，第三步可以外掛 SEO 爬蟲（例如 Screaming Frog 就內建 hreflang 稽核畫面）整站跑一遍，一次性抓出所有漏了回指、代碼寫錯、或連結失效的頁面，這種規模的覆蓋率不是人工點開一頁一頁核對能比的。
想快速確認單一頁面，第四步可以用免費的線上 hreflang 檢測小工具，丟一個網址進去，就能看到這頁掛了哪些 hreflang 值、格式對不對、有沒有接上回指，拿來在上線前後對重點頁做最後把關很方便。抽查的頁面優先挑首頁、主要的著陸頁、和轉換率最高的幾個頁面，這幾頁一旦 hreflang 出問題，對流量的影響也最大。
時間點也不能隨便抓。改完 hreflang 不會馬上反映在搜尋結果裡，Google 得先重新爬一次、重新判讀過，通常抓兩到四週之後再驗，比急著隔天檢查準確得多。還有一點常被忽略，hreflang 對 Google 來說只是參考建議，不是非聽不可的命令。頁面裡明明整篇都是英文，卻把 hreflang 標成 zh-TW，Google 一樣會照頁面實際內容判斷，直接不理會那個標籤。這也代表驗證不能只核對標籤語法對不對，還要回頭看頁面內容跟它自稱的語言合不合，像是翻到一半的頁面、選單沒換語言、或機器翻譯讀起來怪怪的，都會讓 Google 對這組宣告打折扣。
67% 的網域至少踩到一項 hreflang 常見錯誤，不代表誰特別粗心，而是這套標籤天生就容易漏，它同時要求語言代碼寫對、雙向配對接上、canonical 不打架、x-default 補齊好幾個條件，任何一個掉了，整組往往一起失效，Google 也不會跳警告提醒。與其照著網路上隨便一份清單逐條檢查，不如先盯著真正佔比最高的那幾項：x-default 有沒有設、自我參照有沒有漏、網址是不是打得開。這三項加起來，已經涵蓋了 Ahrefs 研究裡九成以上的問題。把這幾項顧好，後面的地區行銷和在地化內容才有意義，不然翻得再用心的頁面，也可能一直被推送給看不懂的讀者。