Canonical URL 完全指南：解決重複內容問題

Canonical URL 是什麼？怎麼讓 Google 選對重複網址的代表版本

為什麼內容越寫越多、越寫越扎實，Google Analytics 裡的自然流量線卻怎麼樣都拉不上來，甚至還慢慢往下滑？多數人直覺怪演算法懲罰、怪對手抄襲搶排名，於是花大把時間查外連、改標題、重寫內容，問題還是沒解決。

真相常常比你想的無聊。動態網站容易讓同一份內容出現在多個網址，造成索引、內部連結與報表歸因混亂；處理這類重複網址時，常會用到 Canonical URL（標準網址）。

換句話說，你的網站裡若有太多「網址不同、內容卻幾乎一樣」的頁面，Google 會自行選擇其中一個作為代表網址。Canonical 的作用，是提示你希望 Google 選哪一個版本，並協助合併重複網址的連結訊號；它不會把 GA4 的流量、點擊或停留時間搬到另一頁，也不能保證排名上升。

重點摘述：Canonical URL 是你主動提示 Google「在這一群內容重複的網址當中，希望以這一個作為代表版本」的機制。設對了，索引網址、內部連結與成效報表會更一致；若訊號互相矛盾，Google 仍可能自行選擇其他版本。

這篇會帶你從頭搞懂 Canonical：它解決的到底是什麼機制、你的網站哪些地方正在偷偷製造重複網址、四種實作方法怎麼選、以及怎麼用 Google Search Console 驗證 Google 有沒有真的聽你的。如果你想要先建立對「重複內容」這個更大主題的全盤理解，可以先看過重複內容的完整指南，再回來這篇聚焦在 Canonical 這個解法。

重複網址怎麼合併：先搞懂 Google 的代表網址機制

很多人以為重複內容會被 Google「懲罰」，這是最普遍的誤解。Google 的官方文件〈Consolidate duplicate URLs〉寫得很清楚：當系統在檢索時發現多個網址指向相同或極度相似的內容，它會選擇其中一個網址作為「標準版本（canonical）」，只索引並排名那一個，其他的則從索引中折疊掉。

聽起來很貼心對吧？Google 自動幫你選一個。問題出在它選的不一定是你想選的那一個。

換個方式想。想像你寫了一篇「台北牙醫推薦」文章，原始網址是 /taipei-dentist。但同一篇文章透過搜尋篩選、列印版本與追蹤參數，一共產生了七個不同網址。這不是把排名力量平均切成七份；真正的問題是外部連結、內部連結、sitemap 與 canonical 若各自指向不同版本，Google 需要自行判斷代表網址，報表也可能被拆散。

更糟的是，Google 自己挑中的「正本」可能是那個帶著一堆查詢參數的醜網址 /taipei-dentist?utm_source=newsletter&cat=health，跟你想推的那個乾淨網址完全不是同一個。你在搜尋結果看到的，是一個又長又醜、根本不適合分享的網址，而且排名訊號還被分散掉了。

這就是為什麼我們不能把「選擇正本」這件事完全交給 Google 自動判斷，而要主動用 Canonical URL 告訴它：「這一群網址，正本在這裡，請把所有訊號合併過來。」

用一張表把「沒設 Canonical」跟「設好 Canonical」的差別具象化，你會更清楚這件事的影響有多大：

狀態	排名訊號怎麼分佈	Google 索引結果	你能控制的程度
完全沒設 Canonical	連結與網站提示可能分散在不同版本	Google 自己選一個正本，可能是醜網址	幾乎零，全憑 Google 判斷
設了 Canonical 但 Google 不採納	Google 依其他提示自行合併與選擇	Google 忽略你的指定，自己選	低，需要回頭檢查設定合理性
設好 Canonical 且 Google 採納	重複網址的連結訊號較容易合併到代表版本	只收錄正本，搜尋結果顯示乾淨網址	高，訊號流向由你決定

Canonical 的本質不是「避免懲罰」，而是協助 Google 選擇代表網址並合併重複版本的訊號。它對大型電商或參數網址多的網站很重要，但影響大小取決於實際重複範圍與其他技術提示，不能預設排名一定差一頁以上。

這跟「關鍵字蠶食（keyword cannibalization）」是不同的問題，很容易被搞混。關鍵字蠶食是你網站上有多篇文章在搶同一個關鍵字，那是內容策略問題，解法看關鍵字蠶食修復；Canonical 處理的是「同一篇文章的多個網址分身」，是純技術問題。兩者常被混為一談，但解法完全不同，不要用錯工具。

你的網站正在製造重複網址的 7 個地方

大多數網站主以為自己沒有重複內容問題，因為「我又沒有抄襲別人」。但 Canonical 處理的跟抄襲無關，它要解決的是系統自動產生的網址變體。接下來這七種來源，你的網站幾乎一定中了幾項，只是你沒察覺。

1. 查詢參數與篩選器

這是最普遍也最隱形的兇手。電商網站的分類頁加上排序、顏色、尺寸、價格區間篩選後，同一個分類可以跑出幾十個不同網址：

• /shop/shoes（原始分類頁）
• /shop/shoes?sort=price（價格排序）
• /shop/shoes?color=black&size=42（顏色尺寸篩選）
• /shop/shoes?sort=price&color=black&size=42（多重組合）

內容幾乎一樣，網址卻完全不同。Google 會把它們當成重複網址，但你如果不設 Canonical，訊號就會分散在這一堆變體上。如果你經營的是 WooCommerce 商店，這個問題尤其嚴重，商品頁的 SEO 設定一定要把這層考慮進去，否則一個熱門分類頁可能就有上百個重複分身。至於某個資訊究竟該寫進路徑還是留在參數，網址路徑與查詢參數的取捨有完整的判斷準則。

2. www 與非 www 版本

https://www.example.com/page 和 https://example.com/page 對 Google 來說是兩個不同的網址。雖然多數主機商預設會做其中一邊的轉址，但不少網站根本沒設好，等於兩個版本同時存在、同時被收錄。這層設定跟你選 www 還是非 www 無關，重點是只能留一個。詳細的選擇邏輯和設定步驟，可以參考www 與非 www 的完整解析。

3. HTTP 與 HTTPS

如果你網站還沒有強制 HTTPS，那 http:// 和 https:// 兩個版本的每一頁都是重複網址。現在 SSL 憑證幾乎是標配（不知道怎麼裝的話看SSL 憑證教學），但「裝了 SSL」跟「強制轉址到 HTTPS」是兩件事。實務上常見的狀況是 SSL 裝了，卻沒把 HTTP 301 轉到 HTTPS，等於兩個版本並存。HTTPS 對 SEO 的影響與正確設定方式，這篇HTTP 換 HTTPS 攻略講得很清楚。

4. 分頁（Pagination）

部落格首頁、分類頁的「第 1 頁、第 2 頁」分頁機制，常常讓第一頁產生兩個網址：/blog 和 /blog/page/1，內容完全相同。這是最經典的分頁重複問題，需要把 /blog/page/1 的 Canonical 指回 /blog。

5. AMP 版本

如果你網站啟用了 AMP，每一篇文章都會有一個 AMP 版本的網址。行動版頁面跟桌面版內容相同但網址不同，這時必須在兩個版本之間互相指定：AMP 頁用 Canonical 指向正本，正本則用 rel="amphtml" 回頭指向 AMP 頁。AMP 的完整設定與注意事項，看AMP 完全指南。

6. 列印版與獨立行動版網址

有些老網站還保留 ?print=1 的列印版本，或用 m. 子網域提供行動版。這兩種都會製造重複網址。行動版的問題現在多半被響應式設計（RWD）解決了，如果你還在用獨立行動網址，強烈建議改成RWD 響應式設計，從架構上一次解決，用 Canonical 補救只治標不治本。

7. 多語系與多區域版本

同一篇文章的繁中版、英文版、簡中版即使是翻譯，也通常各自使用 self-canonical，再用 hreflang 表示語言或地區關係；不要因主題相同就把所有語言版本 canonical 到單一語言。這是進階情境，後面會專門講。

把這七項列出來，你大概已經發現自己的網站中了幾個。這很正常。重複網址幾乎是所有動態網站的副產品，重點從來不是「完全不產生」，而在於你有沒有主動告訴 Google 哪一個是正本。

Canonical 標籤到底跟 Google 說了什麼：是訊號合併，不是封鎖

很多人把 Canonical 想成「叫 Google 不要收錄某個網址」，這是根本性的誤解。Canonical 比較像是提示：你在重複網址的 HTML 裡放一個標籤，告訴 Google 希望哪個網址作為代表版本。它能協助合併重複網址的連結訊號，但不是 noindex，也不是使用者行為資料的搬移工具。

Canonical 的主要用途是訊號合併（signal consolidation）。Google 採納後，會以代表網址處理重複版本，並合併相關連結訊號。這能讓索引與連結歸屬更一致，但不是把點擊資料搬到正本，也不能預測排名一定上升。

但有一件你必須誠實面對的事：Google 把 Canonical 當成「強烈建議」，不是「絕對命令」（見官方說明〈Consolidate duplicate URLs〉）。多數時候它會尊重你的選擇，但如果你的 Canonical 標籤跟網頁實際內容差太遠（例如你指了 A 頁為正本，但 A 頁跟現在這頁內容根本不像），Google 會忽略你的指定，自己選一個。這不是系統出錯，而是 Google 在保護搜尋結果品質。

所以 Canonical 的正確心態是：你要設得「合理」，讓你的指定跟內容、跟使用者體驗一致，Google 才會聽你的。至於 Canonical 標籤的 HTML 語法細節，會在後面〈進階實作〉段落示範；這篇前半段先聚焦在策略與決策邏輯。

4 種實作 Canonical 的方法，各有不同的適用情境

Canonical 不是只有「在 HTML head 放一行 link 標籤」這一種。依照你的網頁類型和技術環境，有四種方法，選錯會沒效果，選對才能讓 Google 確實收到你的訊號。

方法	怎麼做	適用情境
rel="canonical" link 標籤	在 HTML 的 <head> 裡加上 <link rel="canonical" href="https://example.com/page" />	大多數 HTML 網頁，最常見也最推薦的主力方法
HTTP 回應標頭	在伺服器回應標頭加上 Link: <https://example.com/file.pdf>; rel="canonical"	非 HTML 檔案（PDF、圖片）或無法編輯 HTML 的情境
Sitemap 只列正本	在 XML Sitemap 只列出正本網址，不列分身	輔助提示，不能單獨使用，搭配前兩種效果更好
301 永久轉址	把分身網址直接 301 轉到正本	分身網址已經不需要存在、不再被任何地方連結時

多數情況你只需要第一種。但如果你網站有大量 PDF 文件（例如產品規格書、白皮書、電子型錄），這些檔案沒有 HTML head 可以放標籤，就只能用 HTTP 回應標頭的方式指定 Canonical。這是很多人完全忘記的盲區，結果 PDF 之間互相搶排名訊號，卻沒有人處理。

第三種 Sitemap 方法要特別說明。有些教學會告訴你「只要在 Sitemap 放正本就好，Google 就知道了」，這不夠。Google 明確表示，Sitemap 裡出現的網址會被視為 Canonical 的候選，但它不能取代 rel="canonical" 標籤（見 Google 官方文件〈Consolidate duplicate URLs〉）。把它當成輔助提示，不要當主力。Sitemap 的正確提交方式看XML Sitemap 實作教學。

第四種 301 轉址嚴格來說不是「設 Canonical」，而是「消滅分身」。當某個分身網址已經沒有存在的必要（例如舊的篩選參數組合、已下架的商品分類頁），與其留著它再設 Canonical，不如直接 301 轉走，一勞永逸。但兩者的使用時機不同，接下來這張決策表會幫你判斷。

Canonical、301 轉址、noindex：一張表搞懂什麼時候用哪個

這三個工具經常被搞混，但它們解決的問題層次完全不同。選錯工具，輕則沒效果，重則把辛苦累積的流量送進墳墓。這張表把判斷邏輯整理清楚。

工具	它做什麼	什麼時候用	什麼時候不要用
rel="canonical"	告訴 Google 哪一頁是正本，合併排名訊號，分身仍可被使用者正常訪問	同一內容有多個網址都需要保留可用（篩選頁、AMP、列印版、分頁首頁）	兩頁內容差異很大時（Google 會忽略你的指定）
301 永久轉址	把使用者與搜尋引擎直接導向另一個網址，舊網址不再存在	網址永久搬家、合併舊頁、淘汰無用的分身網址	分身網址還需要被使用者直接連結或加書籤時
noindex	告訴 Google 不要把這一頁放進索引、不要讓它出現在排名	頁面需要存在給使用者看，但不該出現在搜尋結果（內部搜尋結果頁、篩選頁的進階組合）	你想保留排名訊號合併到正本時（noindex 不會合併訊號）

這裡有一個關鍵觀念很多人不知道：noindex 不會做訊號合併。你用 noindex 擋掉一個分身，那個分身上的外部連結權重、點擊訊號就浪費掉了，不會自動轉移到正本。所以如果你的目標是「把分散的排名力量集中起來」，Canonical 才是對的工具，不是 noindex。這兩個被混用的頻率，高得令人驚訝。

還有一個絕對不要犯的錯：Canonical 和 noindex 不要同時用在一個頁面上。noindex 會讓 Google 不收錄這頁，連帶也不會去讀你的 Canonical，等於兩個都失效。如果你想深入了解 noindex 的正確用法，看noindex 完整介紹；robots.txt 和 noindex 的搭配禁忌，這篇有完整說明。轉址的完整設定與 SEO 影響，則可以參考301 與 302 轉址教學。

實戰中 5 個最常踩到的 Canonical 地雷

知道理論跟設對是兩回事。接下來這五個地雷，是實務上最常被忽略、也最容易出錯的問題，每一個都會默默稀釋掉你的排名訊號，而且往往要花好幾個月才會被發現。

地雷一：首頁沒設 self-canonical，被參數版本吃掉

這是最常見也最冤枉的一個。你的首頁 https://example.com 沒有設 Canonical，結果有人從廣告或外部連結連到 https://example.com/?utm_source=facebook，Google 把這個帶參數的版本當成另一個網址收錄。久而久之，你的首頁出現在搜尋結果的網址可能帶著一串 utm 參數，點閱率跟信任度都會受影響。

解法很簡單：每一頁（包括首頁）都要設self-canonical，也就是 Canonical 指向自己。這樣即使有人用任何參數連到這頁，Google 都知道正本是乾淨的那個網址。這是 Canonical 最基本也最重要的一條紀律。順帶一提，UTM 參數的管理本身也是一門學問，UTM 追蹤教學有詳細說明，值得一起看。

地雷二：分頁全指向第一頁，結果第二頁之後的內容消失

很多人為了解決分頁的重複問題，把第二頁、第三頁的 Canonical 全部指回第一頁。聽起來合理，但這會造成一個副作用：第二頁之後的內容完全無法被搜尋到。如果那些頁面有獨特的長尾內容，等於白白放棄一堆能帶流量的頁面。

分頁的正確做法是，每一頁都設 self-canonical：第二頁的 Canonical 指向第二頁自己，第三頁指向第三頁自己，讓每一頁都是獨立的正本。真正要處理的只有「第一頁的兩個網址」問題（/blog 和 /blog/page/1），只有這個要指回 /blog。

地雷三：Canonical 鏈（canonical chain）

A 頁的 Canonical 指向 B 頁，B 頁的又指向 C 頁。Google 得一層一層追，追到最後可能放棄，直接自己選一個。Canonical 應該是「一步到位」的，每個分身直接指向最終的正本，不要拐彎。這個錯誤常出現在用了多個 SEO 外掛、又手動改過設定的網站上，兩個工具打架就會產生這種鏈。

地雷四：全站所有頁面的 Canonical 都指向首頁

這聽起來荒謬，但確實會發生。某個網站的主題檔出問題，每一頁的 Canonical 都吐出首頁網址。結果整個網站只有首頁被收錄，其他幾百頁全部被當成首頁的分身，排名訊號雖然集中了，但你能排名的只剩一個首頁，等於自廢武功。如果你用 Rank Math 或 Yoast 這類外掛，定期到Google Search Console的網頁索引報表確認收錄狀況，這種問題很快就會曝光。

地雷五：跨網域 Canonical 搬錯了方向

Canonical 可以跨網域使用，例如你把內容授權給另一個網站，請它把 Canonical 指回你的原文。但方向一定要搞對：是「重複頁指向原創頁」，不是反過來。實務上常出錯的情境是網站搬家後把新網站的每一頁都 Canonical 指回舊網站，結果新網站完全拿不到排名，所有流量還卡在已經要淘汰的舊網址上。跨網域搬家一定要搭配 301 轉址為主、Canonical 為輔，WordPress 搬家到新網域有完整流程，照著走才不會把方向搞反。

怎麼確認 Google 接受了你指定的標準網址

設了 Canonical 不代表 Google 一定照辦。你要驗證它有沒有真的接受你的指定，這件事只能靠 Google Search Console，不能靠猜。

做法是進入 GSC 的網址審查（URL Inspection）功能（官方使用說明），輸入你想檢查的分身網址，展開「Google 索引」區塊，看「使用者聲明的標準網址」和「Google 選擇的標準網址」是不是一致。

如果兩者一致，恭喜，你的 Canonical 被接受了。如果 Google 選擇的標準網址跟你聲明的不一樣，代表 Google 覺得它選的更合適，你需要回頭檢查你的指定是不是合理：內容是否真的高度相似、是不是有其他衝突訊號（例如某個分身拿到更多外部連結）。這個工具的完整操作流程，可以看網址檢查工具的實戰教學。

另一個進階檢查方式是在 GSC 的「連結」報表裡，查看內部連結的分佈。如果你發現一篇文章的內部連結分散在好幾個變體網址上，代表你的內部連結策略跟 Canonical 沒有對齊。理想狀態下，你站內所有連結都應該對準正本網址，避開分身，這樣才能跟 Canonical 的指定互相呼應。

記住一件事：重複網址不只是 SEO 排名的問題，它還會浪費你的檢索預算（crawl budget）。Google 爬蟲每次來你網站，能爬的頁面數量有限，如果它把時間花在爬一堆重複分身上，真正重要的新頁面反而爬不到。對內容量大、更新頻率高的網站，這點影響特別明顯，檢索預算優化值得一併了解。

多語系與跨國網站的 Canonical 進階配置

如果你經營的是多語系網站（例如同時有繁中、簡中、英文版），Canonical 的配置會多一層複雜度。這裡的核心原則是：每一個語言版本都應該是自己的正本，有自己的 self-canonical。不要把英文版的 Canonical 指向中文版，也不要反過來，否則等於告訴 Google 某個語言版本不存在，直接毀掉那個版本的排名機會。

語言版本之間的關係，靠的是hreflang 標籤，不是 Canonical。hreflang 告訴 Google「這些網址是同一內容的不同語言版本，請依使用者的語言偏好顯示對應版本」；Canonical 處理的則是「同一語言內的重複網址」。兩者各司其職，不要混用。hreflang 的完整設定邏輯與常見錯誤，這篇多語系 SEO 手冊講得非常完整，如果你用 WordPress 架多語系站，Polylang 的設定教學也值得一看。

跨國網站還有一個特殊情境：同一語言、不同地區（例如台灣繁中與香港繁中）。如果內容相近，但價格、聯絡方式或出貨資訊不同，可在各頁 self-canonical 的基礎上，搭配 hreflang 標註地區變化。設定錯誤可能讓 Google 顯示不理想的地區版本，因此上線後要用網址檢查與實際搜尋結果驗證。從站點架構、內容分工到各版本上線後的追蹤，跨國網站的完整規劃流程，可以參考多語系 SEO 全攻略。

為什麼這件事現在做，比任何時候都急

你可能覺得 Canonical 是「進階技術 SEO」，可以晚點再處理。根據 Ahrefs 針對大量頁面的研究（2023 年 12 月），超過 96% 的網頁沒有從 Google 取得自然流量。這份研究不能證明 canonical 是沒有流量的主因，但若站內確實產生大量重複網址，及早收斂能讓索引與成效追蹤更清楚。

Backlinko 的搜尋結果研究（2025 年 4 月）觀察到多種與高排名相關的特徵，但沒有證明重複網址或 canonical 設定會直接決定頁面能否進前 10 名。Canonical 的可防守價值，是協助搜尋引擎選定代表網址、合併重複網址訊號，並讓內部連結與報表歸因一致。

若站內有大量未處理的重複網址，先讓 canonical、內部連結與 sitemap 指向一致的代表版本。這能降低 Google 選錯網址與報表拆分的機會；是否影響排名，仍要看重複範圍、連結與頁面本身，不能把第一頁或第二頁的差距只歸因於 canonical。

Canonical 和內部連結策略必須互相呼應

很多人設好了 Canonical 就以為沒事了，卻忽略一個更深的層次：你的內部連結跟 Canonical 有沒有對齊。這兩者如果打架，Google 會收到互相矛盾的訊號，結果就是它誰也不信，自己重新選一個正本。

什麼叫打架？舉個例子。你有一篇文章的正本是 /taipei-dentist，你也在這頁設了 self-canonical 指向自己，邏輯沒問題。但你站內的選單、麵包屑、相關文章推薦，全部連到 /taipei-dentist?source=menu 這個帶參數的版本。等於你嘴巴告訴 Google「正本是乾淨網址」，手卻一直指向帶參數的分身。Google 看到你站內對分身的連結遠多於正本，會懷疑分身才是真正的主頁，於是可能把分身當正本收錄。

正確做法是內部連結全部指向 Canonical 正本。選單連到乾淨網址、麵包屑連到乾淨網址、相關文章連到乾淨網址，全站一致。這樣 Canonical 標籤和內部連結權重傳遞的方向才會一致，Google 不會收到矛盾訊號。實務上，Canonical 從來不是孤立的技術設定，它需要跟你的網站架構、內部連結策略整體一起想清楚。如果你正在重新規劃網站結構，網站架構的 SEO 設計和站內 SEO都值得一起檢視。

還有一個常見的內部連結問題：分頁之間的「上一頁、下一頁」連結。如果你用相對路徑或帶參數的網址來串分頁，也會製造一堆變體。比較穩定的做法是分頁連結直接用完整的乾淨網址，讓每一頁的內部連結都穩定指向自己那個正本。

3 個關於 Canonical 最常被問的問題

Canonical 可以指向別的網域嗎？

跨網域 canonical 可用於內容聯播與授權。若深度內容授權其他媒體轉載，可請對方把 canonical 指向原始網址，協助 Google 判斷偏好的代表版本；但 Google 仍可能依其他訊號選擇不同 canonical，因此不能保證排名訊號完全整併。完整做法可參考內容聯播與授權指南；Medium 的匯入與 canonical 情境則可延伸閱讀Medium SEO 策略。

但跨網域 Canonical 要小心一個陷阱：如果你授權的對象是權重遠高於你的大站，即使對方把 Canonical 指向你，Google 有時還是會選擇把大站版本當正本，因為它的整體權重和外部連結更強。這不是你的 Canonical 設錯，而是現實的權重差距。所以內容授權前，先想清楚你要的是「曝光」還是「排名訊號」，兩者有時不能兼得。

Canonical 和 hreflang 衝突時，誰優先？

這個問題很微妙。理論上它們不該衝突，因為處理的是不同層次的事：Canonical 處理「同一語言內的重複網址」，hreflang 處理「不同語言版本之間的對應關係」。但實務上，如果你的多語系網站設定了錯誤的跨語言 Canonical（例如把英文版的 Canonical 指向中文版），hreflang 和 Canonical 就會打架。

Google 的處理方式是：它會先嘗試理解兩者，如果發現 Canonical 指向的網址跟 hreflang 標註的語言版本矛盾，它可能兩個都忽略，回退到自動判斷。結果就是你的多語系 SEO 完全失效，每個語言版本都可能拿到錯的排名。所以多語系網站的鐵律是：每個語言版本設 self-canonical，語言之間的關係完全交給 hreflang 處理，兩者各管各的，不要越界。

設了 Canonical 之後，多久才會生效？

這要看 Google 重新檢索你網站的頻率。流量高、更新頻繁的大站，可能幾天就生效；冷門的小站，可能要等幾週甚至更久。你可以透過 GSC 的網址審查工具主動提交重要頁面請求重新檢索，加速這個過程。但不要因為等不及就把同一個網址重複提交十幾次，那只會浪費你的檢索配額，不會加快速度。

一個比較務實的節奏是：設好 Canonical 之後，等一週，去 GSC 看網址審查結果。如果 Google 還沒更新選擇，再等一週。通常兩到四週內會穩定下來。如果你的網站真的很冷門、檢索頻率很低，可以從提交 Sitemap和增加內部連結著手，讓 Google 更頻繁地來爬你。

怎麼系統化找出全站的重複網址：實用的檢查流程

前面講了七種重複來源，但你總不能一頁一頁手動檢查。一個稍有規模的網站動輒幾百上千頁，靠人力根本不可能掃完。你需要一套系統化的檢查流程，搭配對的工具，才能把重複網址一次抓出來。

第一步永遠是Google Search Console 的網頁索引報表。這是免費又最權威的起點。報表裡會列出 Google 認為「重複網址」而未索引的頁面，以及它選擇的標準網址是哪一個。你點進去看「原因」欄位，如果寫的是「重複網址，Google 選擇了不同的標準網址」，那就是你設的 Canonical 跟 Google 的判斷不一致，需要逐筆排查。GSC 的完整報表解讀方式，看GSC 實戰技巧。

第二步是用爬蟲工具全站掃描。GSC 只告訴你 Google 發現了什麼，但它受限於檢索範圍，有些重複網址它根本還沒爬到。你需要主動出擊。常見的做法是用 Screaming Frog 這類網站爬蟲工具，把全站爬一遍，篩選出「標題相同」或「內容相似度高」的頁面，這些幾乎都是重複網址的候選。如果你不確定爬蟲工具怎麼用，技術性 SEO 指南有涵蓋這類工具的入門。

第三步是檢查你的網址參數使用狀況。在 GSC 的「網址參數」設定裡（如果這功能還開放給你的網站），你可以看到 Google 偵測到的所有查詢參數，以及每個參數影響了多少網址。如果某個排序參數影響了上千個網址，那就是一個巨大的重複來源，需要標記為「不建立網址」或在伺服器端直接處理。

第四步，如果你用 WordPress，檢查你的 SEO 外掛 Canonical 設定。Rank Math 和 Yoast 都有自動產生 Canonical 的功能，但它們的預設行為不見得符合你的需求。例如有些外掛預設會把分頁的 Canonical 指向第一頁（前面講的地雷二），你需要手動調整。確認外掛設定的最佳時機是網站剛上線、還沒累積太多內容的時候，事後改要動到幾百頁就麻煩了。WordPress 整體的 SEO 基礎設定，這篇完整指南可以當清單用。

把這四步跑完，你對自己網站的重複網址狀況就會有一張清楚的地圖。接下來才是針對每個問題，用前面教的 Canonical、301、noindex 工具去逐一解決。順序很重要：先診斷，再治療，不要一頭栽進去改設定卻不知道全貌。

進階實作：canonical 語法細節、電商變體頁與 Google 拒絕排查

前面講的是策略與決策邏輯，這一段把鏡頭拉近到三個更硬核的實作情境：實際的 HTML 語法長怎樣、電商商品變體頁的 canonical 怎麼判斷、以及當 Google 拒絕你的指定時該往哪裡找原因。這三件事處理得好不好，往往才是大站與小站技術 SEO 差距的真正來源。

canonical 的實際語法：絕對路徑、單一標籤、協定一致

rel="canonical" 的 HTML 寫法本身很簡單，在頁面的 <head> 裡放一行即可：

<link rel="canonical" href="https://example.com/article/" />

多數 CMS（包含 WordPress 的 Rank Math、Yoast）會自動幫你產生這一行。但有三個格式細節會在實務上默默削弱訊號強度，你寫的時候一定要顧到。

第一，網址一定要用絕對路徑（完整寫出 https://www.example.com/article/），不要偷懶寫成相對路徑 /article/。相對路徑在跨網域、跨子網域、或協定不一致時，很容易被 Google 誤判成不存在的網址，把一個本來清晰的訊號變成一團模糊的雜訊。絕對路徑寫起來較冗長，但它排除了所有歧義，這種「笨卻可靠」的寫法在技術 SEO 裡永遠是首選。

第二，一個頁面只放一個 canonical。同時裝了快取外掛和 SEO 外掛、或同時啟用兩個 SEO 外掛時，頁面常會吐出兩個 canonical 標籤，Google 收到矛盾訊號時可能兩個都不採用。排查方法很簡單：用瀏覽器開發者工具檢視原始碼，搜尋 rel="canonical"，確認一個頁面只有一個。

第三，協定與網域必須一致。常見的三種不一致：全站已是 HTTPS，但 canonical 還寫 http://；網站正式網域是 www.，canonical 卻寫成 non-www（或反過來）；網址結尾有的加斜線、有的不加（/article 與 /article/ 並存）。這三種都會讓 Google 多一道「哪一個才算正版」的判斷關卡，削弱 canonical 的訊號強度。確認方式是檢查你網站的偏好網域設定，加上伺服器層的 301 統一轉向，讓不管使用者輸入哪一種變體，最終都會落到同一個標準網址。

如果你要處理的是 PDF、圖片、或沒有 <head> 可寫的資源（例如產品規格書、白皮書、電子型錄），改用 HTTP 回應標頭來宣告：

Link: <https://example.com/whitepaper.pdf>; rel="canonical"

這種寫法比較少見，但在文件下載站、技術手冊站很實用。設定方式視伺服器而異（Apache 用 .htaccess、Nginx 用 add_header），不熟伺服器設定的話請工程師協助，別自己硬改設定檔。

電商商品變體頁：用一張決策矩陣把情境走一次

電商網站的商品變體頁是 canonical 最容易判斷錯的情境。假設你賣一件外套，有紅、藍、黑三色，每個顏色各有 S、M、L 三個尺寸，再加上一個「全部顏色全部尺寸」的商品主頁，總共會產生十個網址。十個網址賣的是「同一件外套」，但內容會因為顏色圖、庫存狀態而略有不同。這時 canonical 怎麼設，會直接決定你能不能把這件外套的排名推上去。用一張決策表來拆這件事：

頁面類型	網址特徵	canonical 指向	理由
商品主頁（總覽）	/product/jacket/	自己（self-canonical）	這是你想衝排名的正版
顏色變體頁	/product/jacket/?color=red	商品主頁	內容高度重疊，集中在主頁
尺寸變體頁	/product/jacket/?size=M	商品主頁	避免自相競爭
顏色＋尺寸組合頁	/product/jacket/?color=red&size=M	商品主頁	組合頁內容仍來自主商品資料
獨立且有獨特內容的變體	有獨立描述、獨立評論、獨立圖文	自己（self-canonical）	內容夠獨特，可獨立排名

關鍵判斷在「獨立且有獨特內容的變體」這一列。如果某個顏色款式有自己專屬的長篇描述、專屬的使用者評論、專屬的圖片集，內容跟主頁已經有實質差異，那就值得讓它獨立排名、用 self-canonical；反之，如果變體頁只是換了顏色 swatch 和庫存數字、文字幾乎一模一樣，集中到主頁才是正解。這條界線會直接決定你是在「集中力量」還是在「扼殺長尾流量」，值得每一個變體都認真想一遍。

要特別小心動態內容的陷阱。很多電商平台的商品變體頁會即時顯示庫存狀態、價格變動、甚至「目前有 N 人在瀏覽」，這些動態區塊會讓兩個變體頁的 HTML 看起來差很多。但它們的核心商品資訊（標題、規格、主描述）往往仍然完全相同。判斷時要把焦點放在「對搜尋意圖有意義的內容差異」上，別被這些裝飾性的動態元素帶偏方向；只要核心描述沒有實質不同，集中到主頁依然是正解。

當 Google 拒絕你的 canonical：8 個原因與排查順序

當你在 GSC 發現「Google 選的標準網址」跟你設定的不一樣時，別慌，這不是 bug，是 Google 在告訴你它找到更強的證據。下列八個是最常見的原因，把它們從高頻到低頻排好：

1. 內容差異過大。你宣稱 A 是 B 的副本，但兩個頁面的標題、內文、結構化資料差很多，Google 認為它們根本是不同內容，不該被合併。排查：實際打開兩個網址比對內容。
2. 內部連結投票矛盾。你嘴上說 A 是正版，但全站的導覽列、麵包屑、相關文章都連到變體網址 B，等於用行動投了 B 一票。Google 看行動比看嘴巴準。
3. 反向連結集中於變體。外部網站大量連到變體網址而非你設定的正版，這是一個強訊號。長期解法是引導外部連結指向正版，短期則考慮用 301 把變體轉到正版。
4. sitemap 與 canonical 衝突。你只在 sitemap 列出變體、卻在 canonical 指向正版，兩個訊號打架。排查：確認 sitemap 只列正版網址。
5. 協定或網域不一致。canonical 寫 https:// 但頁面實際在 http:// 跳轉，或寫 www. 但實際是 non-www，這種不一致會削弱訊號強度。
6. canonical 指向斷裂的網址。你指向的標準網址本身回傳 404、被 noindex、或被 robots.txt 封鎖，Google 無法把它當作正版，只好自己另選。
7. hreflang 與 canonical 順序錯亂。多語系站把所有版本 canonical 到單一語系，Google 為了不讓其他語系消失，會覆寫你的選擇。
8. 頁面載入失敗導致 canonical 抓不到。如果 Googlebot 抓取時頁面因為 JavaScript 渲染問題、伺服器錯誤而沒有正常回傳 <head>，它就讀不到你的 canonical。排查：用 GSC 的「檢視轉譯後的網頁」功能確認 Googlebot 看到的內容。

排查的順序建議固定下來：先確認兩個網址的內容是否真的相似（原因一），再看內部連結與 sitemap 的投票方向（原因二、四），最後才檢查技術層的協定與可爬取性（原因五、六、八）。多數被覆寫的案例，前三個原因就涵蓋了八成以上。把這個順序背起來，遇到問題就不會像無頭蒼蠅一樣亂試，而是有系統地一層一層往技術深處挖。

Canonical 健檢與下一步行動方案

讀到這裡，你應該已經理解 Canonical 為什麼重要、你的網站哪裡出問題、以及怎麼正確設定。知識不會自己變成流量，接下來是動手的時間。底下提供一個五步的行動方案，照著做就能把最嚴重的問題先堵住。

第一步：盤點你網站的重複網址。打開 Google Search Console，隨機挑 5 到 10 個重要頁面，在網址列後面手動加上幾組常見參數（?utm_source=test、?sort=price），看看這些變體網址是否也能正常開啟、內容是否跟正本一樣。再從 GSC 的網頁索引報表看看，有沒有大量被標記為「重複網址」的頁面。

第二步：確認每一頁都有 self-canonical。用瀏覽器開發者工具或 SEO 檢查外掛，檢查你的首頁、分類頁、文章頁的 HTML head，確認都有 rel="canonical" 且指向自己。特別留意 WordPress 網站，確認你的 SEO 外掛（Rank Math 或 Yoast）設定正確。

第三步：處理最嚴重的重複來源。從前面列的七種來源裡，找出你網站最嚴重的重複問題，通常是查詢參數或 www 與非 www，優先處理這兩個。篩選參數造成的重複，可以在 GSC 的網址參數設定裡標記；www 與非 www 則用 301 轉址統一。

第四步：用 URL Inspection 驗證。設好之後，等幾天到一週，回 GSC 用網址審查工具確認 Google 選擇的標準網址跟你指定的一致。如果不一致，回頭檢查設定是否合理，切忌無腦重設。

第五步：建立長期維護機制。把 Canonical 檢查納入你每次發新內容、改版、搬家的標準流程。如果你用 WordPress，做好永久連結的 SEO 設定，從源頭減少重複網址的產生，比事後補救輕鬆太多。

Canonical 不是設一次就永遠不用管的東西。隨著網站長大、新增分類、加入電商功能、導入多語系，新的重複網址會不斷冒出來。把它當成網站健檢的固定項目，每季跑一次，你的排名訊號才會一直集中在對的地方。

老實說，Canonical 是那種「做對了沒人會稱讚你，做錯了流量默默消失」的隱形工程。它不會像一篇爆紅文章那樣讓你立刻看到數字跳動，但它穩穩地決定了你過去累積的每一篇文章、每一條外部連結，到底能發揮出多少力量。很多網站流量卡關，內容不夠好往往並非主因，真正的問題是好內容的力量被重複網址悄悄漏掉了，而你從來沒注意過。

流量不會無故消失，它只是流向了你沒注意的地方。把 Canonical 設好，就是把你辛苦累積的每一分排名力量，都收回到屬於它的正本上。如果你在實作過程中卡關，或不確定自己網站的重複問題出在哪一層，Whoops SEO 提供網站 SEO 健檢服務，可以幫你把這些技術問題一次釐清。先動手試試上面的五步，你會發現很多問題自己就能解決。