標準標籤生成器會將一個偏好的絕對 HTTP 或 HTTPS URL 轉換成單一 HTML 跳脫的 <link rel="canonical" href="..."> 元素，讓你貼到目標頁面的 head 中，以便搜尋引擎將該頁面視為主要版本。對初學者來說，這句話就是全部的工作內容：挑選你想被收錄的 URL，將輸入送進工具，複製產生的標籤，然後放到爬蟲看得到的地方。Canonical Tag Generator 會處理所有容易手動出錯的步驟，包括協定與主機驗證、片段移除、主機大小寫正規化、預設連接埠移除、國際化網域名稱編碼，以及查詢字串中的 & 符號跳脫，讓你拿到的是符合標準的程式碼片段，而非憑感覺亂寫。需要注意的一點是，這個工具只會格式化你給它的內容；當你的網站以多個路徑（有無 www、是否帶有追蹤參數）提供相同內容時，它無法決定哪個 URL 應該勝出。閱讀本指南的其餘部分，你將了解驗證規則、正規化行為，以及一套能在最常見的初學者錯誤進入正式環境前就抓出來的檢查流程。
標準標籤生成器實際上做了什麼
生成器的工作範圍很窄且定義明確。你手它一個絕對 URL，它就回傳一行可直接放入 head 的標記，把該 URL 指定為標準目標。就這樣而已。這個工具不會爬取你的網站、不會在 www 與非 www 之間做選擇、不會強制使用 HTTPS、不會移除追蹤參數、不會解析重新導向，也不會檢查兩個頁面是否真的相似。這些決定必須由你來做，因為它們取決於你的 CMS、路由規則與內容策略的運作方式，而一個會自行猜測的生成器，很可能會產生出語法正確、卻指向錯誤頁面的標籤。
這個工具完全在瀏覽器中執行，因此你輸入的 URL 會留在你的裝置上，不會被送到伺服器。回傳的內容也僅有標記，這代表生成器無法編輯 CMS 範本，也無法驗證 JavaScript 框架最終是如何渲染文件的。你仍然需要將標籤貼到你的範本中，並確認爬蟲實際收到的內容。
標準標籤是一種訊號，而非指令。搜尋引擎會將「在偏好頁面上使用一致且指向自身的標準標籤」，搭配「站名檔、重新導向與內部連結中的對應項目」，視為強烈的證據。該標籤本身在 Google 的整合指引中被記錄為一種強烈的標準化訊號，但內容品質、重新導向、站名檔項目與內部連結，仍會影響搜尋系統最終選擇哪個 URL。將它視為眾多訊號中的其中一票。
初學者常踩雷的 URL 規則
生成器對輸入很嚴格，這對初學者來說其實是好消息，因為它能在第一時間告訴你哪裡出了問題。以下是必須牢記的規則。
URL 必須是絕對路徑。像 /products/widget 這類相對路徑會被拒絕，因為其意義會隨所出現的文件與部署環境而改變。請務必包含協定與主機。
只接受 HTTP 與 HTTPS。像 ftp:、javascript: 與 data: 這類協定並非有效的標準標的，工具會拒絕它們。
URL 中的認證資訊會被拒絕。標準標籤代表的是一個公開的內容位置，將 user:pass@host 嵌入標記中會洩漏使用者名稱與密碼。如果一個頁面需要登入才能存取，標準化並不會讓它變得公開。請重新檢視這個頁面是否真的應該被收錄，而不是嘗試為它加上標準標籤。
片段（fragment）會被移除。輸入 https://example.com/page#details 會產生 https://example.com/page 的標的。Google 的說明文件基本上不支援以片段 URL 作為標準標的，因為片段代表的是一個表示內部的位置，而非一個獨立的網路資源。
查詢字串會被保留。它們可能是刻意選定的標準網址的一部分，而工具無法得知哪些參數是有意保留的。不要讓生成器替你移除追蹤參數。
以下是一份快速的對照表，說明生成器接受與拒絕的內容。
| 輸入形式 | 是否接受？ | 原因 |
|---|---|---|
| https://example.com/page | 是 | 絕對的 HTTP/HTTPS URL |
| http://example.com:80/page | 是 | 正規化時移除預設 HTTP 連接埠 |
| https://EXAMPLE.com/Page | 是 | 主機轉為小寫，路徑大小寫保留 |
| https://example.com/page?id=1&ref;=home | 是 | 標籤中的 & 符號會做 HTML 跳脫，查詢字串保留 |
| https://xn--bcher-kva.example/kindle | 是 | 國際化網域名稱編碼為 ASCII 相容形式 |
| /products/widget | 否 | 相對路徑，意義依情境而定 |
| ftp://example.com/page | 否 | 不支援的協定 |
| https://user:[email protected]/ | 否 | URL 中嵌入認證資訊 |
| https://example.com/page#section | 接受，但片段會被移除 | 標的變為 https://example.com/page |
產生、比對並複製標籤
這是初學者在理解上述規則後會執行的例行步驟。
- 輸入完整的偏好 HTTP 或 HTTPS URL，包含正確的協定、主機、路徑，以及任何刻意保留的查詢字串。
- 產生標籤並閱讀工具顯示的正規化 URL。將它與你希望搜尋引擎偏好的真實 200 頁面，逐字元比對協定、主機、路徑與查詢字串。
- 複製產生的元素。它的形式為 <link rel="canonical" href="...">，查詢字串中的 & 符號會跳脫為 &，以確保屬性為有效的 HTML。
- 將該元素貼到每一個應該解析到同一偏好 URL 的重複或近似重複頁面的 HTML head 中。請將標籤放在 head，而非 body。
- 在瀏覽器中開啟已部署的頁面，檢視原始碼，確認正好只有一個 canonical 元素，且 href 與你預期的一致。請抽樣檢查多個代表性路由的範本，而非僅憑一個成功頁面就假設所有產生的頁面都沒問題。
如果你特別需要一套針對 WordPress 的初學者導向工作流程，How to Create a Canonical Tag in WordPress: A Practical Guide 會帶你走過佈景主題檔頭、SEO 外掛與區塊編輯器的標籤放置位置，使用的就是同一個生成器的輸出。
輸出中的正規化結果長什麼樣子
初學者通常會在輸出上被三件事絆倒：顯示的正規化 URL 看起來與你輸入的不同、href 顯示的是 & 而非 &，或是主機呈現的格式與你寫的不同。這些都不是錯誤。以下是工具實際會做的事，以及這樣做的原因。
瀏覽器的 URL 實作會依據 WHATWG URL 標準來序列化你的輸入。大寫的主機（例如 EXAMPLE.com）會變成 example.com，HTTPS（連接埠 443）與 HTTP（連接埠 80）的預設連接埠會被移除，而像 bücher.example 這類國際化網域會被轉換為其 ASCII 相容的 Punycode 形式（xn--bcher-kva.example）。路徑的大小寫是有意義的，因此會保持原樣，所以即便主機變成小寫，/Products 仍然是 /Products。
片段（如果存在）會在建構 href 之前被移除，因為 Google 的說明文件基本上不支援以片段 URL 作為標準標的。片段代表的是一個表示內部的位置，而非一個獨立的網路資源。
查詢字串會依照輸入原樣保留，但其中的每一個 & 符號在 href 渲染時都會跳脫為 &。「顯示的正規化 URL」與「HTML 屬性」之間的這個差異是預期的，並不會改變所請求的 URL。瀏覽器與爬蟲在讀取屬性時，會將 & 解析回 &。
以下是一個具代表性的對應表。
| 輸入範例 | 標籤中的正規化 href | 變更內容 |
|---|---|---|
| https://EXAMPLE.com:443/Page | https://example.com/Page | 主機轉為小寫，預設連接埠移除，路徑大小寫保留 |
| http://example.com:80/category?id=2&ref;=home | http://example.com/category?id=2&ref=home | 預設連接埠移除，& 符號跳脫 |
| https://bücher.example/kindle#reviews | https://xn--bcher-kva.example/kindle | 國際化網域名稱編碼，片段移除 |
| https://example.com/page?utm_source=mail | https://example.com/page?utm_source=mail | 未變更，查詢字串刻意保留 |
悄悄破壞標準化的初學者錯誤
大多數初學者在標準化上犯的錯，都屬於少數幾種模式。事先認出它們，能省下之後除錯的時間。
訊號互相衝突。HTML 中有一個標準標籤、HTTP Link 標頭中是不同的標準標籤，站名檔裡又是另一個 URL。搜尋引擎仍會嘗試做出選擇，但結果更難預測。一致性會讓偏好更為明確。
標籤放在 body 中。有些佈景主題與頁面編輯器允許你將元素放到內容區。爬蟲只會在 head 中尋找標準標籤，放錯位置的標籤可能會被完全忽略。
缺少指向自身的標準標籤。偏好的頁面應該指向自己。少了它，重複頁面所指向的標的就不會再指回任何東西，訊號強度會因此減弱。
將追蹤參數視為標準網址。utm_source 這類參數並不會改變頁面內容，但會改變 URL。如果你把追蹤 URL 設為標準，就是在告訴搜尋引擎去收錄那個追蹤版本。請將標準標籤保留在穩定的內容 URL 上。
用標準標籤取代重新導向。標準標籤不會把使用者重新導向、不會立刻從搜尋結果中移除 URL，也無法取代遷移時的重新導向。對於不應再提供服務的 URL，請使用永久重新導向，並讓重要的內部連結指向同一個偏好網址。
用戶端渲染造成的覆寫。對於以 JavaScript 為主的網站，在載入後重寫 head 的腳本可能會替換或移除標準標籤。請確認該標籤存在於伺服器端渲染的輸出中，並且用戶端程式碼不會不一致地修改它。
假設可以略過身分驗證。如果頁面位於登入機制之後，加標準標籤並不會讓它變得公開。標準化無法解決存取控制的問題。在加上標籤之前，請先決定這個頁面是否應該被收錄。
貼上標籤到 head 區段之後
標準連結（canonical）標籤只有在頁面爬蟲抓取後才會發揮作用。最後一步是驗證，這一步是值得的。
在實際部署的網址上檢視原始碼。確認 head 區段中只有一個 <link rel="canonical" ...> 元素，且 href 為您預期的網址。
解析 href。將標準連結目標貼到瀏覽器，或使用 HTTP 狀態檢查工具，確認回應為 200。若指向 404 或重新導向鏈，會削弱訊號強度。
比對主要內容。標準連結目標的主要內容應與重複頁面相同。若兩個頁面內容出現分歧，該訊號將更難以維持其效力。
抽樣檢查範本。若您是透過 CMS 範本新增標籤，請檢查多個具代表性的路徑範例，包括首頁、分類頁、產品頁和部落格文章，而非假設範本變更已套用至所有頁面。
若想了解搜尋引擎如何整合重複網址的底層指引，Google Search Central 標準連結說明文件詳細說明了訊號層級。一旦標準連結元素就位，搭配一致的內部連結、對應的網站地圖項目，以及相符的重新導向，就能構成完整的設定。
如需更深入的說明，請參閱Hreflang 產生器入門指南：逐步帶您第一次操作。