標準標籤產生器會拒絕任何非完整、未含認證資訊的 HTTP 或 HTTPS 網址，因此在輸入階段最常見的錯誤其實就是網址格式不對。產生器不會為相對路徑（例如 `/products/widget`）、不安全的協定（例如 `javascript:` 或 `data:`），或內嵌使用者名稱與密碼的網址產出 link 元素——這些輸入會直接回傳空值，而網頁仍會保留原本可能遺失的標準化訊號。當輸入通過這些檢查後，瀏覽器的網址解析器還會在背後對該網址進行標準化處理：主機名會轉為小寫、預設連接埠會被移除，國際化主機名則會轉換為其 ASCII 相容形式。諸如 `#details` 的片段會被捨棄，因為 Google 官方文件通常將片段視為資源內部的指標，而非獨立的標準化目標。了解這些被拒絕的情況與默默進行的標準化處理，能讓你在複製標籤前先修正輸入，避免發佈一個悄悄指向錯誤頁面的元素。
產生器在產出標籤前會拒絕的輸入
標準標籤只有在搜尋引擎能擷取其指向的網址時才有用，因此產生器在輸出任何結果前會強制執行三項輸入規則。
相對路徑會被拒絕，因為其意義取決於讀取它的文件。如果你貼上 `/products/widget`，所產生的標準化網址只有在主機恰好符合你心中所想時才有效；若將網站部署在不同的根目錄下，或在測試主機上進行測試，同一個標籤就會悄悄指向別處。請務必貼上包含協定與主機的完整網址，例如 `https://example.com/products/widget`。
不安全的協定會被拒絕。FTP、`javascript:`、`data:` 及其他非 HTTP 協定無法以相同方式識別出可公開檢索的資源，因此該工具會回傳空值，而非產出一個看似有效卻解析到錯誤位置的標籤。
認證資訊會被拒絕。像 `https://user:[email protected]/private` 這類網址會被拒絕，因為標準化元素是一個公開的標記訊號——將使用者名稱或密碼放入 href 會讓該資訊暴露在每個帶有此標籤的頁面中。如果頁面需要驗證，標準化處理並不會讓它變得公開；在為它產生標籤之前，請重新考慮這個頁面是否應該被索引。
如果輸入未通過上述任一檢查，產生器會回傳空值，而非產出猜測的結果。這種保守的行為是對抗最嚴重錯誤——也就是發佈一個悄悄帶有錯誤 href 的標籤——的第一道防線。
下表摘要說明在產生器寫入任何元素之前，哪些輸入會被接受、哪些會被標準化、哪些會被拒絕。
| 輸入格式 | 範例 | 結果 |
|---|---|---|
| 絕對 HTTP/HTTPS | https://example.com/page | 產生標籤 |
| 相對路徑 | /products/widget | 拒絕 |
| 含預設埠的 HTTPS | https://example.com:443/page | 移除埠號，產生標籤 |
| 含片段的 HTTPS | https://example.com/page#details | 去除片段，產生標籤 |
| Unicode 主機 | https://例え.jp/path | 主機轉換為 Punycode，產生標籤 |
| 含認證資訊的網址 | https://user:[email protected]/page | 拒絕 |
| javascript: 協定 | javascript:alert(1) | 拒絕 |
瀏覽器解析器默默進行的變更
即使網址通過輸入檢查，瀏覽器的 URL 實作在產生器將 href 包進 `link rel="canonical"` 元素之前，仍會套用多項標準化處理。這些並非錯誤——它們是 WHATWG URL Standard 的一部分——但它們會改變網址，而你必須知道這些事情已經發生。
主機名的大小寫會標準化為小寫。像 `https://Example.COM/Page` 這樣的大寫主機名會變成 `https://example.com/Page`。路徑的大小寫則會保留：`/Page` 維持 `/Page`，而伺服器在 `/page` 可能會提供不同的資源。如果網站依大小寫區分路徑，你產生的標籤可能與實際運行的網址不符。
預設連接埠會被移除。443 埠會從 HTTPS 網址中消失，80 埠則會從 HTTP 網址中消失。像 `:8080` 這樣的自訂埠會被保留，因為它是網址的一部分。
國際化網域會透過 IDNA 處理轉換為其 ASCII 相容形式。像 `https://例え.jp/path` 這樣的 Unicode 主機在出現在 href 之前會被標準化為其 Punycode 形式，而非 ASCII 路徑則會以百分比編碼處理，以確保該屬性維持有效的 HTML。
片段會被移除。網址末端的 `#details` 會被去除，因為根據 Google 的標準化指引，搜尋系統通常不支援以片段網址作為標準化目標，而且片段標示的是某個呈現內部的位置，而非獨立的網路資源。
查詢字串會被保留。追蹤參數、排序鍵及其他刻意加入的查詢字串會在標準化過程中保留下來，因為它們可能是被刻意選定的標準化網址的一部分——產生器不會替你做這個決定，解析器也不會。
使用標準標籤產生器產生標準標籤
一旦輸入格式與默默進行的標準化處理都已釐清，實際操作其實很簡短。
- 在任何現代瀏覽器中開啟 標準標籤產生器。輸入內容僅保存在本機頁面中，不會被送到伺服器。
- 貼上完整的首選網址，包括協定（http 或 https）與主機名。可加入刻意保留的路徑與查詢字串，但請省略片段。
- 點擊產生。該工具會解析網址、去除片段、標準化主機與預設埠，並產出一個形式為 `` 的單一 HTML 元素，其中 & 符號會被轉義為 `&`。
- 將標籤旁顯示的標準化網址，與你希望搜尋引擎優先採用的實際 200 回應進行比對。確認主機、路徑大小寫與查詢字串皆與實際提供標準化內容的網址一致。
- 將該元素複製到選定頁面的 HTML `` 中，切勿放到 ``。檢視實際發佈的頁面，確認僅存在一個標準化元素，且指向預期的 200 回應。
若想看一個走過相同流程——從網址一路到 head 標籤——的實作範例，請參閱 從網址到 head 標籤的標準標籤產生器範例 逐步說明。
將標籤貼入 head 後需要留意的錯誤
即使標籤複製過程一切正常，產生出的標籤仍可能有錯。發佈後最常見的錯誤大致可歸納為幾種模式。
標準化訊號互相衝突。同一個頁面可能同時在 HTML head 中帶有一組標準化、在 `X-Robots-Tag` 或 `Link` HTTP 標頭中帶有另一組標準化，以及在網站地圖中帶有第三組網址。搜尋系統會綜合考量所有這些訊號，而不一致會削弱訊號強度。在加入產生的元素之後，請對相同網址的回應標頭與網站地圖項目進行稽核。
協定或主機錯誤。已遷移至 HTTPS 的網站，其標準化仍可能透過 HTTP 提供；或是測試環境可能以不同的主機產出生產環境的網址。請在實際的網址（而非編輯器預覽）上檢視渲染後的 HTML，再宣告該標籤正確無誤。
缺少自我參照。首選頁面通常應帶有指向自身的標準化，而所有重複版本也都應指向同一個網址。若某個頁面所指向的標準化與其重複的版本不同，便會傳遞出矛盾的訊號，搜尋系統可能會任意選用其中一個。
誤以為需要驗證的內容為公開內容。對需要驗證的網址進行標準化處理，並不會讓它變得公開。若頁面位於登入機制之後，標準化並不會繞過存取控制；在發佈標籤之前，請先決定該頁面是否應該被索引。
在 HTML、標頭與網站地圖之間維持單一標準化訊號
一致性是讓標準化訊號強而有力的關鍵。產生器只能產出標記，其餘的訊號就必須手動對齊。
將標準化目標視為一紙契約：所有指向首選頁面的重複版本，都應指向完全相同的 href，包括協定、主機、路徑大小寫與查詢字串。發佈後，請檢索一組具代表性的路由——而不僅僅是一條——並確認每一條都恰好顯示一個標準化元素，且其網址為預期的 200 回應。
網站地圖與 HTTP 標頭應與 HTML 中的標準化一致。若網站地圖列出的是 `https://example.com/page/`，而標準化元素指向的是 `https://example.com/page`（無論結尾有無斜線），搜尋系統就必須在兩個看起來都合理的訊號之間抉擇，其選擇可能難以預測。
標準化標籤並不會轉向使用者、不會立刻將網址從搜尋結果中移除，也無法取代遷移時所需的重導。當某個重複版本不應再被提供時，請使用永久重導，並將重要的內部連結維持指向同一個首選網址。標準化標籤負責整合訊號；重導則負責轉移使用者與檢索器。