canonical 標籤產生器的替代方案，是一款能把偏好的絕對 HTTP 或 HTTPS 網址，轉成乾淨、經 HTML 跳脫的 rel="canonical" 連結元素，而且不會自作主張做路由猜測，也不會要求你上傳網站的工具。Canonical Tag Generator 正是扮演這個角色：它透過瀏覽器內建的 URL 實作來剖析網址、移除片段、拒絕相對路徑與不安全的協定，然後在把結果放入 link 元素之前先序列化。因為每個步驟都是客戶端依據標準邏輯執行，所以輸出會反映出與搜尋引擎爬蟲在請求該網址時所看到的相同主機大小寫、預設連接埠處理方式，以及 IDN 序列化。這種一致性，正是你在比較各家產生器時真正想看到的：是一個忠實反映規格的替代方案，而不是一個在漂亮的預覽背後隱藏著悄悄轉換的工具。本文的其餘部分將逐步說明正規化規則、會被拒絕的輸入，以及決定產生的標籤能否真正整合你的重複網址訊號的擺放位置決策。
許多人在先前工具悄悄改寫了他們的網址、導致與實際頁面不符之後，或者在 CMS 外掛開始產生與 HTTP 標頭或 sitemap 項目相衝突的標記之後，才會轉而尋找 canonical 標籤產生器的替代方案。解法不是更聰明的預設值，而是一個每一項轉換都有文件記載且可預測的產生器。
為何 canonical 標籤產生器的替代方案很重要
重複的網址是正常的。參數、階段作業、排序順序、分面導覽，以及內容聯合發布，都可能讓實際上是同一個資源產生多個網址。搜尋引擎需要一個提示，告訴它你偏好的網址是哪一個，而 rel="canonical" 連結元素就是最常見的傳達方式。風險在於，一個馬虎的產生器可能會發佈一個指向你沒預期之處的標籤，讓搜尋引擎把一個混亂的訊號與轉址、sitemap、內部連結混在一起，最後自行挑出一個贏家。
一個遵循 WHATWG URL Standard 以及 Google 公開整合重複網址指引的替代方案，能提供搜尋引擎真正能信任的成果。Canonical Tag Generator 是建立在瀏覽器的 URL 剖析器之上，因此它的正規化結果與爬蟲在線上實際看到的內容一致：主機小寫、不帶預設連接埠、國際化網域採用 ASCII 相容編碼，以及序列化後的查詢字串。
Canonical Tag Generator 所套用的正規化規則
當你把網址貼進輸入欄時，這個工具會對其執行一組小規模的轉換。理解這些規則，正是真正的替代方案與一個包裝過的文字方塊之間的差別。
| 輸入 | 輸出目標 | 原因 |
|---|---|---|
| https://Example.com/page#intro | https://example.com/page | 主機改為小寫並移除片段 |
| https://example.com:443/blog | https://example.com/blog | 移除預設的 HTTPS 連接埠 |
| http://example.com:80/page | http://example.com/page | 移除預設的 HTTP 連接埠 |
| https://例え.jp/path | https://xn--r8jz45g.jp/path | 國際化網域編碼為 ASCII 相容形式 |
| /products/widget | rejected | 相對路徑，意義取決於文件所在位置 |
| https://user:[email protected]/x | rejected | canonical 目標不允許帶有認證資訊 |
| ftp://example.com/file | rejected | 只有 HTTP 與 HTTPS 是有效的 canonical 協定 |
路徑的大小寫會被保留，因為大多數伺服器的路由是大小寫敏感的。查詢字串也會被保留，因為像 ?id=42 這類參數，很可能正是某個網址之所以是 canonical 形式的全部原因。至於追蹤參數、排序順序、www 與非 www、結尾斜線策略，以及是否強制 HTTPS，則刻意留給你自行決定，因為對其中任何一項做猜測，都可能讓發佈出來的標籤指向錯誤的頁面。
在 HTML 屬性內，& 符號會被跳脫為 &。顯示出來的正規化網址仍然會呈現一般的 & 符號，因為正規化是在 URL 字串本身完成，之後才為了放入屬性而進行 HTML 跳脫。這個差異是預期中的，並不會改變所請求的資源。
三步驟產生 canonical 標籤
Canonical Tag Generator 圍繞著三個刻意的動作所打造：貼上網址、與實際頁面比對、然後放入標記。整個流程說起來比實際操作還要久。
- 輸入完整的偏好 HTTP 或 HTTPS 網址，包含正確的主機、路徑，以及任何刻意的查詢字串。相對路徑與不安全的協定會在此階段被拒絕。
- 產生標籤，並把正規化後的網址與你希望搜尋引擎偏好的實際 200 頁面進行比對。如果顯示的網址與你在瀏覽器中造訪該頁面時所看到的不一致，請在貼上標記之前先修正輸入。
- 把該元素複製到 HTML 的 head 之中，然後檢查實際送出的頁面，確認只有一個一致的 canonical 訊號。確認 href 解析後是 200 回應，且沒有任何 HTTP 標頭或 sitemap 項目與新的標籤相矛盾。
輸入內容會留在你的瀏覽器中。不上傳、不經過代理、不記錄你打算 canonical 化的網址。當該頁面屬於尚未上線、需要登入，或其他私密情境時，這點格外重要。
產生器會拒絕的輸入及其原因
這個工具中的拒絕訊息並非裝飾，每一則都描述了一類搜尋引擎無法妥善處理的 canonical 目標。
- 相對路徑。/products/widget 在每個承載該頁面的文件中意義都不同。只有絕對網址才具有穩定的意義。
- 非 HTTP 協定。FTP、javascript 與 data URI 在搜尋引擎的語境中無法被 canonical 化。只有 http 與 https 描述的是可被公開索引的網路資源。
- 網址中帶有認證資訊。一個含有 user:[email protected] 的 canonical，會在 HTML 標記中洩漏祕密，並把錯誤的頁面標示為偏好頁面。如果一個頁面需要驗證，canonical 化並不能解決存取控制的問題。
在輸入階段就把這些錯誤擋下，是成本最低的修正點。一個悄悄改寫網址而不拒絕輸入的產生器，就是一個可能在你毫無警覺之下發佈錯誤 canonical 的產生器。
產生的標籤在頁面中應放在哪裡
這個元素應該放在 HTML 的 head 之中，而非 body 之中，而且位置應該在任何可能在執行階段重新排列文件 head 的腳本之前。對於客戶端渲染的應用程式，請把 canonical 直接放在伺服器端渲染的原始輸出中，讓爬蟲在任何 JavaScript 執行之前就能看到它。在載入之後變更 href 會引入那種搜尋引擎必須自行猜測的不一致性。
在偏好的頁面本體上，請使用自我指向的 canonical。所有重複的版本都應指向同一個目標。如果你同時也在發佈 X-Robots-Tag 標頭，或在 sitemap 中列出該網址，請保持它們一致。一個 canonical 在 HTML 中、另一個在 HTTP 標頭中、再一個在 sitemap 中，正是典型的訊號互相衝突模式。
如果你管理的是 WordPress 站台，想要一份針對 CMS 的逐步教學，那份關於如何在 WordPress 中建立 canonical 標籤的實務指南，涵蓋了這個產生器刻意留給你自己處理的主題與外掛層面。
Canonical 標籤與 301 轉址的比較
這兩種機制都能減少重複網址造成的混淆，但它們回答的是不同的問題。canonical 是說：把這個網址視為用於索引的偏好版本，即使重複的版本仍會被提供。301 轉址則是說：完全停止提供重複的版本，並把所有人導向偏好的網址。
| 機制 | 使用者行為 | 最佳適用情境 |
|---|---|---|
| rel="canonical" | 重複頁面仍然會載入 | 必須在多個網址下仍可存取的頁面，例如排序檢視、篩選條件、或聯合發布的副本 |
| 301 redirect | 重複頁面轉址到偏好網址 | 不應再被提供的頁面，例如舊路徑、已退役的分類，或網域遷移 |
對於不應再回傳任何內容的遷移情境，請優先使用轉址。對於必須繼續讓使用者使用的分面導覽或聯合發布副本，請優先使用本工具所產生的 canonical 標籤。兩者併用也沒有問題，只要 canonical 目標與轉址目的地一致即可。
更換產生器時常見的陷阱
在切換到基於標準的產生器之後，最常見的意外來自先前工具悄悄改寫過的輸入。
- 主機為大寫。先前的工具可能保留了 Example.com 在標記中。瀏覽器正規化後的目標會變成 example.com。這項改變是正確的，但現有的監控工具如果是記錄精確的 href 字串，可能會對它提出警示。
- 預設連接埠。來源中帶有 443 連接埠的網址，輸出時會變成沒有連接埠。爬蟲本來就會忽略預設連接埠，所以這項正規化是無害的。
- 片段。先前的預覽可能把 #section 顯示成 canonical 的一部分。新的輸出會將其移除，這與 Google 對於片段 canonical 的公開指引一致。
- 被跳脫的 & 符號。搜尋引擎能正確解析 &，但一些舊式的日誌解析器無法。請用你實際用來稽核 head 標籤的工具來驗證 href。
每次變更之後，請檢視實際送出的 HTML，或在真實網址上檢查文件的 head。確認只有一個預期中的 canonical 元素，且其 href 解析後是一個含有等價主要內容的 200 頁面。只檢查一個模板並不能代表所有路徑，因此請抽樣一組具代表性的頁面。
對於需要一次產生大量 canonical 標籤的團隊來說，一款能在瀏覽器中建立長串偏好網址清單的工具，可以與本產生器互補，而適用於編號網址模板的 Bulk URL Generator 替代方案涵蓋了那個相關的工作流程。