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」的差別具象化，你會更清楚這件事的影響有多大：

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

這跟「關鍵字蠶食（keyword cannibalization）」是不同的問題，很容易被搞混。多個網址對同一查詢有曝光，未必就是關鍵字蠶食；要確認內容與意圖是否重疊，以及重要頁面的成效是否受影響。若確有內容策略問題，解法看關鍵字蠶食修復；Canonical 處理的是「同一篇文章的多個網址分身」，是純技術問題。兩者常被混為一談，但解法完全不同，不要用錯工具。

重複網址從哪裡來：按處理手段分組的盤點

大多數網站主以為自己沒有重複內容問題，因為「我又沒有抄襲別人」。但 Canonical 處理的跟抄襲無關，它要解決的是系統自動產生的網址變體。與其背誦一長串情境清單，實務上更有用的分組方式，是看「這批變體最後要交給哪個工具處理」：能用轉址統一消滅的、要靠 Canonical 收攏訊號的、以及必須回到網站架構預先規劃的。你的網站幾乎一定中了幾項，只是你沒察覺。

交給 301 統一：這些變體沒有獨立存在的理由

這一組的共同點是：變體網址的存在本身沒有意義，留著只會讓 Google 多判斷一次「誰才是正版」。處理方式不是設 Canonical，而是用伺服器轉址，讓不管誰連到變體，最終都落在同一個標準網址上。www 與非 www、HTTP 與 HTTPS、列印版與獨立行動版網址，都屬於這一組。

https://www.example.com/page 和 https://example.com/page 對 Google 來說是兩個不同的網址。雖然多數主機商預設會做其中一邊的轉址，但不少網站根本沒設好，可能讓兩個版本同時可存取，Google 則自行判斷代表版本。這層設定跟你選 www 還是非 www 無關，重點是選定偏好版本並讓轉址、內鏈與 canonical 一致。詳細的選擇邏輯和設定步驟，可以參考www 與非 www 的完整解析。

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

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

交給 Canonical 收攏：變體要保留、訊號要集中

這一組的變體有明確的存在理由：使用者真的會用到篩選器、分頁與 AMP 版本，所以不適合直接 301 掉，而是讓每個變體宣告它的訊號該歸向哪個正本。最先上場的，就是篩選參數。

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

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

排序頁可能只是同一商品清單的不同排列；顏色、尺寸篩選則可能形成具有獨立用途的頁面。先比較實際內容與搜尋需求，再決定合併重複版本，或保留可索引的獨立篩選頁。如果你經營的是 WooCommerce 商店，這個問題尤其嚴重，商品頁的 SEO 設定一定要把這層考慮進去，否則一個熱門分類頁可能就有上百個重複分身。至於某個資訊究竟該寫進路徑還是留在參數，網址路徑與查詢參數的取捨有完整的判斷準則。

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

若同一內容同時提供一般 HTML 與 AMP 版本，AMP 頁以 canonical 指向一般版，一般版以 rel="amphtml" 指向 AMP 頁。若網站只提供 AMP 頁，則使用 self-canonical，不必另外建立一般版。設定細節可參考AMP 完全指南。

交給架構與 hreflang 規劃：翻譯版本不是重複內容

最後一組最常被誤判。翻譯不是重複：每個語言版本服務不同的搜尋市場，需要的不是被合併，而是清楚的版本對應關係。

同一篇文章的繁中版、英文版、簡中版即使是翻譯，也通常各自使用 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 確實收到你的訊號。

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

第三種 Sitemap 方法也是 Google 支援的 canonical 提示，但訊號比 rel="canonical" 弱，且需要 Google 自行辨認重複版本。可以單獨使用；若同時使用標籤、轉址與 sitemap，應讓它們指向一致的偏好版本。提交步驟可參考XML Sitemap 實作教學。

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

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

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

noindex 的用途是排除索引，不是指定另一個代表網址。若目標是合併同站重複內容，Google 建議使用 canonical；若頁面本來就不應出現在搜尋結果，才使用 noindex。不能據此推定該頁所有外部連結或點擊資料一定會消失。

不要把 noindex 與 canonical 當成同一種用途：前者要求排除索引，後者表達重複內容的偏好版本。Google 仍可在爬取頁面時讀到兩者；問題是它們不適合一起用來達成「保留並合併重複網址」的目標。實作可參考noindex 完整介紹、robots.txt 與 noindex 的搭配及301 與 302 轉址教學。

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

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

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

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

替希望索引的代表頁設定 self-canonical，並確認追蹤參數版本輸出的 canonical 仍指向那個偏好網址；不能只是將當前含參數的網址原樣填入。會改變主要內容的參數，則需另行判斷。追蹤設定可延伸閱讀UTM 追蹤教學。

地雷二：誤把分頁當副本，讓類別頁的長尾入口斷線

先確立一個觀念：列表頁的分頁在語意上是同一份清單的不同切片，每一頁各自承載一批項目。第 2 頁收錄的內容組合跟第 1 頁不同，對搜尋者來說就是另一批結果；Google 對分頁的期待，同樣是沿著分頁連結一段一段往下檢索，讓每一頁各自被檢索與索引，任何把整串分頁折疊成第一頁的宣告，都跟這個運作邏輯相抵觸。

很多人為了解決分頁的重複問題，把第二頁、第三頁的 Canonical 全部指回第一頁。聽起來合理，但這會造成一個副作用：向 Google 傳送不合適的重複頁提示，可能影響各分頁的索引與呈現；Google 也可能忽略這個設定。如果那些頁面有獨特的長尾內容，等於白白放棄一堆能帶流量的頁面。

我們在台灣市場實際觀察到，這種損失最常落在內容站的類別分頁上：文章累積到上百篇之後，「SEO 工具」這類主題分類的第 2 頁，常常是幾篇兩三年前寫、至今仍穩定承接長尾查詢的舊文唯一入口。一旦第 2 頁的 canonical 被指回第 1 頁，這些舊文就少了最後一條被發現的路徑；而且流量下滑時很難第一時間找到原因，因為報表上先消失的通常是那些長尾查詢，不是頁面本身。

流量之外，檢索面還有一層成本。Googlebot 是靠穩定的分頁連結與一致的訊號往深處走的；當分頁一方面出現在站內連結裡、一方面又被宣告成第一頁的重複，Google 得反覆重新判斷這批網址的關係，多出來的檢索輪次就是實際成本。網站規模越大、分頁越深，這筆帳越可觀，值得列入網站健檢的固定檢查項。

修正方向是把宣告權交還給每一頁：分頁串裡的每個網址各自指向自己（self-canonical），Google 才能沿著分頁連結把每一片清單都納入索引。整套分頁裡真正需要指向別頁的例外只有一個，即第一頁的雙重入口（/blog 與 /blog/page/1），讓後者指回前者即可；除此之外，任何一頁都不該把代表權交給其他頁面。

地雷三：Canonical 鏈（canonical chain）

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

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

若主題或外掛誤把全站 canonical 都指向首頁，會傳送錯誤的代表網址提示。Google 可能忽略不相似頁面的設定，也可能產生不理想的索引結果，不能預設全站一定只剩首頁。先修正輸出，再到Google Search Console檢查重要頁面與 Google 選擇的標準網址。

地雷五：跨網域授權與搬家的方向陷阱

Canonical 可以跨網域指定，但不能保證轉載文章一定由原站取得代表網址。Google 對內容聯播建議由合作方限制轉載版本的索引，而不是只依賴 canonical。網站永久搬家則以對應頁面的永久轉址為主，搭配新網址的 self-canonical；步驟可參考WordPress 搬家到新網域。

內容聯播不能只靠跨網域 canonical 避免轉載版出現在搜尋結果。Google 建議與合作方約定：若轉載版不應參與 Google Search，讓對方使用適當的 noindex，並允許 Google 爬取以讀取指令。授權條款與導流安排可參考內容聯播與授權指南；平台實作另見Medium SEO 策略。

若 Google 選了轉載版，不宜只憑網站規模就判定是「大站權重較高」。應比較內容、canonical、伺服器設定與索引限制。授權前先約定是否允許搜尋曝光；若對方必須被排除索引，單靠 canonical 無法提供這項保證。

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

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

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

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

要檢查站內連結是否指向網址變體，應用網站爬蟲或原始 HTML 匯出實際 href。GSC「連結」報表是抽樣資料，且會按標準網址分組，無法完整還原每個變體的內鏈分布。將爬取結果與 canonical、sitemap 比對，才能找出需要調整的連結。

記住一件事：重複網址不只是 SEO 排名的問題，它還會浪費你的檢索預算（crawl budget）。大量重複網址可能增加爬取成本，但不能由此斷定新頁一定爬不到。小型、更新不頻繁且新頁能正常爬取的網站，通常不必把 crawl budget 當成優先專案。對內容量大、更新頻率高的網站，這點影響特別明顯，檢索預算優化值得一併了解。

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

多語系網站通常讓各個翻譯頁使用自己的 canonical，並以 hreflang 連結語言或地區版本。若同語言的地區頁主要內容高度相同，也可能需要選定同語言的偏好版本。不要僅因主題相同就把所有翻譯頁都指向英文頁；錯誤提示可能影響版本選擇，但不等於其他語言一定完全消失。

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

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

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

你可能覺得 Canonical 是「進階技術 SEO」，可以晚點再處理。根據 Ahrefs 針對大量頁面的研究（2023 年 12 月），Ahrefs 樣本中約 96.55% 的頁面未被估算到 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都值得一起檢視。

分頁的上一頁、下一頁連結應穩定指向各自的代表網址。相對連結或 ?page=2 本身不是錯誤；重點是能解析到正確頁面、不要混入追蹤或不斷變動的參數，並讓內鏈、sitemap 與 canonical 保持一致。

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

Canonical 和 hreflang 衝突時，誰優先？

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

若 hreflang 與 canonical 指向不一致，先檢查標示的頁面是否可用、語言是否吻合，以及同語言重複版本如何選定代表網址。Google 不保證採用所有標記，也不能推定一處衝突必定讓整個多語系網站失效。

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

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

可每週檢查重要網址，並記錄 Google 上次爬取時間及標準網址選擇。重新爬取、索引與 canonical 重估沒有適用所有網站的固定完成期限；必要時透過提交 Sitemap與相關內鏈協助發現網址，再觀察重新處理後的結果。

同一頁的 canonical 和 noindex 同時出狀況，先排查哪一個？

先回到目的：這一頁的訊號該被「合併」到正本，還是這一頁該整個「退出」索引？兩種目的對應不同工具，排查的第一步就是把目的分清楚。若頁面是重複變體、你想把訊號集中到正本，就走 canonical 這條線修到底，頁面上不該再掛 noindex；noindex 傳達的是「排除索引」，和「合併到另一頁」的目標互相矛盾，同時出現等於給 Google 兩個打架的訊號。

若頁面本來就不該出現在搜尋結果（站內搜尋頁、極端篩選組合），工具是 noindex，且不要期待它的連結價值轉移到其他頁面。修完之後用網址審查確認 Google 實際處理的狀態，再回頭看報表變化。判斷依據可以直接套用前面 canonical、301、noindex 的對照表：先決定頁面的去留，再決定掛哪個標籤。

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

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

先用 Google Search Console 的網頁索引報表查看重複網址的未索引原因、數量趨勢與範例；它不是完整網址清冊。要知道某個網址實際被歸到哪個標準網址，請開啟該網址的網址審查，在已索引資料中比較「使用者聲明的標準網址」與「Google 選擇的標準網址」，並核對上次檢索時間。兩者不同時，先判斷 Google 選的版本是否合理，再排查衝突；即時測試不能預測 canonical 選擇（見 Google 網址審查說明）。報表的整體判讀可參考GSC 實戰技巧。

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

第三步是盤點網址參數。GSC 的 URL Parameters 工具已於 2022 年退場，不能再用它設定參數處理方式。改以爬蟲、伺服器紀錄與網站程式檢查排序、篩選及追蹤參數，再依內容用途選擇 canonical、轉址、索引限制或爬取管理。

第四步，如果你用 WordPress，檢查你的 SEO 外掛 Canonical 設定。Rank Math 和 Yoast 都有自動產生 Canonical 的功能，但它們的預設行為不見得符合你的需求。不要只看後台選項；實際抽查首頁、文章與第二頁等分頁的 HTML，確認是否輸出預期網址。若分頁被錯誤指向第一頁，再排查主題、外掛或自訂程式的衝突。確認外掛設定的最佳時機是網站剛上線、還沒累積太多內容的時候，事後改要動到幾百頁就麻煩了。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）會自動幫你產生這一行。但有三個格式細節會在實務上默默削弱訊號強度，你寫的時候一定要顧到。

第一，Google 建議使用絕對網址，例如 https://www.example.com/article/。相對網址也受到支援，但可能受測試網域或文件位置影響；使用完整網址較容易在搬站與部署時檢查目的地是否正確。

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

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

若要替 PDF、Word 文件等沒有 HTML <head> 的文件指定代表網址，可使用 HTTP 回應標頭。Google 對這種 canonical 方法的支援限於網頁搜尋結果，不能把它當成圖片搜尋去重的通用設定：

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

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

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

電商網站的商品變體頁是 canonical 最容易判斷錯的情境。假設你賣一件外套，有紅、藍、黑三色，每個顏色各有 S、M、L 三個尺寸，再加上一個「全部顏色全部尺寸」的商品主頁，總共會產生十個網址。十個網址賣的是「同一件外套」，但內容會因為顏色圖、庫存狀態而略有不同。此時需依網址設計與商品變體的實際內容選擇代表網址，不能用設定方式預測排名高低。用一張決策表來拆這件事：

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

要特別小心動態內容的陷阱。很多電商平台的商品變體頁會即時顯示庫存狀態、價格變動、甚至「目前有 N 人在瀏覽」，這些動態區塊會讓兩個變體頁的 HTML 看起來差很多。但它們的核心商品資訊（標題、規格、主描述）往往仍然完全相同。判斷時要把焦點放在「對搜尋意圖有意義的內容差異」上，別被這些裝飾性的動態元素帶偏方向；若使用可省略的參數切換同一商品變體，可依 Google 建議以省略參數的商品網址作為 canonical；獨立商品頁則應按實際內容與架構判斷。

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

Google 選擇不同的 canonical 時，先確認它選的版本是否更適合使用者，再排查內容與技術提示。下列八項是實務檢查清單，並非 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 封鎖，可能無法正確評估或索引目標頁，應先排查存取與索引限制。
7. hreflang 與 canonical 順序錯亂。多語系站把所有版本 canonical 到單一語系，可能產生不一致提示；應按語言與實際重複內容重新配置。
8. 頁面載入失敗導致 canonical 抓不到。如果 Googlebot 抓取時頁面因為 JavaScript 渲染問題、伺服器錯誤而沒有正常回傳 <head>，它就讀不到你的 canonical。排查：用 GSC 的「檢視轉譯後的網頁」功能確認 Googlebot 看到的內容。

可先確認目標頁能否正常存取及索引，再比對內容、內鏈、sitemap 與語言標記。這是方便排查的工作順序，沒有「前三項涵蓋八成」的通用統計；將每次觀察、修改與 Google 重爬時間記錄下來，較容易判斷修正是否有效。

Canonical 健檢與下一步行動方案

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

第一步：盤點你網站的重複網址。先在瀏覽器開啟幾個重要頁面，在網址後面測試網站實際使用的參數（?utm_source=test、?sort=price），看看這些變體網址是否也能正常開啟、內容是否跟正本一樣。再從 GSC 的網頁索引報表看看，有沒有大量被標記為「重複網址」的頁面。

第二步：確認 canonical 符合各頁用途。偏好的代表頁可設定 self-canonical；主要內容重複的追蹤或排序變體，應表達同一代表網址，而不是全部指向各自的變體。抽查首頁、分類、文章與分頁的實際 HTML，並核對 SEO 外掛（Rank Math 或 Yoast）的輸出；需要獨立索引且內容不同的頁面，不應只因版型相同就合併。

第三步：處理最嚴重的重複來源。從爬取資料確認問題範圍。沒有獨立用途的排序或追蹤變體，可統一連結與 canonical；需要永久淘汰的網址使用對應轉址。GSC 已沒有網址參數設定，篩選內容仍須在網站端依用途處理。

第四步：用 URL Inspection 驗證。修正後先測試線上版本，確認目前輸出正確；待 Google 重新檢索與處理，再查看已索引資料中的 Google 選定標準網址及檢索時間。沒有固定幾天或一週內完成的期限。若版本不同，先比較內容與訊號是否合理，不必反覆重設或重複提交。

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

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

Canonical 是網站維護的一環。若 Google 選擇了不適合的代表網址，或大量變體增加了爬取與報表管理成本，修正它有實際價值；但流量卡關仍可能來自需求、競爭、內容或其他技術因素，不能一律歸因於重複網址。

先確認網站是否真的存在 canonical 問題，再決定修正方式。Whoops SEO 的網站健檢可協助釐清代表網址、索引與內鏈設定；也可以先依上述五步自行抽查，將具體異常與後續處理結果記錄下來。