Canonical 標記怎麼用？處理重複網址而不誤刪內容
Canonical 用來指出重複或非常相似內容的代表網址，不是刪頁或禁止索引按鈕。本文比較 canonical、永久轉址與 noindex，並用完整案例示範實作與驗證。
先說結論：canonical 是代表版本的線索，不是刪除指令
同一份或非常相似的主要內容可以因追蹤參數、列印版、網址大小寫、協定或篩選功能而出現在多個 URL。Canonical 的作用，是告訴搜尋引擎：這一組近似網址裡，希望哪一個成為整合訊號與呈現搜尋結果的代表版本。
它不會把替代網址從伺服器刪除，也不會像轉址一樣把讀者自動送走；搜尋引擎仍會自行判斷，可能選擇和站方宣告不同的 canonical。因此，正確做法不是只加一行標記，而是讓永久轉址、rel="canonical"、Sitemap 與站內連結共同指向同一個清楚、可索引的代表 URL。
先用使用者需求做第一個分流：
- 舊網址不再需要被開啟：使用永久轉址，讓人與搜尋引擎都前往新網址。
- 替代網址仍有功能，但主要內容重複或非常相似：保留頁面並指定 canonical。
- 頁面必須存在，但不應出現在搜尋結果：使用
noindex，前提是搜尋引擎能爬到這項指令。 - 兩頁回答不同問題或提供實質不同內容：各自保留 self-canonical，不要用 canonical 取代內容決策。
Canonicalization 到底在處理什麼？
Google 把 canonicalization 定義為：從一組重複頁面中選擇代表 URL 的過程。系統會比較頁面的主要內容，把相同或非常相似的網址聚成一組，再依收到的訊號選出 canonical。重複內容本身在網站中很常見，並不自動等於垃圾內容或處罰。
常見來源包括：
- 同一商品頁帶有不同活動或分析參數。
- 同一文章同時有一般版與列印版。
http、https、有無www或結尾斜線都能開啟相同內容。- 分類頁使用排序、顏色或價格參數產生大量 URL。
- 測試站或舊路徑意外保持公開。
Google 通常以 canonical 頁作為評估內容與品質的主要來源，重複頁則較少被爬取；Search Console 的部分成效資料也會歸到 Google 選定的 canonical。這能減少同一內容的訊號與報表散落，但不代表每一個替代 URL 都不再被發現或爬取。
網際網路工程任務組發布的第 6596 號文件，把 canonical link relation 定義為：從重複內容中指定偏好的資源。規範也提醒，canonical 目標必須包含重複內容或成為其完整上位版本；若把只含第一部分內容的頁面指定為完整文章的 canonical，搜尋系統可能忽略替代頁的獨有內容。
Canonical、轉址與 noindex 怎麼選？
| 情境 | 優先方法 | 讀者打開舊 URL | 搜尋端主要期待 | 不適合用來做什麼 |
|---|---|---|---|---|
| 舊頁永久搬到等價新頁 | 301 或 308 永久轉址 | 自動到新頁 | 把轉址目標視為 canonical 的強訊號 | 保留兩個可獨立操作的版本 |
| 參數版、列印版仍須可開啟 | rel="canonical" | 留在原頁 | 把近似 URL 聚類並偏好代表頁 | 強迫兩篇不同文章只收錄一篇 |
| 登入後清單、測試結果頁不應搜尋 | noindex | 仍可開啟 | 爬取後不在搜尋結果提供該頁 | 整合重複頁的連結訊號 |
| 頁面永久刪除且沒有相近替代 | 404 或 410 | 顯示已不存在 | 說明原資源已移除 | 把無關頁全部轉到首頁 |
| 篩選頁有獨立需求與獨有內容 | 獨立 URL 與 self-canonical | 正常使用 | 讓它有機會作為獨立頁處理 | 因為 URL 有參數就一律合併 |
Google 把永久轉址與 rel="canonical" 都視為強 canonical 訊號，Sitemap 則是較弱訊號；多項一致的訊號可以互相加強。永久轉址適合「這個舊位置不再提供內容」，canonical 適合「這個替代版本仍有用途，但主要內容應歸到代表頁」。兩者不能只依哪個比較有利於排名來選。
noindex 的目的不同：它明確要求不要在搜尋結果呈現該資源。Google 不建議在同一網站內用 noindex 代替 canonical 選擇，因為它會把該頁排除，而不是告訴系統應把它和哪個代表頁整合。若又用 robots.txt 阻擋爬取，搜尋引擎可能根本讀不到頁面裡的 noindex。
rel="canonical" 應該怎麼實作？
HTML 頁面最常見的方法，是在重複頁的 <head> 放入一個使用完整絕對 URL 的 link element：
<link rel="canonical" href="https://example.com/guides/coffee-grinder/">代表頁本身也建議輸出指向自己的 self-referential canonical。這能讓模板意外帶入追蹤參數或不同存取路徑時，仍清楚表達偏好的乾淨 URL。
非 HTML 資源無法在文件 <head> 加標記時，可以使用 HTTP Link response header。Google 建議在 HTML element 與 HTTP header 中擇一實作，避免兩個位置日後各自指向不同目標。
一個可維護的 canonical 至少要符合五項條件：
- 目標 URL 回傳成功，沒有再轉往另一頁。
- 目標可被搜尋引擎爬取與索引，不含互相矛盾的
noindex。 - 來源與目標的主要內容相同、非常相似，或目標完整包含來源內容。
- 同一頁只宣告一個 canonical，不在 HTML、HTTP header 與 Sitemap 各寫不同答案。
- 站內連結直接指向 canonical，不長期讓讀者先走參數版或多段轉址。
完整案例：84 個可開啟網址，真正需要的是 12 個內容代表
以下是虛構教學案例，用來示範清冊、工具選擇與驗證，不是 MKT Notes 或任何企業的 Search Console 結果。
一個線上沖煮課程有 12 篇公開教材。每篇教材除了乾淨 URL，還能透過 5 種活動追蹤參數與 1 個列印路徑開啟相同主要內容。可存取的組合是：
團隊不能因此把所有帶參數頁都阻擋或刪除。活動連結仍要能正確開啟，列印版也要服務讀者；真正要處理的是「哪一個 URL 代表這份教材」。他們為每組建立下列規則：
| URL 類型 | 內容與用途 | 處理方式 | Sitemap 與站內連結 |
|---|---|---|---|
| 乾淨教材 URL | 完整閱讀與分享 | 200、可索引、self-canonical | 列入 Sitemap，所有站內入口直接連到它 |
| 活動參數 URL | 同內容，用來辨識來源 | 200、canonical 指向乾淨 URL | 不列入 Sitemap，不作常態站內連結 |
| 列印路徑 | 同教材的列印呈現 | 200、canonical 指向乾淨 URL | 從教材頁提供功能入口，不列入 Sitemap |
| 舊教材 slug | 已永久改名，沒有保留用途 | 301 到對應的新乾淨 URL | 清除舊站內連結與 Sitemap 項目 |
| 編輯預覽 | 未核准內容，只供登入者檢查 | 驗證權限，另依需求 noindex | 不列入 Sitemap，不公開連結 |
| 進階延伸教材 | 題目接近但內容、例子與任務不同 | 200、獨立 self-canonical | 當作獨立文章並建立描述性內部連結 |
這份設計沒有承諾 Google 一定只爬 12 個 URL，也不應把「替代頁未索引」當錯誤。合理的驗證目標是：每一組的 user-declared canonical 都指向正確乾淨頁；Google-selected canonical 重新處理後也逐步一致；12 個乾淨頁保持可索引；追蹤與列印版仍能正常服務使用者。
最重要的反例是「進階延伸教材」。它雖然也談磨豆機，卻回答不同程度讀者的不同任務。若只因關鍵字接近就 canonical 到入門篇，搜尋系統可能把進階篇視為重複版本，忽略其獨有內容。應先用關鍵字蠶食診斷區分查詢重疊與真正的重複內容。
一致訊號比單獨一行標記更重要
假設參數頁宣告乾淨教材為 canonical，但 Sitemap 列的是參數 URL，首頁又連到舊 slug，搜尋引擎收到的其實是三個不同答案。Google 可能仍選出合理版本，也可能顯示「Duplicate, Google chose different canonical than user」。這不是加強標記數量能解決的問題，而是要修正訊號衝突。
檢查時可把每組網址攤成一列：
| 檢查層 | 應該看到什麼 | 常見衝突 |
|---|---|---|
| HTTP 回應 | 代表頁 200；已搬遷舊頁單段永久轉址 | canonical 目標本身又轉址或回傳錯誤 |
| HTML／header | 每頁最多一個明確目標；代表頁 self-canonical | 原始碼與渲染後值不同，或兩處宣告不同 URL |
| Sitemap | 只列想作為搜尋代表的可索引 URL | 替代版、轉址頁與 noindex 頁仍在清單 |
| 站內連結 | 導覽、正文與麵包屑直接連 canonical | 大量連到參數版、大小寫變體或舊路徑 |
| 內容相似度 | 來源與目標主要內容重複或非常相似 | 把不同語言、不同商品或不同任務硬歸成一頁 |
篩選導覽尤其需要先判斷內容差異。若「價格排序」只改變順序，通常接近重複版本；若「無麩質咖啡點心」有獨立需求、專屬說明與穩定商品集合，它可能值得成為獨立頁。Google 的篩選導覽文件也提醒，參數組合可能製造近乎無限的 URL 空間；canonical 可協助整合訊號，但不等於大型網站不需要設計爬取與 URL 規則。
八步工作流：從網址清冊到 Search Console 驗證
1. 先定義代表頁的使用者價值
選擇最穩定、可分享、內容完整、回應正常且預計長期保留的 URL。不要只挑最短網址，也不要把即將刪除或需要登入的頁面設為目標。
2. 建立重複網址清冊
從網站路由、分析參數、Sitemap、站內爬取與 Search Console 匯出候選。記錄每個 URL 的狀態、內容任務、是否可索引、宣告 canonical 與目前站內入口。
3. 先判斷是不是同一份主要內容
逐組比較標題、正文、商品集合、語言、功能與讀者任務。內容不同就保留獨立頁；只有相同、非常相似或完整上位版本才進入 canonical 聚類。
4. 依存取需求選工具
不再使用的舊頁做永久轉址；仍需開啟的重複版使用 canonical；不應出現在搜尋結果的功能頁使用 noindex；已永久移除且沒有相近替代內容則回傳 404 或 410。
5. 讓所有訊號對齊
更新 HTML 或 HTTP header、Sitemap、內部連結、語言替代標記與結構化資料中的 URL。轉址應直接到最終代表頁，避免 A 到 B 再到 C 的長鏈。
6. 在正式 HTML 與回應中抽查
檢查 canonical 是否真的出現在 <head>、是否為絕對 URL、是否只有一個、是否被 JavaScript 改寫，以及目標能否正常回應。對非 HTML 資源則直接看 response header。
7. 分別檢查站方宣告與 Google 選擇
URL Inspection 的已索引資料會顯示 user-declared canonical 與 Google-selected canonical。Live Test 能確認現在是否抓得到頁面與標記，卻不能預測最後 canonical，因為重複聚類發生在索引處理階段。
8. 記錄修改並等待重新處理
保存修改日、樣本 URL、原狀態與預期結果。優先對重要代表頁要求重新索引，之後按同一清冊複查。不要每天改一次目標；爬取與重新聚類需要時間，短期狀態不等於設定無效。
七個常見錯誤與限制
把 canonical 當成搜尋引擎一定服從的指令
站方宣告的是偏好，Google 仍會依內容相似度、加密連線版本、轉址、Sitemap 與其他訊號選擇代表頁。若選擇不同，先找內容與訊號衝突，不要反覆提交同一 URL。
每個重複頁都 canonical 到首頁
首頁通常不是商品、文章或分類頁的重複內容。這種映射失去語意，也可能被忽略；每個來源都應對到真正等價或完整包含它的頁面。
用 canonical 合併內容不同的頁面
相同關鍵字、同一商品系列或相似版型不等於重複內容。頁面若有獨立任務與實質內容，應讓它獨立存在，再用內部連結架構表達關係。
canonical、Sitemap 與站內連結各指一個版本
技術訊號互相打架時，搜尋引擎必須自行解題。修正順序是先決定唯一代表，再把 Sitemap、導覽、正文連結與轉址全部更新。
用 robots.txt 阻擋後，期待搜尋引擎讀到 canonical 或 noindex
若禁止爬取，搜尋引擎可能無法讀取頁面裡的標記。爬取控制、索引控制與 canonicalization 是不同層級，應依問題分開設計。
看見「Alternate page with proper canonical tag」就當成錯誤
若替代頁本來就不需要獨立出現在搜尋結果，這通常是預期狀態。真正要確認的是 Google 選到哪個代表頁，以及那一頁是否正確、可索引並服務使用者。
宣稱 canonical 能解決大型網站所有爬取浪費
Canonical 可能讓重複版本逐步降低爬取頻率，但搜尋引擎仍要先發現與處理許多 URL。對大量篩選組合，仍要控制可產生的路徑、空結果、站內連結與伺服器資源；小型網站則不必把「爬取預算」包裝成緊急問題。
最後帶走：先回答「這頁還要不要存在」
遇到重複網址，不要從標籤語法開始。先依序問四件事：
- 這兩個 URL 的主要內容與讀者任務真的相同嗎？
- 替代 URL 還需要讓人直接開啟嗎？
- 希望哪個穩定 URL 成為搜尋與分享的代表？
- 轉址、canonical、Sitemap、站內連結與索引規則是否給出同一答案？
如果舊位置已淘汰，用永久轉址；如果替代版本仍有功能且內容近似，用 canonical；如果頁面不該出現在搜尋結果，用可被爬取的 noindex；如果兩頁各自有價值，就各自保留。Canonical 最重要的能力不是「消除重複內容」，而是讓一組仍可能存在的網址，有一個清楚、可驗證且一致的代表版本。
SOURCE LOG
資料來源
- Google Search Central：Canonicalization 的定義與代表網址選擇
- Google Search Central：指定 canonical 的方法與訊號強弱
- 官方規範：第 6596 號 Canonical Link Relation 文件
- Google Search Central：永久與暫時轉址對 canonical 的影響
- Google Search Console：URL Inspection 與 canonical 欄位
- Google Search Console：Page indexing 的重複網址狀態
- Google Search Central：建立 Sitemap 與只列入預期 canonical
- Google Search Central：Robots meta tag 與 noindex 規則
- Google Crawling Infrastructure：篩選導覽網址的爬取管理