標準標籤產生器 (canonical tag generator) 會將一個偏好的絕對 HTTP 或 HTTPS 網址轉換成一個 HTML 跳脫後的 link 元素，讓你貼到頁面的 head 中，告訴它們哪個位址代表該內容的原始版本。輸出格式永遠一致：一行標記，包含 link rel="canonical"，其 href 指向你輸入的網址，並經過瀏覽器的 URL parser 進行標準化。它不會修改你的 CMS、不會把網址傳送到任何地方，也不會決定你應該將哪個頁面設為標準版本——這些決策仍由你掌控。它能可靠地產生符合標準的標記，讓你不再為了屬性語法、`&` 的跳脫方式，以及主機大小寫而猶豫不決。
在貼上任何內容之前，請先花一分鐘確認你真正想作為偏好的網址是什麼。重複或近似重複的頁面通常源自於追蹤參數、排序順序、多面向導覽、行動版與桌面版路由，或是預備環境與正式環境。挑選你想讓搜尋系統排名並在站內連結的版本，然後輸入那個確切的位址。產生器不會替你選擇；如果你指向錯誤的頁面，你只會得到一個格式完美、卻指向錯誤頁面的標籤。
產生器會處理的事——以及留給你的事
少數幾條規則讓標準標籤在手工撰寫時意外地容易出錯。產生器會負責處理純機械性的部分，讓你能專注於需要做決策的部分。分工大致如下。
| 工作項目 | 由產生器處理 | 留給你決定 |
|---|---|---|
| 通訊協定驗證 | 是 — 僅接受 http 與 https | — |
| 主機大小寫 | 標準化為小寫 | — |
| 預設連接埠 | 移除 (http 為 80,https 為 443) | — |
| 國際化網域名稱 | 序列化為 ASCII 相容形式 | — |
| 片段識別碼移除 | 是 — 會移除 #section 識別碼 | — |
| HTML 中的 `&` 跳脫 | 是 — 屬性中 `&` 會變成 `&` | — |
| 移除追蹤參數 | — | 由你決定 |
| 強制使用 www 或非 www | — | 由你決定 |
| 強制尾端斜線政策 | — | 由你決定 |
| 強制使用 HTTPS | — | 由你決定 |
| 解析重新導向 | — | 由你決定 |
| 檢查內容相似度 | — | 由你決定 |
| 編輯你的範本檔案 | — | 由你決定 |
右側欄的項目更多。每一項都是依據你網站實際結構而定的路由與內容決策。如果工具替你猜測，它只會產生一個語法正確、卻指向錯誤頁面的標籤——這可能比缺少標籤更糟糕，因為錯誤的訊號更難除錯。至於底層機制，標準標籤產生器在每次執行時都會套用瀏覽器標準的解析與序列化。
輸入正確網址的實用技巧
三個習慣能在大多數標準化錯誤發生之前就先行預防。
首先，貼上的網址應與瀏覽器造訪正式上線頁面時在網址列看到的完全一致——包含通訊協定 (https://)、確切的主機、完整路徑，以及任何真正屬於該頁面的查詢字串。例如 /products/widget 這類相對路徑會遭到拒絕，因為同樣的字元會根據所在文件的不同而解析到不同的位置，所以產生器拒絕輸出語意不清的 href。在大多數伺服器上路徑大小寫是有意義的，產生器會保留原樣;如果 /Products 與 /products 在你的網站上是不同的資源，請選擇與你偏好的網址完全相符的那一個。
其次，請再次確認你沒有貼上帶有認證資訊的網址。任何類似 https://user:[email protected]/page 的形式都會被刻意拒絕。標準標籤代表的是一個公開位址;在 head 元素中嵌入使用者名稱或密碼，將使其暴露給每一位訪客以及每一個爬蟲。如果某個頁面需要驗證，真正的問題是它究竟是否應該被索引——這是另一個獨立決策，並非標準化所能解決。
第三，請決定查詢字串是否屬於標準網址的一部分，還是只是某次追蹤實驗的一部分。產生器會保留你的查詢字串，因為它無法得知你的意圖，所以如果你輸入 /products?sort=price,href 中就會保留 sort=price。如果你希望標準標籤忽略該參數，請在產生之前先將它從輸入中移除。關於大小寫、連接埠與片段的標準化規則整理在標準標籤產生器標準化規則速查表中，值得花幾分鐘快速讀過以處理特殊情況。
如何產生一個可正常運作的標準標籤
請依照三個嚴謹的步驟使用產生器，把輸出視為一個仍須驗證的候選結果。
- 輸入完整的偏好 HTTP 或 HTTPS 網址，包含正確的主機、路徑，以及任何刻意保留的查詢字串。
- 產生標籤，並將標準化後的網址與你想讓搜尋引擎偏好的真實 200 頁面進行比對。
- 將該元素複製到 HTML 的 head 中，然後檢視實際送出的頁面，確認只有一個一致的標準訊號。
第二個步驟是多數人最容易跳過的。將標準化後的網址大聲唸出來——主機是否如你所預期、路徑是否完全正確、查詢字串是否如你所想——這能抓出那些在複製貼上時會悄悄蔓延到每個重複使用該範本之頁面的錯字。
悄悄破壞標準標籤的常見錯誤
即使是一個跳脫處理完美的標籤，也可能因一些反覆出現的錯誤而功虧一簣。請將下列清單視為發布前的檢查表;每一項都曾是某個真實標準化錯誤的根源。
- 將重複頁面指向不同的目標。當三個近似重複的頁面各自帶有不同的標準標籤時，搜尋系統會看到三個互相競爭的訊號。所有重複頁面都應該指向同一個偏好的網址，而偏好的頁面本身也應帶有自我指向的標準標籤。
- 混合使用 HTML 與 HTTP 標頭的標準化網址，卻彼此不一致。head 中的 rel="canonical" 標籤若與 HTTP Link 標頭，或與 sitemap 中列出的網址不一致，根據Google Search Central 的標準化文件，會被視為互相衝突的證據。
- 將標準化指向非 200 的頁面。若目標回傳重新導向、404 或軟性 404，該訊號將會被忽略。href 必須解析到實際的內容。
- 將標籤放在 body 中。某些 CMS 範本或用戶端渲染框架會將標記插入奇怪的位置。放在 head 之外的標準元素不會被視為強烈訊號。
- 在標準標籤中保留了片段識別碼。許多人會貼上從頁內錨點複製來的網址。片段識別碼代表的是頁面內的位置，並非獨立的資源，系統會自動將其移除——但若你將原始網址貼到另一個下游工具，片段識別碼又會重新出現。
- 使用相對路徑或非 HTTP 通訊協定。相對路徑以及 ftp:、javascript:、data: 等通訊協定都不會被接受;產生一個 href 錯誤的標籤，還不如完全沒有標籤。
- 誤以為標準標籤會重新導向使用者或將重複頁面從索引中移除。兩者都不會。使用者仍會前往他們點擊的網址，而重複頁面若標準標籤被忽略，仍可能出現在搜尋結果中。當某個重複頁面不應再被提供時，請使用 301 重新導向。
- 以一個成功的頁面來證明範本沒問題。如果你的 CMS 是透過範本產生標準標籤，請測試多個路由族系。某個分支中的錯誤——例如某個變數遺失而輸出 /page 而非 /page/——可能不會在你剛好測試的那個頁面上顯現出來。
部署後驗證標準標籤
複製完標籤並不代表工作完成。請在瀏覽器中開啟實際的 URL，檢視原始碼，確認 head 中正好只有一個 link rel="canonical" 元素，且其 href 與你預期的一致。接著在瀏覽器中直接載入該 href，確認它回傳 200 回應，且主要內容與先前相同。一個簡單的 curl -I、標頭檢查工具或手動擷取，就能告訴你目標是否正確解析。
最後，請對多個路由進行稽核。一個成功的頁面只能證明一個頁面;標準化的問題經常隱藏在參數組合、行動版變體、分頁區段或 RSS 摘要中，單一檢查無法涵蓋這些情況。整個網站維持一致的標準訊號，才能將重複的網址整合為單一的排名位址——標準標籤本身只是提供該段標記。
標準標籤是最便宜的 SEO 修正手段之一，卻也是最容易在細節上出錯的項目之一。產生器會處理跳脫、主機大小寫、預設連接埠、國際化網域名稱以及片段移除，讓你不必每次貼上網址時都得重新回想 URL 解析規則。它無法替你做的決策——哪個網址是偏好版本、追蹤參數是否應納入標準標籤、是否保留 www 或強制使用 HTTPS、某個重複頁面應該重新導向還是僅僅標註——仍然屬於你。請將產生的標籤視為一個形狀正確的成品，將它指向正確的頁面，放入 head 中，並在實際的線上文件中驗證;這樣的組合能涵蓋絕大多數的標準化錯誤。
想進一步了解，請參閱Meta Tag Generator Explained: What It Builds and Why。