當公開且可索引的頁面有一個明確的首選 URL，而其他可存取的 URL 會產生重複或衝突訊號時，請產生標準標籤。
請先做出這項決定，再開啟產生器。標準標籤產生器應遵循這項決定，而非取代它。此工具可以驗證、規范化及格式化您所選取的 URL，但無法判定應優先採用哪個內容版本。Google 的重複 URL 指引會將 rel=canonical 視為整合相似頁面的訊號，而非保證有效的指令。
如果您只有一個唯一的 URL、沒有已知重複項目，也沒有互相衝突的網站訊號，通常不需要使用標準標籤來解決重複問題。一般建議在首選頁面使用指向自身的標準標籤，作為清楚明確的訊號，但這是一項一致性選擇，並不代表每個唯一頁面都需要標準化。
依據頁面與 URL 情況進行判斷
請先檢視實際存在的 URL，而非依賴 URL 的外觀。不同網址不一定代表重複內容。兩個產品篩選器可能產生不同結果，而同一項產品可能可透過分類路徑、行銷活動路徑，以及帶有尾端斜線的 URL 存取。
- 多個公開 URL 是否提供相同或非常相似的主要內容？如果是，標準標籤有助於整合這些訊號。
- 是否有一個首選 URL，可傳回真正的 200 回應，並包含您想與該頁面建立關聯的內容？應在產生標記之前選定該目標。
- 實際問題是否在於重複 URL 的選取？當舊 URL 必須停用時，標準標籤不能取代重新導向；對於私人內容，也不能取代存取控制。
當每個相關版本都能指向同一目的地，且該目的地代表權威版本時，請使用標準標籤。在首選頁面上，使用指向其自身 URL 的自我參照。對於重複版本，請將它們指向同一個目標。如果各版本包含實質不同的內容，整合可能會消除有用的差異，因此這項決定應依據網站的內容與路由模型。
查詢字串需要特別留意。出現篩選器、排序選項或分頁值等參數，並不能證明兩個 URL 互為重複。此工具會保留刻意設置的查詢字串，因為它們可能是特意選取的標準網址的一部分；但判定哪些參數代表不同資源，仍是各網站特有的工作。
依問題採取相應做法
請使用以下比較表，在產生標籤前做出明確的執行或不執行決定。
| 情況 | 標準標籤決定 | 正確做法 |
|---|---|---|
| 相同或非常相似的內容可透過多個公開 URL 取得 | 產生一個 | 將每個重複版本指向同一個首選 URL，並在首選頁面使用自我參照。 |
| 有一個唯一且可索引的 URL，沒有已知變體或衝突訊號 | 解決重複問題時不需要 | 自我參照的標準標籤可以提供一致且明確的訊號，但沒有需要整合的重複集合。 |
| 舊 URL 不應再提供服務 | 不要以標準標籤作為替代方案 | 遷移或停用時請使用永久重新導向，因為標準標籤不會將使用者重新導向。 |
| 內容屬於私人資訊或需要驗證身分 | 不要建立公開的標準標籤來解決存取問題 | 請分別檢視索引與存取控制；標準化不會使受保護內容變為公開。 |
| 刻意使用查詢字串的 URL 代表不同內容 | 不要自動將它們合併 | 請依網站的內容與路由規則進行決定，然後保留可識別不同首選資源的參數。 |
| HTML 標準標籤、HTTP 標頭標準標籤與網站地圖不一致 | 先解決目標 | 選擇一個首選網址，讓衝突訊號保持一致，然後才產生並檢查 HTML 元素。 |
此表格可辨識適當做法，但無法提供確切目標。做出最終選擇前，請參考網站內容結構、路由、重新導向、網站地圖與內部連結所提供的證據。
選擇目標後才產生標籤
決定明確後，請使用標準標籤產生器，為您選取的 URL 建立標記。請遵循此工作流程：
- 輸入完整的首選 HTTP 或 HTTPS URL。請包含正確的通訊協定、主機、路徑，以及任何刻意設置的查詢字串。目標必須完整且為絕對網址。請確認它能識別您希望搜尋引擎優先採用的公開頁面，而且該頁面會傳回真正的 200 回應。
- 產生標籤，並將正規化後的 URL 與該 200 頁面進行比較。請檢視顯示的網址，不要立即複製。經過瀏覽器標準正規化後，它仍應識別同一個預期資源。
- 將元素複製到 HTML head，並檢查實際提供的頁面。請將產生的 link 元素放在文件的 head 中，然後檢視實際提供的原始碼，或在真實 URL 上檢查文件 head，以確認存在一個預期的標準訊號。
輸出內容是含 rel="canonical" 的 HTML link 元素，且 href 指向所選取的 URL。輸入的網址會保留在瀏覽器中。查詢字串分隔符號會在標記中逸出為 HTML 實體，因此產生的屬性仍然有效，而顯示的正規化 URL 則會保留一般字元。
瀏覽器標準正規化可能會變更技術細節，但不會變更您預期的資源。主機名稱的大小寫會轉為小寫，預設連接埠會被移除，國際化網域與非 ASCII 路徑會序列化為瀏覽器標準格式。路徑的大小寫仍然重要，不會變更。查詢字串會保留，但片段會被移除：輸入以 https://example.com/page#details 結尾的 URL，會產生 https://example.com/page 的目標。這是因為片段與標準目標有所區分：前者用於識別表示形式內的位置，後者則用於識別底層資源。
輸入規則同樣重要。諸如 /products/widget 的相對路徑會被拒絕，因為其意義取決於文件所在位置。僅接受 HTTP 與 HTTPS；FTP、javascript、data 及其他通訊協定皆無效。含有內嵌認證資訊的 URL 也會被拒絕。標準標籤應識別公開內容的位置，而不應在標記中暴露使用者名稱或密碼。
產生器只會回傳標記。它無法編輯 CMS 範本、無法判定框架如何算繪最終文件，也無法確認已部署的頁面是否包含您複製的元素。
將網站政策決定移至產生器之外
正規化不等於判定哪個 URL 正確。產生器刻意不會：
- 移除追蹤參數；
- 排序查詢鍵值；
- 強制使用 HTTPS；
- 新增或移除 www；
- 選擇尾端斜線政策；
- 解決重新導向；或
- 檢查頁面相似度。
上述每項決定都取決於網站如何路由 URL 及提供內容。任意猜測可能會產生看似有效、卻指向錯誤頁面的標籤。例如，某個網站可能刻意在標準網址中保留查詢字串，而另一個網站則可能將相同查詢的兩個排序版本視為等效。產生器會保留第一種行為，但不會代為決定第二種行為。
URL 處理方式遵循WHATWG URL 標準所描述的瀏覽器 URL 模型。這項標準化可讓格式具備可預測性，但無法確立內容等效性。發布前，請將正規化結果與實際頁面及網站整體的 URL 政策進行核對。
檢查實際提供的頁面與所有標準訊號
部署後，請檢查實際頁面，而非依賴產生器預覽。最終檢查應涵蓋以下項目：
- 確認標準元素位於 HTML head，而非 body。
- 確認實際提供的頁面上只有一個預期的標準元素。
- 確認其 href 可直接解析至首選的 200 頁面，且該頁面具有等效的主要內容。
- 檢查具代表性的路由範本，不要假定一個成功頁面就能證明每個產生的頁面都正確。
- 確保標準標籤不會與 HTTP 標頭中的另一個標準標籤，或網站地圖中的另一個首選網址發生衝突。
- 讓重要的內部連結持續指向同一個首選網址。
對於用戶端算繪的應用程式，請讓標準標籤在原始碼輸出中清楚明確，並避免使用頁面載入後不一致地修改它的指令碼。僅存在於開發範本中的產出元素，不能證明正式環境的回應也包含該元素。
標準標籤是強烈的標準化訊號，但不能保證搜尋系統一定會選取該目標。內容品質、重新導向、網站地圖項目、內部連結及其他訊號，仍可能影響最終選擇。它也不會立即將 URL 從搜尋結果中移除。當重複頁面不應再提供服務時，請使用永久重新導向，並讓標準標籤、網站地圖與內部連結策略配合遷移作業。
進行最終執行或不執行檢查
發布產生的元素前，請回答三個問題：
- 多個公開 URL 是否需要使用一個首選網址？如果是，請產生標準標籤，並將每個相關版本指向同一個目標。
- 您是否已選取完整的 HTTP 或 HTTPS URL，且該 URL 會傳回 200 回應並提供等效的主要內容？如果沒有，請先解決目標，再產生標記。
- 標準化是否為正確機制？如果舊頁面必須重新導向，請使用永久重新導向；如果問題在於存取或索引，請分別處理。
當標準標籤能整合真正的重複或衝突 URL 訊號時，請產生標籤。如果沒有需要解決的重複問題，或將其用來取代重新導向、存取控制或索引控制，則請略過。目標正確後，產生器會處理一致的格式化與正規化，而最終責任仍由頁面、範本及全站訊號承擔，因為它們才決定使用者與搜尋系統實際取得的內容。