標準 URL 是透過放置在 HTML head 中的 rel=canonical 連結元素來識別的，該元素為一個可能透過多個 URL 存取的頁面指定單一的首選地址。這個標籤是「如何將標準 URL 訊號放到頁面上」這個問題的實用解答，因為相關工作只是在 head 中貼上一段 HTML，而不是伺服器設定或重新導向。標準 URL 的產生方式是將一個完整的絕對 HTTP 或 HTTPS 位址寫入一個工具，該工具會驗證通訊協定、正規化主機與路徑、移除片段，並將結果 HTML 跳脫後放入連結元素。接著將該元素複製到每個應被視為同一資源的重複或近似重複頁面中。這個訊號是對搜尋引擎的一個強烈提示，用以決定要索引哪個版本，但它只是眾多輸入之一：重新導向、網站地圖、內部連結與內容證據都會影響最終的選擇。

how to get canonical url
how to get canonical url

標準標籤實際的作用

標準標籤是一行 HTML，看起來像 <link rel="canonical" href="https://example.com/page">。它放在頁面的 <head> 中，告訴爬蟲你認為哪個 URL 是首選版本。Google、Bing 及其他主要搜尋引擎將它視為一個強烈的標準化訊號，這代表它能協助它們將重複或近似重複的頁面合併到單一被索引的地址上。如果沒有它，同一篇可透過 /blog/post、/blog/post?ref=twitter 與 /Blog/Post 存取的文章，可能會被視為三個獨立資源，從而分散連結權重並造成分析上的混淆。

這個標籤不會重新導向使用者，也不會單獨將某個 URL 從索引中移除。即使標準指向其他地方，該頁面仍可能被爬取並提供內容，這就是為什麼正式環境的路由決策應該與標籤一致。如果你真的想讓某個 URL 消失，請使用 301 重新導向；當多個 URL 必須保持可存取但應被視為同一資源時，則使用標準標籤。標準標籤產生器會根據你輸入的單一 URL 產生這個 HTML 元素，並以�覽器本身的 URL 解析器作為正規化地址的真相來源。

接受與拒絕的 URL 輸入

這個產生器只接受完整、沒有認證資訊、且使用 HTTP 或 HTTPS 通訊協定的 URL。其他所有輸入在產生標籤之前都會被拒絕。不允許相對路徑，因為其意義會隨著文件位置與部署環境而改變。FTP、javascript、data 及其他非 HTTP(S) 通訊協定在此工具中不是有效的標準目標。含有內嵌使用者名稱或密碼的 URL 會被拒絕，因為標準應該識別的是公開的內容位置，而不是在標記中洩露認證資訊。

片段會從輸入中移除。Google 官方文件基本上不支援片段 URL 作為標準目標，而且片段識別的是頁面內部的某個位置，而非獨立的網路資源。因此輸入 https://example.com/page#details 會產生一個 href 為 https://example.com/page 的標籤。認證機制並不會改變這點：如果內容需要登入，標準化並不會讓它變得公開，也無法解決存取控制問題，所以真正的問題應該是這個頁面到底是否應該被索引。

輸入形式結果
https://example.com/page接受；標籤指向正規化後的 URL
http://example.com:443/page接受；連接埠 443 在 HTTPS 輸出中會被移除
https://Example.com/Page接受；主機轉為小寫，路徑大小寫保留
https://example.com/page#details接受；片段已移除，href 為 /page
/products/widget拒絕；不允許相對路徑
ftp://example.com/file拒絕；不支援非 HTTP(S) 通訊協定
https://user:[email protected]/拒絕；不允許內嵌認證資訊

產生器正規化哪些內容（以及保留哪些內容）

�覽器的 URL 解析器是所產生的 href 內容的真相來源。主機的大小寫會被轉為小寫，因此大寫的主機會變成小寫。預設連接埠會被移除，因此連接埠 80 會從 HTTP 中消失，連接埠 443 會從 HTTPS 中消失。國際化域名會被轉換為其 ASCII 相容形式。Unicode 路徑會以瀏覽器標準形式序列化。路徑的大小寫會被保留為有意義的，因此 /Products/Widget 會保持原樣，而不會被折�為 /products/widget，這是依據解析器所實作的 WHATWG URL Standard。

查詢字串會被保留，因為它們可能是刻意選擇的標準位址的一部分。此工具不會移除追蹤參數、不會排序查詢參數、不會強制使用 HTTPS、不會新增或移除 www 前綴、不會選擇尾端斜線原則、不會解析重新導向，也不會檢查頁面相似度。這些決策取決於網站的路由與內容；猜測它們可能會產生一個看起來有效、但實際指向錯誤頁面的標籤。在 HTML 屬性中，& 符號會被跳脫為 &amp; 以確保標記有效；顯示出來的正規化 URL 則保留一般的 & 字元。這個差異是預期中的，並不會改變所請求的 URL。

屬性行為
主機大小寫轉為小寫
預設連接埠 (80, 443)從 href 中移除
片段 (#...)移除
路徑大小寫完全照原樣保留
查詢字串完全照原樣保留
href 中的 & 符號HTML 跳脫為 &amp;
Unicode 路徑以瀏覽器標準形式序列化
國際化域名轉換為 ASCII 相容形式

如何用三個步驟取得標準 URL 標籤

  1. 輸入完整的首選 HTTP 或 HTTPS URL，包含正確的主機、路徑，以及任何刻意保留的查詢字串。請使用帶有通訊協定的絕對形式，不要貼上相對路徑或含有想保留片段的 URL。
  2. 產生標籤，並將正規化後的 URL 與你想讓搜尋引擎優先收錄的真實 200 回應頁面進行比對。瀏覽器的 URL 解析器可能已經變更了主機大小寫、移除了預設連接埠，或序列化了一個國際化域名，因此輸出內容在複製前應該進行檢查。
  3. 將該元素複製到 HTML head 中，然後檢查實際交付的頁面，確認只有一個一致的標準訊號。在瀏覽器中開啟實際的 URL，檢視 head 的原始碼，並確認正好有一個 rel=canonical 元素，其 href 也符合你的預期。

標籤應放在哪裡以及如何驗證

複製的元素應放在 <head> 內部，而不是放在 body 中。對於用戶端渲染的應用程式，請在原始輸出中明確標示標準，並避免在載入後不一致地修改它的腳本。這個產生器只回傳標記；它無法編輯 CMS 範本，也無法驗證框架如何渲染最終文件。如果你在 WordPress 中建立頁面，《如何在 WordPress 中建立標準標籤：實用指南》提供了實用的範本層級操作說明，其中涵蓋了外掛設定與佈景主題層級的放置方式，與本工具所產生的標籤相同。

加入標�後，請檢視實際交付的 HTML，或在真實 URL 上檢查文件的 head。確認有一個預期的標準元素，且其 href 解析為具有等效主要內容的 200 回應頁面。請跨代表性的路由檢查範本，而不是假設一個成功的頁面就代表每個產生的頁面都沒問題。八個符合標準的測試案例涵蓋根斜線插入、主機正規化、路徑大小寫保留、HTTP 與 HTTPS 預設連接埠、片段移除、Unicode 路徑、國際化域名與查詢字串；另有獨立的測試斷言精確的 HTML 跳脫，並拒絕相對、不安全通訊協定與含認證資訊的目標。

削弱訊號的常見陷阱

在首選頁面上使用自我參照的標準標籤是常見的建議做法，讓頁面指向自己。重複的版本應一致地指向同一個標準目標。請避免出現衝突的訊號，例如 HTML 中一個標準、HTTP 標頭中是另一個標準、網站地圖中又是另一個 URL；保持一致性會讓偏好更加明確，Google Search Central 的標準文件中對此有所說明。請勿將標準指向回傳 404 或軟式 404 的頁面，也不要將它指向主要內容明顯不同的頁面。

標準標籤有助於整合重複的 URL 訊號；它們不會重新導向使用者、不會立即從搜尋結果中移除某個 URL，也無法取代遷移時的重新導向。當某個重複內容不應再被提供時，請使用永久重新導向，並讓重要的內部連結指向同一個首選地址。如果你網站中路徑大小寫、尾端斜線或 www 前綴不一致，請選擇一條規則並在所有地方套用，因為標準標籤無法修正網站其餘部分忽略的路由原則。

如果你正在權衡各種選項，《Hreflang 產生器替代方案：瀏�器端標籤建構工具》對此有詳細說明。