標準網址標籤（canonical tag）是一個置於頁面 <head> 中的 HTML <link rel="canonical" href="..."> 元素，用來告訴搜尋引擎哪一個絕對 URL 代表該內容的首選版本。你可以透過在瀏覽器型 標準網址標籤產生器 中輸入完整的首選 HTTP 或 HTTPS URL、複製正規化後的 link 元素，再貼到 HTML head 來產生標籤。產生器會使用瀏覽器的 URL 實作來解析你的輸入，拒絕不安全的協定與內嵌的認證資訊、移除片段識別碼、將主機名稱改為小寫、移除 HTTP 與 HTTPS 的預設連接埠、將國際化網域正規化為其 ASCII 形式、保留路徑大小寫與任何刻意保留的查詢字串，最後在將網址包進 rel=canonical link 元素之前，對 href 屬性進行 HTML 跳脫處理。整個流程都在你的瀏覽器中本機執行，因此你輸入的 URL 不會離開裝置。產生的結果是符合標準的標記，可直接貼入範本，無需再編輯，即可供搜尋引擎讀取。
標準網址標籤實際上做什麼
rel=canonical link 元素是你能發出最明確的訊號之一，用來表示哪個 URL 代表某段內容。根據 Google 的標準網址說明文件，搜尋引擎會將這個註解與其他訊號（例如轉址、sitemap 項目、內部連結以及頁面內容）一起使用，以在多個頁面包含相同內容時，決定哪個 URL 應該出現在搜尋結果中。
這個元素本身很短。產生器會產生類似這樣的標記：
<link rel="canonical" href="https://example.com/products/widget">
href 必須是絕對路徑，並包含協定與主機名稱。搜尋引擎將這個標籤視為強烈的偏好，而非絕對指令；它們仍會權衡網站中的其他訊號。這就是為什麼每個重複訊號的一致性比任何單一標籤更為重要。
何時適合使用標準網址標籤
標準網址標籤解決一個特定問題：整合重複或近乎重複的 URL 訊號。常見情況包括可透過多種篩選組合存取的產品頁面、可列印版本、由分析參數產生的 URL 變體，以及在同一個網域上被發布到多個路徑的內容。
標準網址標籤並非轉址。它不會將使用者導向其他頁面，也不會自行將 URL 從搜尋結果中移除。當某個重複頁面根本不該再被提供時，永久 301 轉址才是正確的機制。當兩個 URL 都仍然存在，而你希望搜尋引擎將其中一個視為資料來源時，標準網址標籤才是正確的選擇。
在自我參照的設定中，每個首選頁面也應該將自己宣告為標準網址。這是常見的建議模式，能在外部系統連結到非首選變體時消除歧義。所有重複版本都應該一致指向同一個目標，讓偏好意圖不容混淆。
逐步產生標準網址標籤
- 開啟標準網址標籤產生器，輸入完整的首選 URL，包括協定、主機、路徑以及你打算保留的任何查詢字串。
- 點擊產生，並將顯示的正規化 URL 與你想讓搜尋引擎偏好的實際 200 狀態頁面進行比對。
- 複製工具輸出的 rel=canonical link 元素。
- 將該元素貼到重複或近乎重複頁面的 HTML <head> 內，而不是 body 中。
- 在瀏覽器中載入發布後的頁面，檢查 head 以確認只有一個標準網址元素，且其 href 能解析到正確的頁面。
對於由 CMS 驅動的網站，請將相同的元素貼到用於產生重複路由的範本中，讓每個產生的頁面都帶有一致的註解。對於用戶端渲染的應用程式，請確保標準網址出現在原始輸出中，因為載入後改寫它的腳本可能會引入搜尋引擎無法察覺的不一致。
產生器遵循的正規化規則
產生器使用瀏覽器的 URL 解析器來序列化輸入，這代表下列規則會自動強制執行。了解這些規則可避免你在比對顯示的網址與 CMS 或分析工具時感到意外。
| 你輸入的內容 | 正規化後的 href 目標 | 原因 |
|---|---|---|
| EXAMPLE.com:443/page | https://example.com/page | 主機名稱改為小寫；移除預設的 HTTPS 連接埠。 |
| http://example.com:80/page | http://example.com/page | 移除預設的 HTTP 連接埠。 |
| example.com/path?a=1&b=2 | example.com/path?a=1&b=2 | 主機大小寫已正規化；保留查詢字串。 |
| https://xn--r8jz45g.jp/page | https://xn--r8jz45g.jp/page | 國際化網域已轉換為其 ASCII 相容形式。 |
| https://example.com/page#details | https://example.com/page | 片段識別碼會被移除；Google 不將含片段的 URL 視為標準網址目標。 |
| /products/widget | 拒絕 | 相對路徑的意義會隨文件位置而改變。 |
| ftp://example.com/file | 拒絕 | 只有 HTTP 與 HTTPS 協定是有效的標準網址目標。 |
| https://user:[email protected]/ | 拒絕 | 在公開的標準網址訊號中，內嵌的認證資訊不合適。 |
路徑大小寫是有意義的，產生器不會更動它，因此大寫的段落會保留大寫。查詢字串是刻意保留的，因為它們可能屬於刻意選擇的標準網址的一部分；工具不會悄悄移除它們。
一個細微但重要的細節：在 HTML 標記中，查詢字串內的 & 會被跳脫為 &，使該屬性合法，而顯示的正規化 URL 則使用一般的 &。兩種形式指向相同的網址，這個差異是預期中的。
標籤應放置在哪裡以及如何確認運作正常
複製的元素應放在 HTML <head> 內，而非 body 中。如果 CMS 外掛已經在寫入標準網址標籤，請先移除或覆寫該輸出，再貼上你自己的標籤，以避免發布的頁面帶有兩個相互衝突的元素。相同的注意事項也適用於 HTTP Link: <...>; rel="canonical" 標頭以及 sitemap 項目。若其中任何訊號與 HTML head 不一致，搜尋引擎必須做出選擇，而其選擇未必符合你的意圖。
部署後，請在上線的 URL 上檢視原始碼，而非預覽環境。確認只有一個預期的標準網址元素，且其 href 會回傳 HTTP 200 並對應等價的主要內容。然後在網站中抽樣檢查一組具代表性的路由，而非假設某一頁成功就代表所有範本都正確。
標準網址標籤無法做到的事
標準網址標籤並不會強制搜尋引擎使用你的 URL。它是一個強烈訊號，而非保證；搜尋系統會將它與轉址、sitemap、內部連結與內容證據結合起來。它不會將使用者重新導向、不會立即將 URL 從搜尋結果中移除，也不會在重複頁面應停止提供時取代移轉轉址。
它也不會驗證內容的存取權限。如果某個頁面需要登入，標準網址標籤並不會讓它變得公開，也無法解決存取控制問題。正確的問題應該是：這個頁面到底是否應被索引？若應該，又該由哪個公開 URL 代表？
產生器不會移除追蹤參數、排序查詢鍵、強制使用 HTTPS、加上或移除 www 前綴、選擇是否使用結尾斜線的策略、解析轉址，或衡量頁面相似度。這些決定取決於你網站的路由與內容，一個擅自猜測的工具可能會產生一個看似有效、卻指向錯誤頁面的標籤。請把決策權留在自己手中，僅將產生器用來產生乾淨、已跳脫且符合標準的標記。
針對 CMS 特定的部署方式，WordPress 標準網址標籤指南涵蓋了範本與外掛的細節；關於更廣泛的 head 中繼資料，中繼標籤指南則說明標準網址在標題、描述與 viewport 中的定位。產生器遵循的底層 URL 規則記載於 WHATWG URL 標準，這也是為什麼解析後的輸出行為符合瀏覽器預期的原因。