規範標籤產生器 (canonical tag generator) 會將一個絕對的 HTTP 或 HTTPS URL 轉換成單一的 HTML 跳脫後 <link rel="canonical" href="..."> 元素,讓搜尋引擎將其視為關於哪個網址是該頁面首選版本的強烈提示。關鍵字「canonical tag generator explained」背後的讀者任務很直接:貼上你希望搜尋引擎優先採用的 URL,取回一個乾淨、有效的 link 元素,然後放進頁面的 head 中。本文所介紹的產生器不需要任何伺服器呼叫即可完成這項工作。輸入內容會由瀏覽器內建的 URL 實作進行解析,僅限於不含認證資訊的 HTTP 或 HTTPS,移除所有片段 (fragment),接著在 href 進行 HTML 屬性跳脫之前序列化為規範形式。其輸出結果是標記 (markup),而非指令。根據 Google 的 canonicalization 說明文件,搜尋系統會將這個標註視為強烈訊號,但內容品質、轉址、sitemap 項目、內部連結以及其他訊號,仍然會影響搜尋引擎最終選擇的 URL。本文將逐步說明輸入內容、正規化規則、產生與放置標籤的三個步驟、會改變工具接受範圍的限制,以及確認所交付頁面只帶有一個一致 canonical 訊號的驗證步驟。

像這樣的產生器,其輸出刻意設計得很窄。它不會在候選頁面之間做選擇、不會比較內容相似度,也不會猜測尾端斜線政策。它不會呼叫伺服器、不會儲存 URL,也不會把網址交給第三方。整個操作完全在本機瀏覽器中執行,這也是為什麼這個工具只能驗證它看得到的 URL 組成部分:通訊協定、主機、連接埠、路徑、查詢字串與片段。其他部分——哪個 URL 才是「正確」的 canonical、是否存在重複、網站如何路由——都必須在你打開工具之前就先決定好。

canonical tag generator explained
Canonical Tag Generator Explained: How It Works

規範標籤產生器實際上在做什麼

規範標籤產生器接收一個 URL,回傳一個 HTML 元素。它不會進行爬取、不會與線上頁面比對、也不會在相似的網址之間做選擇。這個工具的角色比它協助解決的問題更為限縮:它產生的是一個語法正確的 link 標籤,指向你已選定為首選的網址。搜尋引擎在嘗試決定要索引哪一個版本的頁面時,所讀取的就是這個單獨的產物。

本文所介紹的產生器完全在瀏覽器中執行。輸入的 URL 會由符合 WHATWG 規範的瀏覽器 URL 解析器進行解析,僅限於 HTTP 或 HTTPS,移除所有片段,接著重新序列化為其規範形式。主機名稱會轉為小寫、預設連接埠會被移除、國際化域名會被轉換為其 ASCII 相容 (punycode) 形式。路徑的大小寫則保持區分。在 href 進行 HTML 屬性跳脫時——最重要的是,查詢字串中的 & 會變成 &amp; 以確保屬性是有效的標記,而顯示的正規化 URL 則保留一般的 & 字元。這個差異是預期的,並不會改變所請求的 URL。

最終的標記看起來就像一個普通的 HTML link 元素——rel="canonical" 搭配一個指向正規化網址的 href。搜尋引擎會看到 rel 的值、讀取 href,並將其視為該元素所在頁面的一個強烈 canonicalization 訊號。

URL 如何被正規化

正規化是讓瀏覽器型產生器不同於單純封裝工具的核心。WHATWG URL 標準——也就是你在輸入網址時每個現代瀏覽器所使用的同一份規範——在 href 寫入標記之前,會自動套用若干規則。

  • 主機名稱會轉為小寫,因此 WWW.Example.com 會被正規化為 www.example.com。
  • 預設連接埠會被移除:HTTP URL 中的連接埠 80 會消失,HTTPS URL 中的連接埠 443 也會消失。
  • 國際化域名會被轉換為其 punycode 形式,因此像 https://münchen.de/ 這樣的輸入會變成 https://xn--mnchen-3ya.de/。
  • 片段會被移除,因為 Google 的說明文件基本上不支援以片段 URL 作為 canonical 目標。片段是用來識別某個表示內部的位置,而不是一個獨立的網路資源。
  • 路徑的大小寫會被保留,因為在大多數伺服器上路徑是區分大小寫的。
  • 查詢字串會被保留,因為它可能是被刻意選擇之 canonical 網址的一部分。

下表顯示了常見的輸入在被寫入 href 之前是如何被轉換的。工具所顯示的正規化形式即為工具顯示的內容;實際的 href 屬性中,& 會被跳脫為 &amp; 以確保 HTML 有效。

輸入寫入 href 的正規化目標
https://example.com:443/Pathhttps://example.com/Path
https://Example.COM/https://example.com/
https://example.com/page#sectionhttps://example.com/page
https://münchen.de/https://xn--mnchen-3ya.de/
https://example.com/Pathhttps://example.com/Path (保留大小寫)
https://example.com/page?a=1&amp;b=2https://example.com/page?a=1&amp;b=2 (保留查詢字串;標記中為 &amp;amp;)

如需更深入的正規化參考,Canonical Tag Generator Cheat Sheet 以 fixture 等級的範例逐一說明每條規則。

用三個步驟產生 rel=canonical 標籤

使用 Canonical Tag Generator 的端對端工作流程刻意設計得很短。三個步驟就涵蓋了從 URL 選擇到驗證 head 標籤的完整路徑。

  1. 輸入完整的首選 URL。將完整的 HTTP 或 HTTPS 網址輸入到欄位中——包含通訊協定、主機、路徑,以及任何刻意保留的查詢字串。部分 URL 或相對路徑會被拒絕,因為其意義會隨著文件位置與部署環境而改變。如果該頁面需要查詢字串來識別正確的版本,請將其保留。
  2. 產生標籤並比較正規化後的輸出。按下「產生」之後,請閱讀工具所顯示的正規化 URL,並將其與你希望搜尋引擎優先採用的實際 200 頁面進行比較。這正是抓出主機拼字錯誤、不想要的多餘連接埠、不慎包含的片段,或遺漏的尾端斜線的時機——這些情況中的任何一項,都會讓 canonical 指向與你預期不同的資源。
  3. 將元素複製到 HTML head 中,並檢查實際交付的頁面。將 link 元素貼到應承載 canonical 之頁面的 head 內,接著在瀏覽器中載入該頁面,並透過檢視原始碼或使用文件檢查器來確認。確認恰好只有一個 canonical 元素,且其 href 能解析為一個含有等效主要內容的 200 頁面。如果某個模板會為同一頁面產生多個版本,請逐一檢查每個具代表性的路由。

輸入規則與工具會拒絕的內容

這個產生器的輸入規則比看起來更嚴格,而這些拒絕是刻意的。canonical 元素應該用來識別一個公開的內容位置,因此該工具會拒絕任何會讓 href 變得模糊、不安全,或未經認證的輸入。

  • 像 /products/widget 這樣的相對路徑會被拒絕,因為其意義會隨著文件 URL 與部署環境而改變。
  • 非 HTTP 的通訊協定(例如 ftp、javascript、data)不是有效的 canonical 目標。
  • URL 中所包含的認證資訊——任何 https://user:[email protected]/ 形式的內容——都會被拒絕。canonical 不應在標記中洩漏使用者名稱或密碼,且 canonicalization 也無法解決存取控制問題。
  • 片段會在輸入時被移除,因為 Google 基本上不支援以片段 URL 作為 canonical 目標。

下方的比較表摘要說明了產生器接受與拒絕的內容。

輸入形式是否接受原因
https://example.com/page是絕對 HTTPS,無認證資訊
http://example.com/page是允許絕對 HTTP
https://example.com/page?ref=email是保留查詢字串
/products/widget否相對路徑會被拒絕
ftp://example.com/file否不允許的通訊協定
https://user:[email protected]/否認證資訊會被拒絕
https://example.com/page#details移除片段不支援片段

有一個重要的結果:這個產生器不會移除追蹤參數、不會排序查詢參數、不會強制 HTTPS、不會新增或移除 www、不會選擇尾端斜線政策、不會解析轉址,也不會檢查頁面相似度。這些決定取決於網站的路由與內容,而自動猜測它們,可能會產生一個看起來有效、卻指向錯誤頁面的標記。八個符合標準的 fixture 涵蓋了根斜線插入、主機正規化、路徑大小寫保留、HTTP 與 HTTPS 預設連接埠、片段移除、Unicode 路徑、國際化域名與查詢字串,並有獨立的測試來斷言精確的 HTML 跳脫,以及拒絕相對、不安全通訊協定與含有認證資訊的目標。

標籤應放置的位置與如何驗證

canonical 元素應該放在 HTML head 內,而不是 body 中。對於用戶端渲染 (client-rendered) 的應用程式,canonical 必須在文件的原始輸出中可見——在頁面載入後才由 JavaScript 注入的標籤,對爬蟲來說較難可靠地發現。這個產生器只會回傳標記;它無法編輯 CMS 模板,也無法驗證框架如何渲染最終文件,因此最終的檢查必須在實際交付的頁面上進行。

幾個驗證習慣可以抓出大多數的錯誤:

  • 開啟實際交付的頁面並檢視原始碼。確認恰好只有一個 rel="canonical" 的 link 元素,並讀取其 href。
  • 在新的分頁中載入該 href。確認它回傳 HTTP 200,且顯示相同的主要內容。
  • 檢查各個具代表性路由的模板,而不只是某個成功的頁面。在首頁上能正常運作的模板,可能會在分頁或篩選路由上渲染出多個 canonical。
  • 將 HTML 中的 canonical 與 sitemap 項目,以及同一 URL 的任何 X-Robots-Tag HTTP 標頭進行比對。同一頁面出現三個不同的 canonical 目標,是這種訊號失效最常見的原因之一。

在首選頁面上設定自我指涉 (self-referential) 的 canonical 是普遍受到推薦的做法。重複的版本應一致地指向同一個目標。一致性會讓偏好更明確;相互衝突的訊號則會削弱它。

關於標準化訊號的常見誤解

有幾個常見的期待值得直接釐清。標準化標籤（canonical tag）有助於整合重複的 URL 訊號；它們不會重新導向使用者、不會立即將某個 URL 從搜尋結果中移除，也不會取代移轉時的重新導向。如果某個重複頁面不應該再被提供，正確的工具是永久重新導向，並將標準化標籤作為輔助，而非替代品。

標準化標籤也不是萬靈丹。根據 Google 的說明文件，這個註記只是一個強烈的訊號，並非指令。搜尋系統在選擇 URL 時，會將標準化標籤與重新導向、sitemap、內部連結以及內容證據一併考量。一個指向內容薄弱或自相矛盾頁面的乾淨標準化標籤，無法勝過一個結構完善且連結強勁的競爭對手網址。

最後，這個產生器並無法解決存取控制問題。如果某個頁面需要驗證，將其標記為標準化並不會讓它變得公開。一個需要驗證的頁面，首要問題在於它是否應該被索引——而不是如何將其標準化。

延伸閱讀：Canonical Tag Generator for Beginners: A Safe First Run。