同一篇文章加上追蹤參數，可能產生另一個網址；同一個產品頁，也可能有排序、列印或不同路徑的版本。網址不同，內容卻相同或非常接近，企業就需要確認：希望哪個版本成為主要網址？
Canonical 是處理這類問題的方式之一。但它不是強制 Google 採用某個網址的指令，也不會讓訪客自動跳轉，更不是禁止索引的開關。
Canonical 的核心用途，是針對重複或高度相近的內容，表達偏好的主要網址。 設定前要先判斷哪些頁面真的屬於相同內容，設定後則要核對目標頁與其他訊號，不能只驗收「有沒有一個標籤」。
Canonical 是什麼？為重複或相近內容指出偏好網址
企業指定與 Google 選定的主要網址可能不同
Canonical 常被稱為標準網址或主要網址。網站可以使用 rel="canonical" 表達偏好的版本，Google 則會依內容與其他訊號，選擇它認為適合的主要網址。若要確認不同轉址的差異與適用情境，可以接著閱讀〈301、302、307、308 轉址的差異〉。
Google 的主要網址設定說明將 rel="canonical" 與轉址列為強訊號，Sitemap 列入則是較弱的訊號。這些方法可以共同支持同一個選擇，但不是企業設定後就一定被採用。
因此，要分開記錄「網站宣告的主要網址」與「Google 選定的主要網址」。兩者不同時，先查內容與設定，不必直接認定 Google 出錯，也不能只反覆加入同一個標記。
Canonical、轉址與 noindex 解決的問題不同
三種方式的差異，可以先從訪客與搜尋用途理解：
| 方式 | 主要用途 | 訪客與索引上的差異 |
|---|---|---|
| Canonical | 表達重複內容偏好的主要版本 | 不會因標記本身讓訪客跳轉，也不保證其他版本完全不索引 |
| 轉址 | 將舊網址或停用版本導向另一個位置 | 訪客會前往目標網址；是否永久及如何實作需依用途確認 |
| noindex | 要求支援的搜尋引擎不要索引內容 | 頁面仍可能供訪客閱讀，但不是整合重複網址的同義工具 |
舊版頁面不再使用時，可以評估適當轉址；多個版本仍需要存在且內容相同時，可以評估 Canonical；公開內容不希望出現在搜尋中，則是另一種索引需求。延伸閱讀：若正在規劃改版或換網址，想確認上線前後的檢查項目，請見〈網站改版避免 SEO 流量流失的檢查清單〉。
Google 官方不建議用 noindex 來阻止同站某頁被選為主要版本。先確認要解決的問題，再選工具，避免一邊希望整合內容，一邊又要求搜尋引擎不要索引。
哪些網址情境需要先檢查？
參數、排序、列印及多網址版本是否呈現相同內容？
常見檢查對象包括帶追蹤參數的網址、列印版本、不同排序，以及多條路徑提供相同內容的頁面。
但不能只看網址格式就判斷。某些參數只記錄來源，不改變內容；另一些參數則可能改變商品、篩選結果或頁面任務。相同參數名稱，在不同網站也可能有不同用途。
先比較主要內容、讀者需求與功能，再決定是否視為重複。以下是假設性的判斷示例，不是所有網站都應套用的設定：
| 網址情境 | 應先確認的事 | 可能的方向 |
|---|---|---|
| 同一篇文章加上追蹤參數 | 正文是否相同，參數是否只供追蹤 | 評估指向文章主要版本 |
| 同一份內容的列印頁 | 是否只是呈現方式不同 | 評估指向一般閱讀版本 |
| 商品排序版本 | 商品與需求是否實質相同 | 依內容與網站架構判斷，不一律合併 |
| 舊路徑與新路徑內容相同 | 舊版是否還需要保留 | 若停用舊版，可評估永久轉址 |
| 不同產品或服務頁 | 範圍、內容與讀者任務是否不同 | 不因關鍵字相近就指向同一頁 |
內容不同或不同語言的頁面，不能一律合併指向
兩篇文章都包含「SEO 費用」，不代表它們是重複頁。一篇解釋收費方式，另一篇說明預算評估，可能支援不同的決策任務。應先檢查內容分工，而不是依關鍵字相似度直接合併。
不同產品、地區或服務條件，也可能需要獨立頁面；但如果只是換了名稱，沒有實質差異，則要重新檢查內容設計。
語言版本也不能全部指向單一語言頁。Google 官方建議，使用 hreflang 時應指定同語言的主要頁；只有不存在同語言主要頁時，才考慮合適的替代語言。語言與地區版本的關係，需要另按網站實際架構確認。
設定前：選定主要版本並盤點既有訊號
主要網址是否可存取、可索引且內容相符？
主要網址不是選一個最短的網址就好。應確認它是正式版本、正常提供內容，沒有誤設的 noindex 或不必要存取限制，也與來源頁的內容相符。
如果重複文章指向首頁，首頁卻沒有相應正文，就不能只因為首頁比較重要而視為合理整合。同樣地，指向錯誤頁、登入頁或測試站，也不符合原本的主要版本目的。
建議先建立來源與目標對照，並記錄為什麼視為同一份內容。無法說明兩頁關係時，先不要用 Canonical 掩蓋尚未整理清楚的內容結構。
內部連結、Sitemap 與轉址是否支持同一選擇？
主要網址選定後，站內連結與 Sitemap 應盡量支持同一版本。不要文章宣告 A 是主要頁，導覽大量連到 B，Sitemap 又列入 C。若要分清楚這幾種索引設定各自負責什麼，可以接著閱讀〈robots.txt、noindex 與 Sitemap 的差異〉。
若已設定轉址，也要確認最終目標與 Canonical 一致。Google 官方提醒，不要用不同主要網址設定方式，替同一頁宣告互相衝突的目標。
可以從導覽、文章連結、相關頁面推薦與 Sitemap 抽查。這不是要求立即修改所有歷史外部連結，而是先把企業能控制的訊號整理清楚，降低維護與判斷上的混亂。
設定時：把 Canonical 使用範圍說清楚
自我指向與重複頁指向各用在哪些情境？
自我指向，是主要頁宣告自己為偏好的網址；重複頁指向，則是將其他版本的偏好主要網址設為同一個正式頁面。
例如文章正式版本指向自己，帶追蹤參數但正文相同的版本指向正式版本。這是假設情境，實際仍要確認系統是否以相同方式產生內容。
Google 建議主要頁本身也提供自我指向 Canonical，但未指定偏好不代表網站一定無法被搜尋，Google 仍可能自行選擇主要版本。不要把缺少標記一律描述成排名失敗的原因。
不同系統可能透過頁面模板、插件或伺服器設定實作。企業應交辦來源與目標規則，工程則確認實際輸出與特殊頁型，不只開啟一個全站設定。
避免錯指首頁、無效網址或不一致的連鎖設定
常見問題包括所有文章指向首頁、正式頁指到測試網域，或 A 指向 B，B 又指向 C。這些情況都應回到預期主要版本重新核對。
Google 官方建議使用完整的絕對網址，而不是相對路徑，也不建議使用帶有 # 片段的網址作為主要網址。這能減少環境與路徑解析造成的混淆。
若採 HTML link 標記，應確認它出現在有效的 head 區段；如果由程式動態加入，則需核對實際產生的內容。也要避免模板、插件或其他實作同時輸出不同的主要網址。
主要版本應清楚且直接，不用多層連鎖表達偏好。來源頁與目標頁修改後，都要重新檢查，不能只測其中一端。
怎麼驗證實際設定及 Google 的選擇？
核對頁面實作及 Search Console 網址檢查
驗收可以分成兩層：網站實際宣告是否正確，以及 Google 後續選擇是否符合預期。
先由網站負責人核對 HTML、可用的回應標頭與實際渲染結果，確認來源網址宣告哪個目標。不是後台填了正確網址，就代表公開頁面已輸出相同設定。
接著使用 Search Console 網址檢查，查看可用的「使用者宣告的主要網址」與「Google 選定的主要網址」資訊。若尚無相關資料，就記錄未知，不由即時測試自行推測。若發現頁面沒有被 Google 收錄，想知道排查順序，推薦搭配〈網站沒有被 Google 收錄的排查步驟〉一起閱讀。
Google 的網址檢查工具說明指出，主要網址選擇需要查看索引資料；即時測試不能預測受測網址是否會被選為主要版本。
不只看有沒有標籤，也確認目標頁與其他訊號
一個正確輸出的標記，仍可能指向不適合的頁面。驗收要一起確認目標內容、存取與索引條件，以及內部連結、Sitemap 和轉址是否一致。
可以用以下清單核對：
- 來源與目標是否真的是重複或高度相近內容？
- 目標是否為正式、可存取且適合索引的網址？
- 宣告是否明確，有沒有多個互相衝突的值？
- 目標頁是否提供符合預期的自我指向？
- 內部連結、Sitemap 與轉址是否支持同一版本？
- Search Console 資料是在修改前還是修改後處理的？
這些條件可以核對工作品質，但不能保證 Google 立即採用。設定發布、重新檢索與主要網址選擇，是不同的階段。
Google 沒選指定網址，應如何排查？
內容相似度、存取及索引條件是否符合？
先比較被指定的頁面與 Google 選擇的頁面。內容是否真的相同？預期主要頁是否存取異常、被封鎖或有 noindex？是否存在舊版本訊號與不一致的轉址？
也要確認工具資料的時間。如果主要網址設定剛修改，索引資料仍反映先前版本，不宜直接宣布設定無效。
按照證據逐項排查，比不斷更換主要網址更容易釐清問題。若同時修改多種設定，應保留版本與時間，避免事後無法知道哪些工作已落地。
頁面角色不同時，先重新判斷是否應視為重複
Google 沒有採用指定網址，可能需要重新檢查原本的內容分組。兩頁若支援不同需求，就不應只因企業希望集中排名而強行指向同一頁。
若內容確實重複，而且其中一頁已不再需要，可以評估直接整合內容與適當轉址。若兩頁都要保留，則明確說明各自用途與相同部分，再決定合適設定。
不要用 robots.txt 封鎖、搜尋移除工具或大量 noindex，強迫完成主要網址選擇。Google 官方不建議把這些方法當作網址整合手段；它們處理的是其他問題，也可能阻止必要資訊被取得。
企業怎麼交辦、驗收與持續維護？
列出來源網址、預期主要網址、責任及檢查方式
交辦不應只寫「修 Canonical」。可以建立以下對照表，讓內容、工程與 SEO 負責人確認同一份規則：
| 欄位 | 建議記錄內容 |
|---|---|
| 來源網址或頁型 | 哪些參數、路徑或版本需要處理 |
| 預期主要網址 | 完整正式網址，不只填首頁或頁面名稱 |
| 判斷依據 | 內容為何相同，其他版本為何需要保留 |
| 配套訊號 | 內部連結、Sitemap 與轉址需如何調整 |
| 責任與日期 | 核准者、實作者、上線與檢查時間 |
| 驗收結果 | 實際宣告、目標頁狀態與 Google 選擇資料 |
資料不足時，把待確認事項寫出來。內容團隊確認頁面分工，工程確認網址與輸出，SEO 負責人核對搜尋訊號，不把所有判斷都交給一個插件設定。
新功能或改版後抽查，不承諾設定後一定立即生效
網站新增篩選、排序、語言版本或更換模板時，都可能改變網址與內容關係。上線前後應抽查代表性頁面，而不是只在第一次設定時驗收。
也要注意測試環境、插件更新與網域變更，是否讓正式頁指向錯誤版本。保留既有規則與測試清單，才能在更新後快速比較。
後續搜尋表現應另行觀察。主要網址採用正確，不代表排名一定提高；排名變化，也不能直接當成 Canonical 修改的因果證明。
Canonical 做得好，不是每個頁面都有標記，而是企業清楚知道哪些內容屬於同一組、希望保留哪個主要版本，並讓設定與其他訊號保持一致。
從內容關係開始，完成網址選擇、實作與分層驗收，才能避免用錯設定，也讓網站在新增功能或改版時有可持續維護的依據。