Canonical 標籤是什麼？讀懂 Google 選取標準網址的邏輯
很多人設了 canonical 標籤，卻發現 Google 並沒有採用。問題通常不在語法，而在信號衝突。這篇解釋 rel canonical 為何只是「建議」、JavaScript 注入的隱藏陷阱，以及如何用 GSC 診斷 canonical 是否被正確採用。
Canonical 標籤是什麼？讀懂 Google 選擇標準網址的邏輯
同一份內容，卻出現在三個不同的 URL 上。Google 爬蟲抵達時，要索引哪一個？這個問題就是 canonical 標籤想解決的事。
rel="canonical" 標籤是一個放在 HTML <head> 區塊的 link 元素，用來告訴搜尋引擎：「這幾個 URL 裡，這個才是你應該索引的版本。」它的語法長這樣：
<link rel="canonical" href="https://example.com/product/white-shirt/" />但有一件事多數人沒說清楚：canonical 標籤對 Google 來說是「強烈建議」，不是指令。Google 會考量你的聲明，但保留最終選擇權。
rel="canonical" 的語法規則與常見放錯位置
canonical 標籤有幾個硬性要求，放錯就失效：
- 必須放在頁面的
<head>區塊，不能放在<body> - href 使用絕對 URL，包含 https:// 和完整路徑
- 不要用相對路徑（如 href="../product/"），不同爬蟲解析方式不同
- 一個頁面只放一個 canonical。多個 canonical 標籤衝突時，Google 通常忽略全部
最常見的錯誤是 canonical 出現在 <body> 裡，或被插入 AMP HTML 的錯誤位置。這些情況 Google 不會採用這個信號。
Google 怎麼決定 canonical？不只看你的聲明
這裡是競品文章普遍跳過的機制層。Google 選擇 canonical URL 時，會把 rel="canonical" 當作多個信號之一，同時評估：
- rel="canonical" 聲明（你的聲明，但不是唯一依據）
- 內部連結：站內哪個版本被連結最多次？Google 用連結數量判斷「這個版本對你自己比較重要」
- 外部連結：如果外部網站都連向非 canonical 的那個 URL，Google 傾向採用外部更認可的版本
- 協議偏好：HTTPS 版本優先於 HTTP 版本
- 網址簡潔度：較短、沒有不必要參數的 URL 更容易被選為 canonical
- Sitemap 收錄：sitemap.xml 中出現的 URL 版本是一個弱信號
這就是為什麼有時候你設了 canonical 指向頁面 A，Google 仍然索引頁面 B。從 Google 的角度看，它只是在綜合判斷後做了不同的決定。
官方說明可參考：Google Search Central 的 canonical 說明文件，裡面明確指出 canonical 是「強信號」而非「強制指令」。
從這個角度看，canonical 設定的工作不只是「加一行標籤」，而是要讓你的連結結構和你的 canonical 聲明一致。如果連結都指向 A，canonical 也指向 A，Google 採用的機率就很高。
Google 選取 Canonical 的信號優先序示意圖：rel="canonical" 是強烈建議，但 Google 保留最終選擇權
什麼情況需要設 Canonical 標籤？六種常見場景
不是所有網站都有大量重複頁面，但以下六個場景幾乎在每個中大型網站上都會出現。
場景一：電商商品的規格和顏色變體
白色 T-shirt 和黑色 T-shirt 各有一個 URL，商品描述卻幾乎相同。這是電商最典型的 canonical 需求。做法是讓所有規格頁的 canonical 指向主商品頁（或最具代表性的版本），讓 Google 集中索引一個頁面，把排名信號集中。
場景二：UTM 參數與動態篩選條件
行銷活動的追蹤連結（?utm_source=facebook）和電商分類的篩選條件（?color=red&size=M）都會生成新的 URL，但內容和原始頁面完全相同。不設 canonical 的情況下，Google 可能把這些都當成不同頁面來處理，稀釋排名信號。
場景三：HTTP/HTTPS 與 www/non-www 的混用
如果你的網站沒有強制跳轉，http://example.com、https://example.com、http://www.example.com、https://www.example.com 可以是四個不同的「版本」。設定 canonical 指向你的標準版本（通常是 https://），加上 301 轉址作為雙重保障。
場景四：同一篇文章被多個分類路徑存取
部落格文章可能同時出現在 /blog/post-title/ 和 /category/seo/post-title/。如果兩個 URL 都能訪問同一篇文章，需要決定一個「正版」並讓另一個指向它。
場景五：跨平台重複發布
把文章同步發布到 Medium、方格子、Vocus 時，這些平台通常允許設定 canonical 指向你的原始頁面。設定後，即使被轉載，搜尋引擎的排名信號仍集中在你的網站上，而非轉載平台。
場景六：AMP 頁面與原始頁面的配對
AMP 頁面需要雙向設定：原始頁面加上 <link rel="amphtml" href="https://example.com/amp/post/">，AMP 頁面加上 <link rel="canonical" href="https://example.com/post/">（指回原始頁面）。這樣 Google 才知道 AMP 頁是原始頁的加速版本，不是獨立內容。
從 SEO 策略層面看，這六種場景共同的問題是「排名信號分散」。如果你在意SEO 排名因素如何累積，canonical 設定其實就是在做「把信號集中到一個頁面」的工程。
六種常見需要設定 Canonical 標籤的情境整理
Canonical 標籤怎麼設定？三種方式與最常被遺忘的規則
設定方式有三種，對應不同技術環境，但有一個所有情況都適用的規則最常被跳過。
方式一：直接寫入 HTML <head>（自建站或完全控制原始碼）
最直接的方式，找到你的頁面模板，在 <head> 區塊加入：
<link rel="canonical" href="https://example.com/your-page-url/" />對於靜態網站生成器（如 Astro、Next.js、Gatsby），通常在頁面的 head 元件裡處理，可以動態帶入當前頁面的完整 URL。
方式二：透過 CMS 外掛設定
- WordPress + Yoast SEO：每篇文章的 Yoast 設定面板底部有「進階」頁籤，可手動指定 canonical URL。預設狀況下 Yoast 會自動產生指向自身的 canonical，通常不需要手動調整
- WordPress + RankMath：類似位置，在「進階」頁籤中
- Webflow：頁面設定中有 SEO 設定區域，可填入 canonical URL
方式三：讓每個頁面都有指向自身的 canonical（最常被遺忘的規則）
即使你的頁面目前沒有任何已知的重複版本，仍然建議加上指向自身的 canonical（self-referencing canonical）：
<link rel="canonical" href="https://example.com/current-page/" />原因在於你無法完全控制自己頁面的所有 URL 版本。當有人在連結裡加了 UTM 參數、當 CDN 快取了一個奇怪的版本、當使用者分享了帶有 session ID 的連結，這些「意外版本」就出現了。
自我 canonical 的作用是預防性的，讓 Google 在遇到任何版本的你的頁面時，都有一個明確的指引。Google 自己也建議這樣做，這是成本很低、但能有效避免意外 canonicalization 問題的做法。
實際操作上，如果你用 CMS 外掛，自我 canonical 通常是預設行為。自建站的話，確認模板裡有動態帶入當前頁面 URL 的邏輯。
設了 Canonical 但 Google 沒採用？五個原因和診斷流程
這個問題比你想像中常見。Google Search Console 裡看到「Google 選取的 canonical」與你設的不同，並不代表你的設定壞掉了，而是 Google 在綜合信號後做了不同判斷。
Google 忽略 canonical 的五個常見原因
在調整設定之前，先搞清楚是哪個原因：
- 信號衝突：canonical 指向頁面 A，但站內和外部連結都指向頁面 B。Google 更傾向跟隨連結投票，而不是標籤聲明
- 內容不夠相似：Google 判斷兩個頁面不是真正的重複內容，所以不需要 canonicalize，選擇分別索引
- 語法錯誤：href 用了相對路徑、canonical 放在 body 而非 head、或同頁面有多個衝突的 canonical 標籤
- 爬取頻率低：你剛改了 canonical 設定，但 Google 還沒重新爬取到這個頁面，判斷還在用舊的快取資料
- 外部連結指向非 canonical 版本：如果大量外部反向連結指向另一個 URL，Google 可能認為那個版本更「權威」
JavaScript 注入 canonical 的隱藏陷阱
這個問題在使用 React、Vue、Angular 或 SPA 架構的網站上很常見，但很少被明確討論。
如果你的 canonical 標籤是由 JavaScript 動態寫入 <head>，問題在於 Googlebot 的渲染方式：它先做 HTML parse，把 JS 執行排進一個獨立的渲染佇列。這個佇列的處理可能延遲數天甚至數週。
在 JS 還沒執行之前，Googlebot 看到的是沒有 canonical 標籤的頁面。這段時間內，Google 可能根據其他信號做了自己的 canonical 判斷，後來 JS 執行後才出現的 canonical 聲明可能已經太晚改變 Google 的決定。
解決方法很直接：canonical 標籤永遠用靜態 HTML 輸出，不要依賴 JS 動態注入。如果你的框架支援 server-side rendering，確保 canonical 在 SSR 階段就已經出現在 HTML 裡。
三步驟診斷 canonical 是否被採用
- Google Search Console → URL 檢查工具：輸入你設 canonical 的頁面 URL，看「Google 選取的 canonical」欄位。如果這個欄位顯示的 URL 和你在頁面裡設的不同，表示 Google 做了不同選擇
- 頁面原始碼確認：在瀏覽器打開頁面，Ctrl+U 看原始碼，搜尋 "canonical"。確認標籤存在、在 head 裡、href 是完整的絕對 URL
- 檢查 canonical chain：如果你的 canonical 目標頁本身又 canonical 到另一頁，或者指向一個有 301 轉址的 URL，這個 canonical chain 可能讓 Google 不知道要跟到哪裡
爬取預算與未解決的 canonical 衝突
對有幾千頁以上的網站，這個層面很重要。未解決的 canonical 問題不只影響索引，還影響 Googlebot 對你整個網站的爬取效率。
根據 Google 的爬取預算管理文件，重複 URL 被列為「低價值 URL」的主要類型之一，Googlebot 的目標是盡量減少在這類頁面上的時間，把配額留給新內容和重要頁面。
電商網站的典型情況：10,000 個商品，每個商品有 5 個 URL 變體（顏色、尺寸、排序參數），理論上就有 50,000 個需要處理的 URL。如果這些都沒有 canonical 設定，Googlebot 需要花大量資源判斷哪些是重複的，進而壓縮對新商品頁的爬取頻率。
如果你在用 PageSpeed Insights 做技術優化，爬取效率同樣值得追蹤，canonical 是技術 SEO 的基礎建設之一，而不只是對付重複內容的補救工具。
GSC URL 檢查工具的 canonical 狀態欄位說明：兩欄位不同代表 Google 忽略了你的聲明
Canonical vs. 301 轉址：什麼時候用哪個？
這兩個工具常被混用，但它們的設計目的不同。一句話區分：canonical 讓兩個 URL 都可以訪問，但告訴 Google 哪個才是「正版」；301 讓舊 URL 永遠消失，所有流量和信號都強制轉移到新 URL。
核心差異對比
| 面向 | rel="canonical" | 301 轉址 |
|---|---|---|
| 兩個 URL 是否都可訪問 | 是，都可以打開 | 否，舊 URL 自動跳轉 |
| Google 遵從強度 | 強烈建議，可被覆蓋 | 通常 100% 遵從 |
| 適合的重複類型 | 功能性重複（需要兩個 URL 存在） | 永久性合併（舊 URL 不再需要） |
| 典型場景 | UTM 參數頁、AMP 頁、跨平台發布 | 網站改版、域名更換、內容合併 |
| 風險 | Google 可能忽略聲明 | 301 鏈過長會損失部分 PageRank |
AK Canonical 決策樹：選 canonical 還是 301？
遇到重複 URL 問題，用以下兩個問題決定：
問題一：用戶或系統是否需要保留兩個 URL 都能訪問？
- 需要（如：UTM 追蹤連結需要有效、AMP 頁需要獨立 URL）→ 用 canonical
- 不需要 → 進入問題二
問題二：這個重複是否是永久性的、不會改變的？
- 是永久重複（如：舊網址廢棄、內容合併）→ 用 301 轉址，最終解決問題
- 功能性/暫時性重複（如：URL 參數是系統需求）→ 用 canonical
實務上，我傾向先做 301 轉址，因為它的信號更確定、不會被 Google 忽略。canonical 是在「真的需要保留兩個 URL」的情況下才用。用 canonical 當成 301 的替代品，結果通常不如預期。
技術 SEO 的基礎設定，不知道從哪裡開始盤點？從 canonical 問題到爬取效率，這些通常是排名卡關的隱藏原因。了解我們的 SEO 策略顧問服務，從技術層診斷你的網站實際狀況，找出優先處理的改善點。
AK Canonical 決策樹：兩個問題決定使用 rel canonical 還是 301 轉址
Canonical 標籤常見問題
Canonical 標籤會影響 Google 索引的速度嗎？
canonical 設定本身不會加快索引，但它可以讓 Google 把爬取資源集中在有價值的頁面上，間接改善整個網站的爬取效率。特別是對有大量重複 URL 的網站，清理 canonical 問題後，新內容被索引的速度通常會有改善。
一個頁面可以同時有多個 canonical 標籤嗎？衝突時怎麼辦？
技術上可以存在，但 Google 遇到同一個頁面有多個 canonical 標籤（指向不同 URL）時，通常的做法是忽略全部，然後自行判斷 canonical。這比沒設還糟糕。解決方式：找到重複的來源（通常是兩個不同的 SEO 外掛同時輸出），只留一個。
Canonical 可以跨域指向另一個網站嗎？
可以。跨域 canonical 的典型用途是把自己的網站設成授權來源，讓在其他平台（Medium、合作媒體）發布的相同內容指向你的網站。這樣搜尋引擎的排名信號會集中在你的頁面，而不是第三方平台。不過跨域 canonical 是「弱信號」，Google 可能選擇不採用，尤其是當目標域名的權威性比來源域名低的時候。
Google Search Console 顯示「使用者宣告 canonical 與 Google 選取 canonical 不同」，怎麼辦？
先不要急著「修正」，因為這不一定是問題。Google 選取的版本可能確實是「更好的」選擇。先確認幾件事：Google 選取的那個 URL 是不是你認可的版本？如果是，那沒有問題。如果不是，通常原因是連結結構和 canonical 聲明衝突，需要讓兩者方向一致，而不只是修改 canonical 標籤。
WordPress 用什麼外掛設定 canonical 標籤？
Yoast SEO 和 RankMath 都會自動為每個頁面輸出自我 canonical，大多數情況下不需要手動設定。如果你需要針對特定頁面修改 canonical，在文章/頁面的 SEO 設定面板找「進階」頁籤，裡面有 canonical URL 欄位可以手動填寫。
電商網站的商品頁每一頁都要設 canonical 嗎？
是的，而且應該在模板層統一處理，而不是逐頁手動設定。電商平台（Shopify、WooCommerce）通常有預設的 canonical 邏輯，但需要確認 URL 參數頁（篩選、排序、分頁）是否都正確指向標準 URL。分頁（?page=2）的處理方式需要額外注意，通常不建議 canonical 全部指向第一頁，因為分頁內容是不同的。
AMP 頁面的 canonical 設定和一般頁面有什麼不同？
需要雙向設定。原始頁面加上 <link rel="amphtml" href="AMP頁URL">，讓 Google 知道有加速版本。AMP 頁面加上 <link rel="canonical" href="原始頁URL">，告訴 Google AMP 頁不是獨立內容。如果只設單向，Google 可能把 AMP 頁當成獨立頁面索引，造成重複。
canonical 標籤跟 noindex 可以一起用嗎？
可以，但效果會相互衝突。canonical 說「讓這個頁面被索引但把信號轉到那裡」，noindex 說「不要索引這個頁面」。同時使用的話，多數搜尋引擎以 noindex 為優先，即不索引這個頁面、也不跟隨 canonical 信號。如果你的目標是不索引但轉移信號，應該用 301 轉址，而不是 canonical + noindex 的組合。
如果 canonical 目標頁本身也有 canonical，會形成 canonical chain 嗎？
會。A canonical → B，B canonical → C，這就是一條 canonical chain。Google 通常能跟隨 2 層以內的 chain，但超過 2 層後 Google 可能選擇 chain 中間的某個 URL 作為 canonical，而不是跟到最終目標。另一個問題是 canonical 指向一個有 301 轉址的 URL，Screaming Frog 會顯示「canonical to redirect」的警告。最好的做法是讓 canonical 直接指向最終目標，跳過所有中間跳轉。
Canonical 可以解決抄襲問題嗎？
不能，但常有人這樣期待。canonical 標籤只對「把 canonical 設上去的頁面」有效。如果別的網站抄你的內容，那個頁面的 canonical 是由對方控制的，對方不會設成指向你。真正幫助的方法是確保你的原始頁面比抄襲頁面更早被 Google 爬取和索引，以及透過 Google 的內容侵權申訴流程處理。