Canonical tag 是放在 HTML <head> 裡的一行 <link> 元素，用 rel="canonical" 告訴搜尋引擎：這一群內容相同或高度相似的重複網址裡，你偏好讓哪一個網址出現在搜尋結果中。它在 Google 的官方定位是提示性質的訊號，Google 保留最終選擇權。重複版本要保留時可用 canonical；舊網址永久淘汰時用 301；不想讓頁面出現在搜尋結果時則使用 noindex，並允許搜尋引擎檢索。設定完成後，還要用 Search Console 比對網站宣告與 Google 實際選擇的標準網址。
Canonical tag 是什麼：標準網址與標準化程序
Canonical tag 中文常稱為標準連結標籤或標準網址標籤，本體非常簡單，就是一行 HTML：<link rel="canonical" href="網址" />。HTML 規格對這個關鍵字的定義寫得很直白：href 屬性指定的網址，是目前這份文件偏好的網址，用途是幫助搜尋引擎減少重複內容。這層連結關係的完整定義收錄在 2012 年 4 月發布的 RFC 6596，Google 的支援說明也以它為依據。這個屬性是 2009 年 2 月由搜尋引擎共同宣布支援的機制，比多數人以為的歷史更久。
要理解它解決的問題，先看重複網址怎麼來。同一篇內容常常可以透過多個網址存取：有 www 和沒有 www 的版本、http 與 https 版本、廠商追蹤參數造成的變體、商品列表的排序與篩選組合、列印版本，甚至檢索器意外碰到的測試環境。Google 在說明標準化程序的官方文件中把這個程序定義為：從一群重複網頁中選出一個最具代表性的標準網址。Google 會把主要內容相同或高度相似的頁面歸為同一組，依收集到的訊號選出內容最完整實用的那一頁當標準頁；標準頁會被檢索得最頻繁，其他重複頁的檢索頻率較低。評估內容與品質時，Google 也以標準頁為主要依據。站上另一篇整理 Google 對重複內容建議的文章補充了重複內容的全景判斷，可以搭配閱讀。
什麼時候值得明確指定？官方文件列出四個常見原因：指定搜尋結果要顯示的網址、把重複網頁各自收到的連結與訊號整併到偏好版本、簡化成效追蹤的指標口徑，以及避免檢索時間浪費在重複頁面上。反向的疑慮也常見：重複內容本身並非處罰，Google 說明站上出現部分重複內容屬於正常現象，也不違反垃圾內容政策；真正該處理的，是同一內容被大量不同網址存取、造成使用者困惑而且成效難以追蹤的情況。
關鍵性質在於：canonical 是你向搜尋引擎表達的偏好，屬於提示，不是必然執行的指令。多數時候 Google 會照做，但當其他訊號與你的宣告矛盾，或 Google 判斷另一個版本對搜尋者更合適時，它可能選擇不同的標準網址，例如行動裝置搜尋時顯示行動版頁面。Google SearchLiaison 在 2024 年 1 月說明聯合發布內容的處理原則時，也順帶點出 canonical 與 noindex 的本質差異：
Canonical means effectively “don’t list the other thing” as a duplicate when the content is often not a full or near duplicate across domains. Noindex does the same thing—don’t list the other content. And there are no complications involved. It’s a directive; canonical is a…
— Google SearchLiaison (@searchliaison) January 31, 2024
幾個常見名詞指涉的是同一個機制的不同側面：canonical tag 指那個 link 元素本身；canonical URL（標準網址）指被指向的目標網址；canonical link 是元素的完整寫法；rel=canonical 則是屬性值。看文件或外掛設定時把它們當同一件事理解即可。如果你偏好用影片建立整體概念，Google Search Central 的 SEO Mythbusting 系列在 2020 年 8 月用一整集談標準化的常見誤解：
Canonical tag 怎麼寫：三種宣告管道與語法細節
Google 支援三種宣告標準網址的管道：HTML 的 link 元素、HTTP 標頭，以及把標準網址放進 Sitemap。Google 的指定標準網址文件依訊號強度把重新導向列在最前，接著是同屬強烈訊號的 rel=canonical 註解，Sitemap 則是較微弱的訊號；文件同時提醒這些方法可以疊加使用，指向一致時效果更強。實作時，HTML link 與 HTTP Link 標頭宜擇一管理，避免重複維護造成衝突；Sitemap 可以搭配，內部連結也應指向相同的標準網址。
管道一：HTML 的 link 元素，適用於絕大多數網頁
在重複網頁的 head 區段加入指向標準網址的 link 元素，例如偏好網址是綠色洋裝商品頁的 https 版本時寫成：
<head>
<title>綠色洋裝｜Example 服飾</title>
<link rel="canonical" href="https://www.example.com/dresses/green-dress/" />
</head>四個細節決定這行元素有沒有生效。href 一律使用絕對網址，包含 https 與完整網域；Google 雖然支援相對路徑，但官方明白不建議，因為相對路徑在環境搬移時容易出事，例如測試站被檢索後，相對路徑會把標準網址算到錯誤的網域上。元素必須出現在有效的 head 區段內，head 本身壞掉時整個註解會被忽略。被指向的標準頁本身也建議放一個指向自己的自我參照 canonical，把「我就是標準頁」講得再明確一點，自我參照能讓標準頁的偏好更明確。優先在伺服器回傳的 HTML 中輸出正確值；若 JavaScript 也設定 canonical，必須與原始 HTML 一致，不要先輸出錯誤網址再依賴腳本修正。這個管道能對應的重複網頁數量沒有上限，代價是網站規模變大、網址經常調整之後，對應關係的維護會愈來愈費工；官方的比較表也提醒它只作用於 HTML 網頁，PDF 這類檔案請改走 HTTP 標頭。
管道二：HTTP 標頭，PDF 等非 HTML 檔案的解法
link 元素只能放進 HTML，PDF、Word 這類文件沒有 head 可以用，這時改在 HTTP 回應標頭宣告，格式依照 RFC 5988 的 link 標頭：
HTTP/1.1 200 OK
Link: <https://www.example.com/white-paper.pdf>; rel="canonical"這個管道不會讓檔案變大，能對應的數量也沒有上限，代價是需要能改伺服器或應用程式的回應設定，網址經常變動時維護成本較高。Google 僅在網頁搜尋結果支援這個方法，標頭裡同樣要使用絕對網址。同一份內容以 PDF 與 docx 兩種格式發布時，就是靠它指定哪個檔案版本是標準。
管道三：把標準網址放進 Sitemap
Sitemap 中列出的每個網址，都代表你建議的標準網頁。對頁面數量龐大的網站來說，這是最容易實作與維護的方式，也很適合順便告訴 Google 你認為站上哪些網頁最重要。它的限制是訊號強度不如 rel=canonical，Google 仍要自行根據內容相似度判斷哪些頁面互為重複，因此實務上常把它當作輔助，與 link 元素或重新導向搭配，前提是所有管道指向的網址必須一致。常見的誤解是把 Sitemap 當完整解方；它只表達你偏好哪些網址，不會阻止重複網址被檢索，參數變體與篩選組合仍要靠 canonical 或重新導向收束。
語法層面還有一個容易踩的陷阱：在 canonical 元素上加上 hreflang、lang、media 或 type 屬性時，Google 會把這個註解視為建議替代版本而忽略，不會用於標準化。要宣告行動版或不同語言版本，正確做法是改用 link rel=alternate 搭配 hreflang 或 media 屬性。RFC 6596 對 canonical link relation 的定義也值得工程同仁讀一次，其中對分頁與內容超集的邊界有明確規範，後面談分頁時會用到。
Google 怎麼選擇標準網址：訊號強度與相互印證
把宣告寫對只是輸入端，理解 Google 的選擇邏輯才能預期結果。Google 會綜合多種訊號判斷標準網址：重新導向、rel=canonical 註解、Sitemap 中出現的網址、頁面透過 https 還是 http 提供，以及 hreflang 叢集內的相互指向。幾個預設傾向值得記住：在 https 與 http 之間，Google 偏好 https，除非 https 版本憑證無效、含不安全的相依資源、把使用者導回 http，或它的 canonical 反而指向 http 頁面。在 hreflang 叢集中，Google 傾向選擇叢集內的網址，而不是落在叢集外的版本。站內連結也扮演印證角色，官方建議內部連結一律連到標準網址本身，整站一致的連結習慣能讓 Google 更容易讀懂你的偏好。
2019 年 9 月 Google Search Central 發布的 AskGoogleWebmasters 影片，用五分鐘說明挑選標準網址的考量，適合當作這一節的總結：
如果你的宣告沒有被採用，原因多半不在語法：通常是其他訊號的合力指向了別頁，或 Google 認為另一個版本的內容對搜尋者更完整。判斷與處理的完整思路，站上為什麼 Google 會無視 canonical 標籤一文有深入拆解，本篇先記住結論：訊號一致比單點宣告更有力量。
連結指向哪個版本，Google 也會納入評估，但不能只憑造訪量推論標準網址。若出現非預期的跨網域標準網址，應依官方排解文件檢查複製內容、伺服器設定與網站入侵跡象。大規模搬移網址時還有替代名稱的概念：Google 會持續追蹤舊網址與新網址，就算新網址已建立索引，使用者查詢暗示更信任舊網址時，結果頁仍可能顯示舊網址，隨著使用者習慣新網域會自然消退，無須人工介入。
其他搜尋引擎的態度也值得知道。Bing 在 2009 年 2 月與 Google、Yahoo 共同宣布支援這個屬性時就表明，會把它當成提示而非命令，並在當時規範 href 必須在同一網域內，允許跨子網域。這份公告說明的是當時的支援範圍；實作 Google 的跨網域標準網址時，仍應以 Google 現行文件為準。
五大使用時機：什麼情況該設 canonical tag
下列五種情境常遇到標準網址問題，但處理方式不同。需要保留、內容相同或高度相似的版本，可以使用 canonical；不同內容的分頁應各自設定標準網址，聯合發布則要先確認是否適合合併，不能只看網址形式決定。
時機一：https、www 與尾斜槓等網址變體並存
最經典的情境是同一個頁面可以透過多種網址形式存取：https 與 http、有 www 與沒有 www、結尾有無斜槓。這些版本對使用者看起來一樣，對搜尋引擎卻是完全不同的網址。處理順序有講究：若是舊網址確定不再使用，直接用 301 重新導向合併最乾淨；若一時無法全面導向，先在每個變體頁放上指向偏好版本的 canonical。測試環境與內部預覽網址也屬於這一類，官方文件甚至把「檢索器意外存取示範版本」列為重複內容的常見來源；上線前用密碼或 IP 限制把 staging 擋在檢索之外，比事後補 canonical 更根本。
時機二：追蹤參數與篩選排序產生的重複組合
電商與內容站常見的困境：同一個商品頁帶著 gclid、utm 或 session 參數被分享出去，列表頁加上排序、顏色、價格篩選後衍生出數十種組合。這些網址的內容高度相似，全數索引會吃掉爬取預算，官方文件列出的設定原因之一，就是避免把檢索時間浪費在重複版本上。處理原則：追蹤參數或排序未改變主要內容時，可指向對應的乾淨網址；篩選後若有獨立內容與搜尋需求，就要另行評估是否保留索引，不能一律指回基準頁。Google 的篩選導覽指南也提醒，canonical 對減少檢索的效果較慢，不能代替檢索控制。Bing 曾在 2012 年介紹Bing Webmaster Tools 的 URL Normalization 功能，用來指定可忽略的參數；這是歷史資料，不能據此認定現在仍有相同的操作介面。該文也提醒，搜尋引擎仍會回訪 canonical 來源頁以確認目標是否變動，參數的組合愈多，這種回訪的成本愈高。減少變體也可以從源頭做起：站內連結一律使用乾淨網址、篩選器改用不產生可檢索網址的互動方式，重複組合少了，canonical 只需要接住外部帶進來的變體。
時機三：行動版與 AMP 等替代版本
同時提供 m.example.com 行動版與桌機版的網站，行動版頁面應 canonical 指向對應的桌機版，桌機版則用 link rel=alternate 搭配 media 屬性宣告行動版位置，這組雙向宣告是官方文件給出的標準做法。AMP 頁面同樣遵循官方指南，把標準頁與 AMP 版本的關係分別標示。現在多數網站已走向同一網址的自適應設計，這個情境的重要性下降，但仍在維護獨立行動版或 AMP 的網站，仍應確認雙向宣告正確，讓搜尋引擎辨識版本關係。檢查時兩個方向都要確認：只有行動版單方面指向桌機版、桌機版缺少 alternate 宣告時，Google 需要更多線索才能確認兩個版本的關係。
時機四：跨網域的聯合發布內容
內容授權給媒體或合作平台聯合發布時，許多發布方會要求「幫我加 canonical 指向你們」。Google 現行排解文件不建議以 canonical 處理聯合發布內容：聯合發布的兩個版本通常經過改寫、加上不同的導覽與版面，內容差異往往大到不構成完全重複，用 canonical 反而容易造成混淆；官方建議的有效解法是由合作夥伴封鎖轉載版的索引。SearchLiaison 在 2024 年 1 月對此有過完整說明：
You can reach that larger audience just fine at the syndication site that has visitors who come to it, who they may email, social share, etc. You can also choose to let them appear in search results, if you want. But if you tell them to use a canonical, you’re signaling to us…
— Google SearchLiaison (@searchliaison) January 31, 2024
實務上的談判籌碼很清楚：如果授權合約允許，請合作方在轉載版使用 noindex，並允許 Google 檢索，才能讀取這項索引指令；robots.txt 的檢索封鎖不能可靠取代 noindex；如果對方堅持保留索引，至少確認轉載版加上指向原文的連結，並接受兩個版本在結果頁並存的可能。想單靠自己網站上的設定去控制別人網站的排名，超出了 canonical 的能力範圍。
時機五：分頁式內容
分頁是最容易做錯的情境。把第二頁以後的所有分頁 canonical 都指到第一頁，等於告訴搜尋引擎「後面幾頁只是第一頁的重複」，可能讓後續分頁的內容無法被正確辨識與索引。RFC 6596 對此有明確規範：各分頁可以指向包含全部內容的彙整頁（內容超集），但不應該指向第一頁，因為那樣會造成內容損失。Google 的分頁指南明確要求每個分頁使用自己的標準網址，不要全部指向第一頁。分頁之間再靠可檢索的翻頁連結串聯；這讓各頁有機會被索引，仍不保證一定收錄。
Canonical 和 301 重新導向怎麼選
兩者的根本差異在使用者體驗：301 重新導向會把訪客與搜尋引擎一起送到目標網址，canonical 則讓兩個頁面繼續存在，向搜尋引擎提示你偏好的搜尋結果網址。由此推出選擇原則：舊網址確定淘汰、沒有人需要再連到它，用 301；兩個版本都必須繼續被使用者存取（行動版與桌機版、列印版、帶參數的分享連結），用 canonical。訊號強度上 301 更強，Google 的重新導向文件說明索引管道會把永久重新導向視為「目標應為標準網址」的明確信號；301 與 308 都屬永久，302 與 307 屬暫時，暫時重新導向通常保留來源網址作為標準版本，Google 將它視為較弱的目標標準化訊號，0 秒的 meta refresh 會被視為永久。
| 情境 | 建議做法 |
|---|---|
| 舊網址永久淘汰（改版、換網域、刪除舊分類） | 301 永久重新導向 |
| 同一頁面的 https／www 變體 | 301 導向偏好版本，或 canonical 指向偏好版本 |
| 追蹤參數或排序版本需保留，主要內容相同 | canonical 指向對應的乾淨網址；內容不同的篩選頁另行評估 |
| 行動版、列印版等替代版本需並存 | 相同內容可指向主版本；獨立行動版另依官方指南設定 alternate |
| 季節性活動頁暫時換位置 | 302 暫時重新導向，表達之後會回復原位置 |
兩者可以分工，但不要打架。同一個頁面又被 301 導向 A、又有 canonical 指向 B 時，等於同時發出兩個不同方向的訊號，Google 只能自行猜測你的偏好。各種重新導向的完整語法與伺服器設定，站上301 與 302 重新導向的比較文有完整整理；重複內容的整體處理架構，包含何時該合併、何時該保留，則可參考重複內容對 SEO 影響與解法的專文。Google 官方的重新導向文件也值得直接讀一遍，特別是搬站時的注意事項。
大規模搬站時兩者是前後手：搬移當下以 301 把每個舊網址指到對應新網址，讓索引與訊號逐步轉移；新站上線後，確認每頁的自我參照 canonical 都換成新的絕對網址，內部連結也改連新網址，避免舊訊號持續把自己拉回舊版。看到結果頁仍出現舊網址時先別急著重做，前述的替代名稱機制會讓它自然退場。
WordPress 與常見 CMS 的 canonical 設定
用 WordPress 的站長第一個該知道的事：核心已經幫你做了一部分。文章與固定頁面這類單一內容頁，WordPress 會自動輸出指向該頁網址的自我參照 canonical，靠的是 rel_canonical 與 wp_get_canonical_url 兩個核心函式，不需要佈景或外掛再補一行。同一時間，核心的 redirect_canonical 機制會把常見的網址變體，例如與網站偏好不一致的 www 形式或不符合固定連結設定的網址，用 301 導回正確版本。有些開發文件會教你關掉這個 canonical redirect，一般網站不需要也不建議這麼做，只有在特定 AJAX 載入或無限捲動的實作下，分頁網址被錯誤導回第一頁時才考慮，而且要明白後果是變體網址不再自動合併。
核心沒有涵蓋的部分是首頁、分類、標籤與日期彙整頁，這些頁面預設不輸出 canonical。WordPress SEO 外掛與設定可以補上這塊：Rank Math、Yoast 與 AIOSEO 都會為全站每種頁面類型輸出 canonical，並在每篇文章的編輯畫面提供 canonical 網址欄位，讓你對單一頁面手動覆寫。用外掛時只要確認一件事：全站只有一個來源在輸出 canonical。佈景主題自己硬寫一行、外掛又輸出一行的雙重宣告，是 CMS 環境最常見的錯誤之一。
Shopify 的站長則有另一組注意事項。佈景的 theme.liquid 預設以 {{ canonical_url }} 液態物件輸出標準網址，商品頁即使從 /collections/summer/products/shirt 這類系列路徑進入，標準網址仍應回到 /products/shirt 根路徑；更換佈景或客製 head 時要保留這個行為，別把系列路徑寫進 canonical，否則同一件商品會依進入路徑裂成多個標準頁。
不用 CMS、自己管理 head 的網站，做法取決於你的樣板系統：在每個頁面樣板把標準網址組成絕對網址後輸出，伺服器端組好再回傳，避免依賴前端腳本插入。官方文件對無法直接改 HTML 的平台（Blogger、Wix 這類）給的建議很實際：到平台的說明文件搜尋修改 head 的方法，通常都有對應的設定項。佈景或子佈景的 functions.php 也可以掛 wp_head 鉤子輸出，與範本檔解耦、升級時比較不容易遺失；無論用哪條路，收尾都用原始碼檢查確認每種頁面都恰有一行 canonical。
七種讓 canonical 失效的常見錯誤
語法只有一行，錯誤卻花樣繁多。下面七種是實務中最常見、也最常被工具抓到的問題，可以先依序檢查，再納入完整的技術 SEO 健檢流程：
- 同一頁出現多個 canonical。多半是佈景與 SEO 外掛同時輸出，或範本被重複 include。多個宣告互相抵觸時，等於把選擇權交回搜尋引擎，宣告形同失效。Lighthouse 的 SEO 稽核把這列為明確的失敗條件，拿它掃一遍能快速定位來源。
- href 使用相對路徑。程式碼看起來簡潔，但搬到測試網域或 CDN 之後，相對路徑解析出的標準網址會跟著錯，官方明確建議一律使用絕對網址。
- canonical 與 noindex 混用。頁面自身標了 noindex 又宣告 canonical 指向別頁，或把 canonical 指向被 noindex、robots.txt 封鎖的頁面，都是一邊說他是標準、一邊說他不可索引的矛盾訊號。官方最佳做法提醒：robots.txt 不是標準化工具，要移除分身靠 canonical 或重新導向即可，不需要 noindex。
- 宣告形成迴圈或鏈條。A 指向 B、B 又指向 A 的迴圈，以及 A 指向 B、B 再指向 C 的鏈條，都會讓最終標準頁變得模糊，也增加搜尋引擎的解析成本；每個重複頁都應直接指向最終的標準頁。
- 分頁全部指向第一頁。可能讓後續分頁被錯當成第一頁的重複，影響各頁內容的辨識與索引，RFC 6596 已明言這會造成內容損失，正確做法是各頁自我參照。
- 把 hreflang、media、type 等屬性加在 canonical 元素上。這種寫法會被 Google 當成替代版本建議而忽略，語言與裝置版本應該用 link rel=alternate 宣告。
- canonical 指向別人的網域。除了聯合發布的誤用，最危險的情況是網站被入侵後，head 或 HTTP 標頭被植入指向垃圾網站的 canonical，Google 的排解文件把這列為標準化問題的常見原因，發現排名集體異常時記得檢查原始碼。
檢查方法：確認 Google 實際採用了哪個網址
檢查分兩層：先確認你送出的宣告正確，再確認 Google 實際採用。第一層用瀏覽器就能做：在目標頁面檢視原始碼或開發人員工具，搜尋 rel=”canonical”，確認只出現一次、網址是絕對路徑且指向你偏好的版本；宣告在 HTTP 標頭的檔案，用 curl 加 -I 參數檢視回應標頭。要批次檢查整個網站，把爬蟲工具設定為收集 canonical 欄位，掃完匯出成表，重複宣告與指向異常會直接浮出來。不進 Search Console 也能做粗檢：在 Google 搜尋 site: 加確切網址，可初步觀察該網址是否出現在搜尋結果，但未顯示不代表未索引，索引狀態仍以網址檢查為準；官方說明也示範用 site: 搭配主題字詞搜尋，觀察結果頁顯示的是哪個版本的網址。
第二層看 Google 的實際選擇，工具是 Search Console 的網址檢查。官方的網址檢查工具說明指出，檢查任一網址時，報告會同時列出「使用者宣告的標準網址」與「Google 選擇的標準網址」兩個欄位，兩者不一致就是你該關注的訊號。官方也說明了背後的相似度邏輯：重複網頁必須與標準網頁相似，如果宣告的標準網頁與目前網頁並不相似，Google 就不會採用該宣告。
網頁索引報表裡，三種與標準網址直接相關的狀態值得認得。「替代頁面（有適當的標準標記）」通常代表 Google 採用了另一個標準頁；若標準頁符合你的預期，無須為了收錄重複頁而修改設定。「重複網頁；使用者未選取標準網址」代表 Google 未取得使用者明確指定的標準網址，已自行挑選代表頁。先看 Google 的選擇是否符合需求；需要調整時，再讓 canonical、內部連結與 Sitemap 一致指向偏好版本。「重複網頁，Google 選擇的標準網址與使用者宣告的不同」則代表有宣告但被推翻，常見原因是內部連結與 Sitemap 指向另一個版本，或宣告與其他訊號矛盾；順手檢查 Sitemap 只提交標準網址，別讓參數變體混進去。官方對這份報表的說明還有個重要提醒：重複網址未被索引通常是好現象，代表 Google 已找到並索引你的標準頁，報表的樣本清單一次最多顯示一千個網址。
發現 Google 選了不同的標準網址時，處理順序是：先用網址檢查看 Google 選了誰，再判斷 Google 的選擇對搜尋者是否其實更合適；確認是技術設定問題就修掉對應的錯誤；修正後可用網址檢查裡的要求建立索引加快重新評估，但這個功能有配額，保留給重要網址。Google 的標準化排解文件補充了一個時間預期：即使修正完成，Google 也可能把重複叢集中的網頁保留最多兩週，內容差異愈明顯，拆分速度愈快。操作 Search Console 的完整流程，站上的Search Console 教學有逐步截圖說明。
常見問題
canonical tag 和 canonical URL 有什麼不同？
canonical tag 指的是 head 裡那個 link 元素本身，canonical URL 則是它指向的標準網址，一個是宣告工具、一個是被指定的目標。文件與外掛介面常混用這兩個詞，看語境理解即可。實作時要分開檢查：元素有沒有寫對是一回事，href 指到的網址是否真的是你要的版本，是另一回事。兩者都正確，機制才算完整發揮。
canonical tag 會直接影響排名嗎？
不會直接影響。canonical 的作用是整併重複網址的訊號與索引，讓外部連結與成效指標歸到同一個網址，屬於技術整併而非排名加成。真正與排名有關的，是標準頁被正確索引、訊號沒有被重複版本分散，這也是設定的價值所在。把它當成排名開關到處設定，反而容易出狀況。
WordPress 一定要裝外掛才能設定 canonical 嗎？
不一定。WordPress 核心會在文章與固定頁面自動輸出指向自己的 canonical，redirect_canonical 機制也會把 www 等常見變體導回正確網址。需要涵蓋首頁與分類彙整頁，或想對特定頁面手動覆寫時，才需要 SEO 外掛的 canonical 欄位。裝了外掛後，確認全站只有一個輸出來源。對多數網站來說，裝一個 SEO 外掛仍是最省事的完整解。
canonical 可以指向另一個網域嗎？
語法上可以，RFC 6596 允許跨網域的宣告，Google 會把它當提示評估。但搜尋引擎對跨網域 canonical 一貫保守，聯合發布內容尤其如此，官方建議改由轉載方封鎖索引。若發現網站冒出指向陌生網域的 canonical，要懷疑被入侵，立即檢查原始碼與 HTTP 標頭。自己要宣告跨網域時，先確認內容確實構成重複。
為什麼 Google 沒有採用我指定的 canonical？
因為 canonical 是提示，Google 會與重新導向、內外部連結、https、hreflang 等訊號一起評估。常見原因包含兩頁內容差異太大、其他訊號一致指向別頁、宣告本身有語法問題。用網址檢查看 Google 選了誰，判斷它的選擇是否其實更合適，Google 對特定重複叢集的說明是，修正內容後仍可能保留頁面最多兩週；這不是一般索引更新的保證期限。若兩頁內容其實不同，先處理差異再談標準化。
canonical 和 301 重新導向應該怎麼選？
看舊網址還需不需要存在。確定淘汰、使用者不必再連到它，用 301，訊號強且訪客直接被送到目標；兩個版本都必須存在，例如行動版、列印版或參數變體，用 canonical，頁面照常開啟，搜尋引擎再依訊號選擇標準版本。兩者不要指向不同目標，那等於自相矛盾。臨時性的活動頁則可用 302 保留原網址。
每一頁都放自我參照的 canonical 有必要嗎？
需要獨立索引的標準頁，可以設定指向自己的 canonical；重複頁則應指向對應的偏好版本。自我參照有助表達「本頁就是標準」，但不能保證 Google 一定採用。多數 CMS 與 SEO 外掛預設就是這樣輸出，不需要手動逐頁添加，確認機制有開啟即可。分頁內容也適用各頁自我參照的同套原則。
怎麼檢查 canonical tag 有沒有寫錯？
單頁檢查看原始碼搜尋 rel=”canonical”，確認只出現一次、是絕對網址、指向偏好版本；HTTP 標頭宣告用 curl 檢視回應。要看 Google 實際採用誰，用 Search Console 網址檢查比對「使用者宣告」與「Google 選擇」兩個標準網址欄位。整站批次稽核可以交給 Lighthouse 或爬蟲工具。發現錯誤時修完，再用網址檢查要求重新評估。
討論與提問