標準化標籤用於在相同或實質相似的內容可從多個網址存取時，宣告單一的首選網址，告訴搜尋引擎應將哪個版本視為主要副本。標籤本身是一個置於頁面 head 內的 HTML link 元素：<link rel="canonical" href="https://example.com/preferred-page/" />。當多個網址因追蹤參數、www 與非 www 主機變體、通訊協定差異或聯盟轉載等原因而顯示重複或近乎重複的內容時，標準化標籤會將抓取、建立索引與連結權重訊號整合到單一網址上。搜尋引擎在決定索引哪個網址時，會將該訊號與重新導向、網站地圖項目、內部連結及內容本身一併考量，因此標準化標籤是一個強烈的提示，而非具強制性的指示。妥善使用時，它能避免重複內容造成的權重分散、維持分析資料的乾淨，並在頁面因設計而必須存在於多個網址時保護排名。標準化標籤產生器會接收您要指定為首選的絕對 HTTP 或 HTTPS 網址，透過瀏覽器的 URL 解析器進行標準化，並將其轉為該精確的 link 元素，經過 HTML 跳脫處理以便安全地貼上。
標準化標籤適用於哪些情境
在多種情境下，標準化標籤是比重新導向或 noindex 更合適的回應。共同的主題是：相同的主要內容可從多個網址存取，而每個重複項目都必須保持公開可存取。
- 參數化追蹤或排序網址（例如 ?utm_source=、?sort=price 或 ?ref=newsletter）若未改變頁面的重要內容，可將乾淨的網址列為標準化網址，使參數不會造成索引分散。
- 您文章被聯盟轉載、重新發布或合作夥伴代管的版本，應在各份副本上將您的原始網址宣告為標準化網址。
- 同一產品、分類或文章的分頁或篩選檢視若無法以重新導向合併，仍需指定一個標準化目標。
- www 與非 www 的主機變體、http 與 https 的通訊協定變體可各自帶有一個指向所選形式的標準化標籤，但長期而言以重新導向作為處理方式更為乾淨。
- AMP 或其他與標準化桌面版頁面共享主要內容的替代呈現層，應將桌面版網址宣告為標準化網址。
- 在首選頁面本身加上自我指向的標準化標籤被廣泛建議，因為即使沒有重複頁面存在時，它仍能強化訊號。
若重複頁面根本不應再被提供，請改用 301 重新導向。標準化標籤不會立即將網址從搜尋結果中移除，也不會重新導向使用者，因此對已停用的頁面而言是錯誤的工具。
rel="canonical" 連結元素的結構解析
此元素具有固定的結構。必要的部分為 rel="canonical" 以及包含絕對首選網址的 href 屬性：
<link rel="canonical" href="https://example.com/preferred-page/" />
在您手動撰寫或貼上此元素時，有三項規則最為重要。該元素應置於 HTML head 內，而非 body。href 必須為絕對路徑，包含通訊協定與主機，因為像 /products/widget 這類相對路徑的意義會隨著文件內容而改變，且不被產生器接受。href 必須指向一個回傳 200 狀態且具有等效主要內容的頁面；若指向 404、軟性 404 或不相關的頁面，會使訊號混淆，並削弱網站上其他所有標準化標籤的效果。
href 內的 & 符號會以 & 撰寫，使屬性保持有效的 HTML。顯示的網址保留一般 & 字元；此差異屬於預期行為，且所請求的資源並未改變。
逐步建立標籤
使用瀏覽器端工具產生並部署標準化標籤時，請依下列步驟進行。
- 在輸入欄位中輸入完整的首選網址，包括通訊協定（http 或 https）、主機、路徑，以及任何屬於刻意選擇之標準化網址一部分的查詢字串。請省略片段（fragment），因為它們會在解析過程中被移除。
- 產生標籤並檢視工具回傳的標準化網址。將其逐字元與您希望搜尋引擎優先收錄的實際 200 頁面進行比對，特別留意主機大小寫、預設連接埠，以及任何 Unicode 轉 ASCII 的網域轉換。
- 從輸出區域複製產生的 <link rel="canonical" href="..."> 元素。
- 將其貼入主要內容與標準化目標相符之頁面的 <head> 中。對於重複頁面，此元素指明首選網址；對於首選頁面本身，此元素為自我指向，指向其自身網址。
- 於瀏覽器中檢視所提供的 HTML，或在實際運行的網址上檢查文件 head。確認恰好只有一個標準化元素、其 href 可解析至具有等效主要內容的 200 頁面，且各代表性路徑的頁面範本行為一致。
若您的 CMS 會自動注入標準化標籤，請先停用該功能或調整其輸出，再貼上您自己的元素，否則兩者會相互競爭並削弱訊號。
產生器套用的標準化規則
產生器透過瀏覽器的 URL 實作（即驅動網址列與 fetch 客戶端的同一套 WHATWG URL 標準）解析輸入。這些轉換是刻意設計的，而非憑空猜測。下表摘要說明哪些部分會變更、哪些保持不變。
| 輸入形式 | 產生器的輸出 | 原因 |
|---|---|---|
| https://Example.com/Page | https://example.com/Page | 依 URL 標準將主機轉為小寫；路徑大小寫則予以保留。 |
| https://example.com:443/page | https://example.com/page | HTTPS 的預設連接埠 443 會被移除。 |
| https://example.com:80/page | https://example.com/page | HTTP 的預設連接埠 80 會被移除。 |
| https://example.com/page#details | https://example.com/page | 片段識別的是資源內部的位置，而非獨立的網路物件。 |
| https://xn--fsqu00a.xn--0zwm56d/page | https://xn--fsqu00a.xn--0zwm56d/page | 國際化網域與非 ASCII 路徑會以 punycode 編碼為 ASCII 相容形式。 |
| https://example.com/page?utm=mail&ref=blog | 輸出中為相同網址，HTML 屬性中以 & 分隔參數 | 查詢字串會予以保留，因為其可能屬於刻意選擇的標準化網址一部分；& 符號會進行跳脫以維持有效的標記。 |
| /products/widget | 拒絕 | 相對路徑會被拒絕，因為其意義取決於文件所在位置。 |
| ftp://example.com/page | 拒絕 | 僅接受 HTTP 與 HTTPS；ftp、javascript、data 及其他通訊協定皆非有效的目標。 |
| https://user:[email protected]/page | 拒絕 | 內嵌於網址中的認證資訊會被拒絕，以維持標準化標籤的公開性。 |
如需各項規則的完整參考，標準化標籤產生器速查表詳細說明了該工具所依據測試的八個符合標準的測試案例。
產生器刻意不代為決定的項目
標準化標籤產生器無法讀取您的 CMS、路由表或內容。多項決策必須由您自行決定，因為猜測可能使標準化標籤指向錯誤的頁面，並在無聲無息中損害索引成效。
- 工具不會強制使用 HTTPS 也不會移除 HTTPS；若您的網站同時提供兩種通訊協定，則由重新導向層決定哪種形式為標準化形式。
- 工具不會新增或移除 www；主機標準化是全站性的決策，於邊緣節點或應用程式組態中處理。
- 工具不會強制執行結尾斜線政策；您輸入的路徑即為輸出的路徑。
- 工具不會移除追蹤參數；查詢字串會保持您撰寫的原始形式，以確保像 ?product=red 這類刻意的標準化網址得以原貌保留。
- 工具不會解析重新導向；若您輸入的網址會 301 至其他位置，則標準化標籤會指向輸入的網址，而非目的地。
- 工具不會比較頁面相似度；它無法判斷兩個頁面是否真的重複，僅能對您提供的網址進行標準化。
將這些決策保留在您的重新導向對應表、網站地圖與內容稽核中，以使標準化標籤與其他所有項目保持一致。
貼上後驗證實際運行的頁面
產生標籤僅完成一半工作。另一半在於確認實際運行的頁面帶有預期的訊號，因為一個與其他標準化標籤、HTTP 標頭中的標準化標籤或網站地圖項目相衝突的標準化標籤，會同時削弱全部三項訊號。
- 於實際運行的網址上檢視原始碼，確認 head 中僅出現一個 <link rel="canonical" ...> 元素。
- 檢查 HTTP 回應，確認沒有其他指向不同 href 的競爭性 Link: <...>; rel="canonical" 標頭。
- 將標準化 href 與您的網站地圖及主要內部連結進行交叉比對；三者應對首選網址達成一致。
- 抽樣檢查若干代表性範本，例如產品、分類、文章及分頁彙總頁面，因為單一頁面成功並不能證明每個產生的頁面皆正確。
- 在任何涉及 head 範本的 CMS、佈景主題或架構升級後，重新執行檢查。
根據Google 的標準化文件所述，標準化是一項強烈訊號而非指令，因此每項訊號指向同一個網址的一致性越高，該網址被選定的可靠性也越高。
如需更深入的說明，請參閱初學者 meta 標籤產生器：白話英文指南。