Canonical 標籤完整教學：Google 不採用的 5 個常見原因與診斷修正
Canonical 標籤是 Google 選擇代表網址的重要信號，但可能因信號衝突或實作錯誤而不被採用。本文整理適用場景、設定方法、官方信號與 GSC 診斷流程。
最後更新：
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，降低測試站或錯誤 base URL 造成的解析風險
- Google 支援相對 URL，但官方仍建議使用較安全的絕對 URL
- 一個頁面只輸出一個一致的 canonical；多個互相衝突的聲明會製造歧義，Google 可能改選其他代表頁
最常見的錯誤是 canonical 出現在 body 裡，或被插入 AMP HTML 的錯誤位置。這些情況 Google 不會採用這個信號。
Google 怎麼決定 canonical？不只看你的聲明
這裡是 canonical 機制中最常被忽略的一層。Google 選擇 canonical URL 時，不會只讀你的 rel="canonical" 聲明，而是把它當作多個信號之一，同時評估：
- 重新導向：當舊 URL 已停用時，永久重新導向是強信號
- rel="canonical" 聲明：也是強信號，但不是強制指令
- Sitemap 收錄：sitemap.xml 中的 URL 是較弱的信號
- 一致的內部連結：站內連結應直接指向你偏好的代表 URL，避免與 canonical 聲明互相矛盾
- HTTPS 與 hreflang 一致性：Google 通常偏好 HTTPS；多語系頁面應讓同語言版本落在同一 canonical 群組
- 頁面必須可供 Google 存取與處理，因此爬取與索引機制仍是更上層的判斷前提
這就是為什麼有時候你設了 canonical 指向頁面 A，Google 仍然索引頁面 B。從 Google 的角度看，它只是在綜合判斷後做了不同的決定。官方說明可參考：Google Search Central 的 canonical 說明文件，裡面明確指出 canonical 是「強信號」而非「強制指令」。 延伸閱讀：robots.txt 檔案。
從這個角度看，canonical 設定的工作不只是「加一行標籤」，而是要讓你的連結結構和你的 canonical 聲明一致。如果連結都指向 A，canonical 也指向 A，Google 採用的機率就很高。
什麼情況需要設 Canonical 標籤？六種常見場景
需要設定 canonical 標籤的情況，發生在「同一份內容可以被多個 URL 存取」的時候。常見來源包括高度相似的商品變體、內容不變的追蹤參數、可並存的網域或分類路徑，以及仍在維護的 AMP 配對。跨平台轉載則要另外評估，不能預設 canonical 一定適用。設定前先確認內容是否重複或高度相似、兩個 URL 是否都需保留，再用 canonical 表達偏好的代表頁。
場景一：電商商品的規格和顏色變體
電商商品若有多種規格或顏色，通常每個變體都會有獨立 URL。例如白色 T-shirt 和黑色 T-shirt 各有一個網址，但商品描述、尺寸表與購買區塊幾乎相同，只有顏色選項不同。對 Google 來說，這些頁面是高度重複的內容。
只有當變體頁內容重複或高度相似、而且沒有獨立搜尋價值時，才把它們 canonical 到主商品頁。若顏色、尺寸或型號頁提供不同庫存、內容或搜尋意圖，應評估保留自我 canonical，不能一律合併。
場景二：UTM 參數與動態篩選條件
行銷活動為了追蹤來源，會在網址後面加上參數，例如 ?utm_source=facebook。電商分類頁為了讓使用者篩選顏色或尺寸，也會產生 ?color=red&size=M 這類動態網址。UTM 通常不改變主要內容；篩選參數則可能改變商品集合與搜尋意圖，必須先比較實際頁面，不能一律當成重複內容。
如果沒有設定 canonical，Google 可能把這些帶有參數的網址當成獨立頁面，日積月累就會稀釋排名訊號。對內容不變的追蹤參數，可把 canonical 指回乾淨 URL；對產生獨特且有搜尋價值內容的篩選頁，則應個別決定是否自我 canonical、允許索引或採取其他控制。
場景三：HTTP/HTTPS 與 www/non-www 的混用
網站如果沒有在伺服器端強制統一網域，http://example.com、https://example.com、http://www.example.com 與 https://www.example.com 就可能同時被訪問。四種寫法開啟的是同一份內容，但對搜尋引擎來說是四個不同版本。
做法是選擇一個 HTTPS 標準版本；若其他主機或協議版本已不需要保留，優先用伺服器端永久重新導向直接送往標準版，並讓目標頁使用自我 canonical。這兩個信號可以保持一致，但不能把 canonical 當成重新導向的替代品。
場景四：同一篇文章被多個分類路徑存取
部落格文章常因為內容管理系統的分類設定，同時存在於多條路徑。例如同一篇文章可能透過 /blog/post-title/ 訪問，也可以透過 /category/seo/post-title/ 訪問，兩者顯示的內容完全相同。
此時必須決定哪一個 URL 是「正版」，也就是主要發布路徑，然後讓另一條路徑的 canonical 指向它。如果不指定，Google 會自行選擇代表頁，而它的選擇不一定符合你的內容策略。
場景五：跨平台重複發布
內容發布到 Medium、方格子、Vocus 等平台時，等於在同一時間把文章複製到多個網域。這些平台大多提供 canonical 設定功能，允許你填回原始文章的網址。
跨網域 canonical 技術上可用，但 Google 目前不建議把它當成控制轉載內容的可靠方法，也不保證排名信號一定集中。能控制合作平台時，應優先要求避免索引轉載版或只發布摘要並連回原文，再用 Search Console 驗證實際選擇。
場景六：AMP 頁面與原始頁面的配對
如果網站仍維護獨立 AMP 版本，AMP 與非 AMP 頁面需要依 AMP 規格正確配對。原始頁面需要加入 <link rel="amphtml" href="https://example.com/amp/post/">，AMP 頁面則需要加入 <link rel="canonical" href="https://example.com/post/">，指回原始頁面。
這樣做的目的是讓 Google 明確知道 AMP 版只是原始文章的加速版本，而不是獨立內容。把這個配對邏輯放回六種場景會發現，電商變體、UTM 參數、網域混用、分類路徑、跨平台發布與 AMP 配對，共同問題都是排名訊號被分散。設定 canonical 就是一種收攏訊號的工程，想了解這些訊號如何影響整體表現，可以對照 Google 的 SEO 排名因素如何累積，確認代表頁是否真的集中在最有價值的頁面上。
Canonical 標籤怎麼設定？三種方式與最常被遺忘的規則
設定 canonical 標籤的基本做法，是在網頁的 <head> 中加入一個 <link rel="canonical"> 元素，明確指定這個頁面的標準網址；對自建站來說，直接在模板中輸出即可，若使用 CMS，則可在 SEO 外掛的進階欄位填入。無論採用哪一種方式，都需要記得一個最常被遺忘的規則：每個頁面都應該加入指向自身的 canonical，用來處理 UTM 參數、session ID、CDN 快取等意外產生的重複版本。
方式一：直接寫入 HTML 的 <head>（自建站或完全控制原始碼）
當你擁有網站原始碼的完全控制權時，最直接的做法是在頁面模板的 <head> 區塊中，加入一行 canonical 標籤，例如：<link rel="canonical" href="https://example.com/your-page-url/" />
對於靜態網站生成器，例如 Astro、Next.js、Gatsby，通常在頁面的 head 元件裡處理，可以動態帶入當前頁面的完整 URL，避免每頁手動填寫。
方式二：透過 CMS 外掛設定
在 WordPress 上，如果使用 Yoast SEO，每篇文章的設定面板底部有「進階」頁籤，可以手動指定 canonical URL。預設狀況下 Yoast 會自動產生指向自身的 canonical，因此多數文章不需要手動調整。
Rank Math 的作法類似，在文章編輯頁的「進階」頁籤中也可以找到 canonical 欄位。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」與你在頁面裡設定的 canonical 不同，這種情況很常見，也不一定代表你的設定有錯。Google 會綜合內容相似度、重新導向、rel canonical、Sitemap、內部連結、HTTPS 與 hreflang 等信號；當這些信號不一致，它就可能做出不同選擇。因此，與其直接認定標籤失效，不如先從五個常見原因與三步驟診斷流程逐一檢查。
Google 忽略 canonical 的五個常見原因
在調整任何設定之前，先確認你的網站屬於哪一種情況。不同的原因對應的修正方式差異很大，例如內部連結指向錯誤，和 JavaScript 注入造成的問題，處理方法完全不同。
- 信號衝突：canonical 指向頁面 A，但內部連結、Sitemap 或重新導向卻指向頁面 B。這些公開信號互相矛盾時，Google 可能不採用你的 canonical 聲明。
- 內容不夠相似：當 Google 判斷兩個頁面不是真正的重複內容，便沒有必要從中選一個標準網址，於是兩個頁面都可能被獨立索引。
- 實作錯誤：canonical 放在 body、指向無法存取的 URL，或同一頁輸出互相衝突的聲明，都會削弱或使信號失效。相對 URL 受支援，但官方建議使用絕對 URL 以降低部署錯誤。
- 爬取頻率低：剛修改 canonical 設定後，Google 可能尚未重新爬取該頁面，仍在沿用舊的快取資料，因此需要等待一段時間再驗證。
- 目標頁不合格：canonical 指向無法存取、被 robots 阻擋、回傳錯誤或本身又導向其他位置的 URL，會讓 Google 難以採用該目標。
上述原因中，信號衝突與目標頁狀態最容易被忽略。檢查時先確認內部連結、Sitemap、重新導向與 hreflang 都指向同一版本，再實際請求目標 URL，確認它可供 Google 存取且沒有下一層跳轉。
JavaScript 注入 canonical 的隱藏陷阱
使用 React、Vue、Angular 或一般 SPA 架構的網站，很容易出現由 JavaScript 動態寫入 <head> 的 canonical 標籤。這個做法雖然在瀏覽器渲染後看得到，但對 Googlebot 的處理流程來說，存在時間差。
Googlebot 會先處理伺服器回傳的 HTML，再進入渲染階段；官方只說渲染可能在數秒後或更久，沒有公布固定的數天或數週時程。因此，canonical 在初始 HTML 就存在最容易驗證，也能避免渲染失敗或程式碼互相覆寫。
最佳做法是讓伺服器回傳的 HTML 直接包含 canonical。若技術上只能用 JavaScript，初始 HTML 應先省略 canonical，再由 JS 設定；若初始 HTML 已有 canonical，JS 不應把它改成另一個 URL。
三步驟診斷 canonical 是否被採用
要確認 Google 是否採用你宣告的 canonical，可以依照下列三個步驟操作。每個步驟都能過濾掉一類常見問題。
- 在 Google Search Console 的 URL 檢查工具中，輸入你設定 canonical 的頁面 URL，查看「Google 選取的 canonical」欄位。如果這個欄位與你宣告的 URL 不同，代表 Google 做了其他選擇。
- 檢視頁面原始碼：在瀏覽器開啟網頁後，使用 Ctrl+U 檢視原始碼，搜尋「canonical」。確認標籤存在、位於 head 內、href 是完整的絕對 URL，而且後續沒有其他 canonical 標籤覆蓋它。
- 檢查 canonical chain：如果 canonical 目標頁本身又指向另一個 canonical，或這個目標 URL 帶有 301 轉址，Google 就需要沿著鏈條再判斷一次，途中任何中斷都會讓最終標準網址偏離你的預期。
執行完三個步驟後，通常可以定位出是語法問題、鏈條問題，還是訊號衝突。若確認技術設定無誤，但 Search Console 仍顯示不同的選擇，應等待 Google 重新爬取與重新處理後再驗證；官方沒有承諾固定的兩週門檻，實際時間取決於頁面與網站狀況。
如果你手上同時有多個技術 SEO 問題待處理，例如 canonical 設定、頁面效能、索引覆蓋率等，需要一份能將問題盤點與執行優先順序一次整理出來的藍圖，可以參考 SEO 策略藍圖服務。這個方案以 15 萬起、一次性執行的方式，針對網站現況做技術 SEO 盤點，並列出優先處理的任務順序，避免你在不同議題之間反覆切換卻看不到進展。
爬取預算與未解決的 canonical 衝突
爬取預算主要是超大型或更新非常頻繁網站的議題。Google 的現行粗略門檻包括約百萬頁且每週更新、約一萬頁且每日更新，或大量 URL 長期停在「已發現、尚未建立索引」；一般數千頁網站不應先把問題歸因於爬取預算。
根據 Google 的爬取預算管理文件，重複 URL 被列為「低價值 URL」的主要類型之一。大量重複 URL 的確可能消耗爬取時間，但 Google 也明確說明：只有網站已碰到服務容量上限時，減少低價值 URL 才可能讓其他重要 URL 得到更多爬取，並非自動轉移配額。
以電商網站為例，10,000 個商品，每個商品有 5 個 URL 變體（顏色、尺寸、排序參數），就產生 50,000 個需要處理的 URL。這些變體會擴大 Googlebot 需要探索與判斷的 URL 空間；是否影響新商品頁爬取，仍要用伺服器日誌、GSC 狀態與網站容量證據確認，不能只靠 URL 數量推定。
除了 canonical，Sitemap 也是控制索引信號的關鍵，Sitemap 指南會說明如何透過 XML Sitemap 讓 Googlebot 更快發現重要頁面。另外，PageSpeed Insights 指南可用來檢查使用者體驗與載入效能；伺服器回應穩定性可能影響 Google 的爬取容量，但 PSI 分數本身不是爬取配額。URL 結構設計指南則可協助建立一致、可管理的網址規則。這些面向與 canonical 一樣，都屬於技術 SEO 的基礎建設。
Canonical vs. 301 轉址：什麼時候用哪個？
這兩個工具常被混用，但它們的設計目的不同。一句話區分：canonical 讓兩個 URL 都可以訪問，但告訴 Google 哪個才是「正版」；301 會把使用者與搜尋引擎導向新 URL，並向 Google 提供永久遷移的強信號，但 Google 仍會綜合其他信號處理。
核心差異對比
選錯工具之所以常見，是因為兩者在 HTML 和伺服器設定上看起來都在「指定一個標準網址」，但對 Google 的意義完全不同。canonical 是在「兩個 URL 都必須活著」的前提下，表達偏好；301 則是在「舊 URL 不需要存在」的前提下，把 URL 的位階徹底移轉。
表格中最值得注意的差異是 Google 遵從強度與風險。canonical 只是強烈建議，Google 可能因為訊號不一致或其他因素而不採用；永久重新導向是強信號，但不宜寫成 100% 保證。Google 說明永久重新導向本身不會造成 PageRank 流失；仍應避免 A 到 B 再到 C 的長鏈，因為它增加延遲、爬取成本與故障點。
| 面向 | rel="canonical" | 301 轉址 |
|---|---|---|
| 兩個 URL 是否都可訪問 | 是，都可以打開 | 否，舊 URL 自動跳轉 |
| Google 遵從強度 | 強烈建議，可被覆蓋 | 強信號，但仍需驗證 |
| 適合的重複類型 | 功能性重複（需要兩個 URL 存在） | 永久性合併（舊 URL 不再需要） |
| 典型場景 | UTM 參數頁、AMP 頁、跨平台發布 | 網站改版、域名更換、內容合併 |
| 風險 | Google 可能忽略聲明 | 長鏈增加延遲、爬取成本與故障點 |
AK Canonical 決策樹：選 canonical 還是 301？
遇到重複 URL 問題，先判斷第一個問題：用戶或系統是否需要保留兩個 URL 都能訪問？以 UTM 追蹤連結為例，帶有參數的 URL 必須能正常回應，追蹤系統才能記錄來源；AMP 頁也必須維持獨立 URL，平台才能正確引用。兩個 URL 都有存在的必要時，用 canonical 表達偏好，而不是讓其中一個失效。
- 需要（如：UTM 追蹤連結需要有效、AMP 頁需要獨立 URL）→ 用 canonical
- 不需要 → 進入問題二
接著判斷第二個問題：這個重複是否是永久性的、不會改變的？舊網址廢棄、內容合併屬於永久重複，301 能讓使用者與搜尋引擎都直接到達唯一的新位置，並把舊網址的連結信號一併轉移；URL 參數這類功能性重複則因為系統必須繼續產生不同的 URL，仍應使用 canonical。
- 是永久重複（如：舊網址廢棄、內容合併）→ 用 301 轉址，最終解決問題
- 功能性/暫時性重複（如：URL 參數是系統需求）→ 用 canonical
實務上，若舊 URL 已不需要保留，我傾向先做直接指向最終頁的永久重新導向，因為它同時改變存取路徑並提供強信號；若兩個 URL 都需保留，再用 canonical 表達偏好。兩者仍須用網址檢查與實際回應驗證。用 canonical 當成 301 的替代品，結果通常不如預期。
技術 SEO 的基礎設定，不知道從哪裡開始盤點？若需要一次整理網站問題與執行順序，可參考SEO 策略藍圖。這項一次性交付以網站現況診斷、內容架構建議、技術 SEO 問題盤點、執行優先順序與內部團隊任務表為範圍。
完成 Canonical 設定後的下一步：驗證與長期監控
設定完 canonical 標籤之後，不能只用「有放就好」當作完成。你必須確認搜尋引擎實際採用哪一個標準網址，並在網站持續運作時觀察它的變化。驗證不是一次性動作，而是與內容發布、網站改版、參數調整並行的長期任務。Google Search Console 的「網址檢查」工具會顯示你指定的標準網址與 Google 選擇的標準網址，這是驗證的第一步。 延伸閱讀：網站改版 SEO 風險控制。
用 Search Console 驗證標準網址是否被採用
在「網址檢查」工具中，當兩者一致時，代表你的 canonical 標籤被採用。如果不一致，代表有其他訊號影響，需要進一步檢查並調整，讓它們往同一個方向集中。此時你需要的不是繼續加標籤，而是處理這些訊號。
可再搭配頁面索引報表觀察群組變化，但報表可能只提供代表性樣本，重複 URL 減少也不能單獨證明 canonical 已採用。請以重要 URL 的網址檢查結果、原始碼與實際導向狀態交叉驗證；Google 沒有承諾一週到數週的固定完成時間。
若你同時使用 Google Analytics 或伺服器日誌，可以比對標準網址與其他版本在請求量、點擊數上的比例。當非標準版本的比例持續下降，表示使用者與搜尋引擎都在往標準網址集中。請把這份紀錄存起來，作為下次改版時的對照基準。
長期監控的指標與頻率
監控的重點不是每天看數字，而是設定固定節奏。依網站發布與改版節奏抽查重要 URL 的網址檢查結果，記錄指定版本與 Google 選擇是否一致；URL 檢查是逐頁工具，不能把有限抽樣包裝成全站採用率。同時觀察標準網址的曝光次數與平均排名，如果出現明顯下滑，先確認 canonical 是否有被意外移除或覆寫，再檢查是否新增了更強烈的競爭頁面。
比較容易被忽略的是參數型網址。當網站加入新的追蹤參數或篩選條件時，這些網址可能形成新的重複內容來源。Google 已在 2022 年停用 Search Console 的「網址參數」工具；現在應從網站路由、內部連結、robots 規則與 canonical 等層面管理參數 URL，並先確認參數是否真的不改變內容。每月巡視一次已發布的 canonical 標籤程式碼，確認沒有被外掛程式或改版程序覆寫，是必要的維護工作。
把驗證與監控變成固定的 SEO 維護工作
上述工作如果只靠偶爾抽查，很容易在網站改版時漏掉。比較穩妥的做法是建立一份 canonical 檢查清單，內容包含每一組重複內容的標準網址、上次驗證日期、採用狀態，以及該頁面的主要流量來源。每次發布新內容或修改現有頁面時，先對照清單，決定是否需要新增或調整 canonical。如此一來，canonical 的維護就不會只停留在一次性的設定。
當你發現站內重複內容的規模持續擴大，或 canonical 設定需要與整體爬蟲預算配置、內容階層重新規劃一起處理時，單靠內部團隊消化會比較吃力。這類工作涉及技術 SEO 的持續投入，包括結構審計、程式碼調整與效果追蹤。例如 SEO 策略藍圖（15 萬起 / 一次性）適合建立整體配置，SEO 成長顧問（10 萬起 / 月）適合持續監控。若你需要外部資源分擔這份投入，請瀏覽SEO 服務方案與適用對象說明。
Canonical 標籤常見問題
Canonical 標籤會影響 Google 索引的速度嗎？
canonical 設定本身不保證加快索引。大型網站若有大量重複 URL，讓信號一致可能減少無效探索；但只有網站確實碰到爬取容量限制時，才可能間接改善其他重要 URL 的爬取，必須用日誌與 GSC 驗證。
一個頁面可以同時有多個 canonical 標籤嗎？衝突時怎麼辦？
HTML 技術上可能輸出多個標籤，但互相衝突的 canonical 會製造歧義，Google 可能忽略其中的聲明並自行選擇代表頁；不要把結果寫成必然「忽略全部」，也無法一概斷言比未設定更糟。解決方式：找到重複的來源（通常是兩個不同的 SEO 外掛同時輸出），只留一個。
Canonical 可以跨域指向另一個網站嗎？
可以。跨域 canonical 的典型用途是把自己的網站設成授權來源，讓在其他平台（Medium、合作媒體）發布的相同內容指向你的網站。跨域 canonical 技術上受支援，但 Google 目前不建議把它當成控制轉載內容的可靠方法，也不保證信號一定集中。能協調發布方時，優先避免索引完整轉載版或改發摘要並連回原文。
Google Search Console 顯示「使用者宣告 canonical 與 Google 選取 canonical 不同」，怎麼辦？
先不要急著「修正」，因為這不一定是問題。Google 選取的版本可能確實是「更好的」選擇。先確認幾件事：Google 選取的那個 URL 是不是你認可的版本？如果是，那沒有問題。如果不是，通常原因是連結結構和 canonical 聲明衝突，需要讓兩者方向一致，而不只是修改 canonical 標籤。
WordPress 用什麼外掛設定 canonical 標籤？
主流 WordPress SEO 外掛通常會自動輸出自我 canonical，並提供逐頁覆寫欄位；介面位置與預設行為會隨版本變動，實作時應以目前外掛文件與頁面原始碼為準，而不是只相信後台顯示。
電商網站的商品頁每一頁都要設 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 頁不是獨立內容。若仍使用 AMP，應依目前 AMP 文件驗證配對與 canonical；不要只靠「單向就一定造成重複」這類推論判斷結果。
canonical 標籤跟 noindex 可以一起用嗎？
不建議把 noindex 與 canonical 混在同一個重複頁面策略中。Google 明確不建議用 noindex 阻止它選擇某個 canonical，因為這會讓信號含義不一致；若舊 URL 已不需要保留，使用直接指向最終頁的永久重新導向通常更清楚。
如果 canonical 目標頁本身也有 canonical，會形成 canonical chain 嗎？
會。A canonical → B，B canonical → C，這就是一條 canonical chain。Google 沒有公布「canonical 最多兩層」的固定門檻，也不能預測它必然選擇鏈中哪個 URL。另一個問題是 canonical 指向一個有 301 轉址的 URL，Screaming Frog 會顯示「canonical to redirect」的警告。最好的做法是讓 canonical 直接指向最終目標，跳過所有中間跳轉。
Canonical 可以解決抄襲問題嗎？
不能，但常有人這樣期待。canonical 標籤只對「把 canonical 設上去的頁面」有效。如果別的網站抄你的內容，那個頁面的 canonical 是由對方控制的，對方不會設成指向你。應保留原始發布與著作權證據，必要時依適用法律與平台程序提出移除要求；較早被爬取或索引不能保證 Google 一定判定你是原始來源。法律處理有風險時，應諮詢合格專業人士。
想先自己檢查：相關免費工具
先用這幾個工具把文章提到的項目對照一次，再回到你的網站情境閱讀結果。
想把技術檢查放回整體網站？
留下 Email，我會寄出合作方式與價格範圍；你可以先了解技術問題如何整理成工作順序，再決定是否回覆。
十年 SEO 實戰 · Threads 公開研究 · 隱私權政策