標準標籤應根據一個經過審慎選擇的絕對 HTTP 或 HTTPS URL 產生，然後在放入 HTML head 之前，與線上頁面及網站的其他標準化訊號進行比對。在比較使用 Canonical Tag Generator 產生標準標籤的 various 方法時，應將 3 項決策分開處理：偏好哪個 URL、標準化訊號應放在哪裡，以及最終頁面該如何驗證。產生器會處理 URL 解析、瀏覽器式正規化、片段移除與 HTML 跳脫，但只會傳回標記；它不會發布標籤、編輯 CMS、解析重新導向，也不會判斷哪個頁面具有最強的內容。手動撰寫的標記、CMS 欄位、HTTP 回應標頭與網站地圖都能參與標準化，但各自解決問題的不同部分，而且當其偏好 URL 不同時，可能彼此矛盾。因此，最安全的工作流程應以比較為主，而非完全自動：定義 URL 政策、從選定的目標產生乾淨的元素、將其置於 head，並確認傳送的文件只公開一個一致的標準化 URL，且該 URL 會解析至真正回傳 200 的頁面，並提供等效的主要內容。

how do i compare approaches to generate canonical tag when using canonical tag generator
如何比較標準標籤產生方式

比較標準化偏好應放在哪裡

比較應先從標準化偏好所在的位置開始。HTML 中的標籤、HTTP 回應標頭中的標準化 URL，以及 XML 網站地圖中的 URL 都是彼此相關的訊號，但工作並不相同。Canonical Tag Generator 只會建立 HTML link 元素；它不會寫入標頭、更新網站地圖或變更 CMS 範本。這項限制使其輸出適合用於受控的工作流程，因為您可以在決定部署位置之前，先檢查確切的標記。

方法 最適合的用途 主要比較重點
產生的 HTML link 元素 靜態頁面或由範本管理的網站 可產生可供審查的標準化標記，但擺放位置與傳送頁面檢查仍須由您負責。
手寫的 HTML 元素 受控的單一頁面或小型範本 可以產生相同的 link 元素，但必須手動處理 URL 正規化與 HTML 跳脫。
CMS 或佈景主題欄位 具有可重複套用頁面 head 規則的網站 支援廣泛的範本控制，但產生的標籤仍須在算繪後插入並檢查。
HTTP 回應標頭 不適合使用 HTML head 的環境 提供回應層級的標準化訊號，但必須與任何 HTML 標準化 URL 一致。
XML 網站地圖 全站探索偏好 URL 支援探索與整合，但無法取代頁面層級的標準化標註。

當團隊希望在部署前審查確切元素時，產生的 HTML 通常是最清楚的選項。手動標記可提供相同的最終結構，但會將正規化與跳脫的責任交給作者。CMS 欄位可以讓許多路徑的實作更容易，但產生器無法確認 CMS 最終算繪的內容。標頭與網站地圖訊號最好視為圍繞相同偏好 URL 的輔助證據，而不是可用來選擇不同目的地的獨立方式。根據 Google Search Central 的標準化文件，標準化標註是一項強烈訊號，而非無條件命令；重新導向、網站地圖項目、內部連結與內容證據仍可能影響最終選擇。

決定產生的標籤應以哪個 URL 為目標

在比較兩個產生的標籤之前，應先決定哪個地址代表網站自身路由規則下的偏好內容位置。產生器刻意避免猜測屬於網站擁有者的政策。它不會選擇 HTTPS、新增或移除 www、強制使用尾端斜線格式、移除追蹤參數，也不會排序查詢參數鍵值。這些選擇可能會改變標籤所識別的資源，因此每項都應納入產生前的 URL 政策審查。

URL 元件 產生器的處理方式 產生前必須做出的決策
通訊協定 接受 HTTP 或 HTTPS，並保留輸入的通訊協定。 選擇已核准用於偏好頁面的通訊協定。
主機大小寫與預設連接埠 將主機轉為小寫，並移除預設的 HTTP 或 HTTPS 連接埠。 檢查輸出中正規化後的主機與連接埠。
www 與裸網域 維持主機形式不變。 選擇偏好內容位置所使用的主機。
路徑大小寫 保留路徑中的大小寫。 使用確切路由，因為路徑大小寫仍然具有意義。
尾端斜線 不會新增或移除斜線。 遵循網站既定的路由政策。
查詢字串 保留參數及其順序；不會移除追蹤參數。 僅納入刻意屬於標準化地址的參數。
片段 從標準化目標中移除片段。 以底層資源為目標，而非其內部的某個位置。
相對 URL 予以拒絕，因為其意義取決於文件位置。 提供完整的絕對 HTTP 或 HTTPS URL。
不支援的通訊協定或內嵌認證資訊 拒絕 FTP、javascript、data、其他通訊協定，以及含有認證資訊的 URL。 使用預期內容位置的公開 URL。

正規化方式遵循 WHATWG URL Standard 所記載的瀏覽器 URL 模型。國際化網域與非 ASCII 路徑會經序列化處理，而路徑大小寫維持不變。片段會被移除，因為它所識別的是某個表示形式內部的位置，而非獨立的網路資源；例如，https://example.com/page#details 會產生 https://example.com/page 作為目標。查詢字串仍是所選地址的一部分，因為它們可能用來區分刻意建立的內容。當有多個查詢參數時，產生的 HTML 屬性原始碼會在參數之間使用 &，顯示的正規化 URL 則保留一般 & 字元。這種跳脫方式可維持屬性有效，同時不改變所要求的目標。

產生標籤並與目的地比較

產生器是可供審查的標記步驟，而非自動部署步驟。輸入內容會留在瀏覽器中，而結果則是具有標準化關係的 link 元素，其 href 包含所選 URL。

  1. 輸入完整的偏好 URL。 請包含 HTTP 或 HTTPS 通訊協定、正確的主機、預期路徑，以及屬於所選資源的任何查詢字串。不接受像 /products/widget 這樣的相對路徑，因為其意義會隨文件位置與部署環境而改變。
  2. 產生標籤並審查正規化地址。 檢查輸出中的主機、連接埠、路徑、尾端斜線與查詢參數。確認已移除的片段原本並未承載有意義的差異，且跳脫後的標記仍能呈現預期的查詢字串。
  3. 將正規化 URL 與真正的目的地比較。 開啟偏好頁面，並確認其回傳 200 回應。目標應識別您希望搜尋引擎優先採用的頁面，且該頁面具有等效的主要內容，而不是找不到的頁面、受存取控制的資源或不同的路由。產生器不會解析重新導向，也不會檢查內容相似度。
  4. 將確切元素複製到 HTML head。 請勿將其置於 body。部署後，請檢查傳送的文件，並確認其中出現 1 個預期的標準化元素，其 href 會解析至已驗證、回傳 200 的頁面。

產生的標註只會識別偏好；它不保證被選取、不會重新導向訪客、不會立即從搜尋結果中移除 URL，也無法取代遷移作業所需的重新導向。它同樣無法編輯 CMS 範本，或檢查框架如何算繪最終文件。產生標記後，仍須執行這些檢查。

將元素放在每個頁面都能讀取的位置

請將複製的標準化元素放入相關頁面或範本的 HTML head 內。通常建議在偏好頁面上使用自我參照的標準化 URL，而重複版本則應一致指向同一個目標。對於用戶端算繪的應用程式，應讓標準化 URL 在來源輸出中清楚可見，並避免使用頁面載入後會不一致地變更它的指令碼。僅在不一致的用戶端變更後才出現的標準化 URL，並不是可靠的共用訊號。

請檢查具代表性的路由，不要因為 1 個頁面成功，就認定每個產生的頁面都能運作。即使複製的元素完全相同，CMS 範本、路由規則與算繪條件仍可能不同。請查看實際 URL 傳送的 HTML，或檢查該 URL 上的文件 head，然後驗證 href、回應狀態與主要內容。標準化 URL 必須描述公開的內容位置，不得洩露認證資訊，也不得暗示受限內容已變成公開內容。

讓全站的標準化訊號保持一致

單一的標準化 URL 最容易受到信任。請避免互相衝突的指示，例如 HTML 中有 1 個標準化 URL、HTTP 標頭中有另一個標準化 URL，而網站地圖中又有另一個偏好地址。當內部連結旨在整合某個版本時，也應指向相同的偏好位置。這並不表示每種技術格式中的每項輔助訊號都必須完全相同；其重點在於每項訊號都應表達相同的 URL 偏好。如果某個路由需要不同的標準化 URL，請記錄原因，並確保其目標提供等效的主要內容。

當多個地址提供應整合的重複或非常相似內容時，標準化是最適當的做法。如果某個重複版本不應再提供，請改用永久重新導向。如果頁面需要驗證，標準化不會移除存取要求，也不會決定該頁面是否應建立索引。因此，最後的比較很簡單：產生的標籤應指定所選的公開 200 頁面，每個重複版本都應一致指向該頁面，而傳送的網站不應公開任何互相矛盾的標準化訊號。

如果您正在權衡各種選項，如何比較產生 Hreflang 的方式？會有更詳細的說明。

如果您正在權衡各種選項，Meta Robots 標籤產生器：上線前錯誤檢查清單會有更詳細的說明。