在 Hreflang 產生器 中點擊產生後，結果會是一整個已轉義的 HTML 區塊——每個語系列各有一個 <link rel="alternate"> 元素，並包含自我參照、將 & 符號編碼，且 hreflang 屬性會以標準大小寫撰寫，例如 en-US 或 zh-Hant。檢查結果包含 3 項不同工作，但人們經常將它們混為一談：以視覺方式掃描區塊，檢查格式與轉義錯誤；將完全相同的區塊安裝到每個替代頁面的 head；以及抓取線上頁面，確認每個語系確實都傳回完整集合，且各替代項目實際上都能互相指向。產生器本身只會產生可直接放入 head 的文字；它看不到您的網站，因此它在標記中描述的每個訊號，都必須重新對照已發布的 HTML 加以確認。如果某個區塊在程式碼編輯器中看起來整齊，卻缺少於該 URL 群集中的其中一個 URL，搜尋引擎就會忽略它，因為另一個頁面的單向宣告無法替未包含在內的頁面發言。請將產生後的階段視為部署儀式，而不是隨手貼上。
產生後，「檢查結果」實際上代表什麼
「檢查結果」可分成 3 項工作，而這些工作很容易在無意間被合併。第一項工作是將工具剛產生的區塊與您輸入的內容進行比對——每一列是否都產生一個元素、每個 hreflang 值是否都已正規化、每個 URL 是否都是完整限定 URL，以及每個 & 符號是否都呈現為 &？第二項工作是安裝：完全相同的區塊，一字一字都不得有任何差異，必須放入該語系叢集中每個頁面的 head。第三項工作是線上驗證：使用爬蟲、瀏覽器開發者工具或 curl，確認每個已發布頁面確實都傳回完整集合，且每個目標 URL 都能解析到真正存在且可供索引的頁面。這些步驟一項都不能略過，因為每一項都會偵測到不同類型的失敗。產生器無法連線至您的 CMS、查看重新導向，或觀察快取層、壓縮工具或範本繼承所造成的偏差，因此產生後的階段，才是切實的實作問題首次浮現的地方。
安裝前先檢查產生的區塊
第一輪檢查是安靜地閱讀工具剛產生的 HTML。區塊應針對每一列輸入內容包含一個 <link rel="alternate" hreflang="..." href="..."> 元素，每個屬性值都應以雙引號包圍，且 & 符號應呈現為 &。hreflang 屬性必須使用標準大小寫——應為 en-US，而非 en-us；應為 zh-Hant，而非 zh-hant。URL 必須是包含 host 的完整限定 URL，並使用 http 或 https；不得出現相對參照、協定相對參照、片段或內嵌認證資訊。如果任何一列違反上述格式規則，產生器會拒絕整組，而不是悄悄略過其中一個語系，因此剪貼簿中若只有部分區塊，通常表示分隔符號數量錯誤，或輸入內容中有格式錯誤的列。
| 產生 HTML 中的徵狀 | 可能的輸入原因 | 修正來源列的方式 |
|---|---|---|
| hreflang 值類似 en-us 或 zh-hant | 語系中的地區或文字以小寫輸入 | 使用標準形式 en-US、zh-Hant |
| href 包含 /en/page 或 //example.com/en | 相對 URL 或協定相對 URL | 提供完整 https://example.com/en/page |
| 查詢參數之間出現原始的 & | 複製前未將 & 符號轉義 | 確認區塊所有位置都使用 & |
| 區塊缺少您輸入的某個 hreflang 列 | 正規化後出現重複語系或重複目標 URL | 移除或合併重複列 |
| 未產生區塊 | 輸入的列少於 2 列 | 加入目前頁面，以及至少 1 個替代頁面 |
| href 包含 #section 或 user:pass@ | URL 中仍留有片段或認證資訊 | 移除片段及所有含 @ 的認證資訊 |
語系大小寫這一欄值得進一步檢視，因為它是最容易在視覺檢查中被忽略的項目。產生器會讓每個語系通過 Intl.getCanonicalLocales，因此 en-us 會變成 en-US、zh-hant 會變成 zh-Hant，而附加於語言的地區則會顯示為 fr-CA。大小寫正規化並非表面細節——搜尋引擎會將標籤視為不透明字串，而大小寫混雜的群集會被視為缺少項目的群集。請確認大小寫與您手動撰寫各個標籤時所輸入的內容一致，再繼續進行部署。
執行建置後的 3 項檢查
區塊讀取起來完全無誤後，就開始進行部署檢查。之所以要執行每個步驟，是因為前一步只能偵測到其他類型的錯誤。
- 盤點群集。寫下每個確實屬於替代頁面的當地語系化 URL，包括您目前正在編輯的頁面。切勿漏掉目前頁面——Google 將自我參照記載為一項必要訊號，而沒有自我參照的區塊，可能讓其他網站宣稱對這個頁面的所有權。
- 將完全相同的區塊安裝到每個頁面的 head。Hreflang 產生器會產生一組已轉義的內容；這一組內容必須一字不差地貼入每個替代頁面。各份複本之間出現偏差，是最常見的單一實作失敗，因此最好使用以產生時相同列為來源內容範本。
- 抓取線上群集，每種語言至少抽查 1 個 URL，並檢查傳回的 HTML。確認每個抽查 URL 都傳回 200、完整預期集合確實存在於 head 中，且每個 hreflang 目標都能解析到傳回 200 狀態的真實頁面。指向重新導向、404 或非標準 URL 的頁面，都會在無聲中削弱該群集。
一項有用的輔助檢查，是使用 diff 工具比較 3 或 4 個語系所呈現的 HTML。如果 head 區段除了空白或屬性順序之外還有任何差異，這些差異就是真正的實作偏差，而非無害的格式差異。有些發布系統會從側車檔案或資料庫欄位為 hreflang 套用範本，而該來源必須同時作為產生器使用的唯一真實來源，否則更新將不會傳播至每個頁面。
在線上頁面上確認自我連結與互惠連結
互惠連結是產生器無法自行驗證的部分——它無法從瀏覽器發出 HTTP 請求。自我連結與回連是兩項彼此相關的預期：每個頁面都必須在集合中列出自己，而每個替代頁面也都必須出現在其他每個替代頁面所發布的集合中。Google 曾記載，單向宣告可能會遭到忽略，因為其他網站不得單方面將您的頁面宣稱為其替代頁面。一項實用檢查方式是使用瀏覽器開發者工具或命令列工具，從群集中擷取 3 或 4 個範例 URL，列出每個頁面上找到的 hreflang 值，並確認各清單的大小與 URL 內容完全相符。
如需更深入的稽核指引，Google 關於當地語系化版本的文件會說明群集概念，以及搜尋引擎如何對待替代宣告。常見且值得留意的偏差，是 x-default 列出現在部分頁面，卻未出現在每個語系頁面上——集合中只能有 1 個 x-default，但它仍必須存在於每個頁面。產生器在正規化後，會以不區分大小寫的方式拒絕重複語系值，因此除了 en-US 之外若還有遺漏的 en-us，就會讓產生器拒絕整組內容，且必須在來源修正重複列。
哪些因素會在產生與索引之間破壞區塊
即使區塊產生得完全正確，發布系統在貼上後如何處理它，仍可能破壞結果。讓結果不再符合原始內容的常見原因包括：CMS 在儲存時將絕對 URL 改寫為相對路徑；範本繼承從其中一種語言頁面的 head 中移除某個替代頁面；HTML 壓縮工具將它認為重複的鏈接元素刪除；CDN 邊緣邏輯在某些國家路徑中注入重新導向，卻未在其他路徑中注入；以及 sitemap 或 HTTP 標頭實作透過不同管道發布第二組不一致的 hreflang 內容。搜尋引擎會將 HTML head、HTTP 標頭與 XML sitemap 視為同等效力，因此任何其他管道中的重複集合，都必須完全相符，否則就不應存在。
請選擇 CMS 能夠維持完整且同步的方法，並將 Hreflang 產生器用於該單一管道。若想更深入從概念層面瞭解工具如何依據每一列塑造輸出，產生器建置內容的逐步解說很適合搭配本文涵蓋的驗證角度。若要了解 WHATWG HTML 現行標準對 rel="alternate" 屬性的定義，link 類型規格會說明產生器所針對的屬性格式。
隨群集變更，確實執行建置後檢查
驗證不是一次性事件。當語系被新增、移除、重新導向，或移動至新的標準 URL 時，每個既有頁面上的 hreflang 集合都必須重新產生並重新安裝，而且必須重複抓取群集。請將產生的區塊視為群集在某個時點所宣告形狀的快照；該形狀只要有任何變更，快照就會失效。一項輕量的持續性做法，是每當國際化或 CMS 團隊安排發布時，都以標準 URL 清單重新執行產生器，將新區塊貼入測試環境，先在那裡抓取部分語系進行檢查，之後才將變更提升至正式環境。
最後還有一項值得記住的限制，就是工具無法為您做到的事情。它不會翻譯內容、偵測語言或保證搜尋結果。它也無法證明互惠連結，因為它無法存取遠端頁面。持續維持品質，關鍵在於將 hreflang 視為實質等價的當地語系化頁面之間的關係描述——內容準確、時效最新，且整個群集完全一致——而不是將它當作已翻譯主要內容或完整國際化架構的替代品。
如需進一步瞭解，請參閱 網站 Meta 標籤產生器：建置並驗證標籤。