canonical 是什麼？重複網址的判斷與常見設錯

TL;DR

• canonical（標準網址）是建議不是命令，Google 的文件寫得很直白：這是 hint，不是 rule
• Google 會綜合協定、轉址、sitemap 收錄狀況與 canonical 標籤自行判斷，可能選一個跟你指定的不一樣的網址
• 最常見的重複來源不是內容抄襲，是同一份內容在 http、https、www、參數網址上各活一份
• 每一頁都該有指向自己的 canonical，這比只在重複頁上設更不容易出錯
• 要「合併」用 canonical，要「搬家」用 301 轉址，兩者不能互相取代

目錄

canonical 的效力：建議而非指令
重複網址的五個常見來源
自我參照 canonical 的作用與寫法
canonical 的四種常見設定錯誤
canonical 與 301 轉址的適用時機
canonical 是否生效的三層檢查
重複網址對 AI 搜尋引用的影響

引言

大部分人第一次認真研究 canonical，是因為 Search Console 跳出那句「Google 選擇的標準網址與使用者指定的網址不同」。訊息本身沒有情緒，但它的意思其實不太客氣：你指定了一個網址，Google 看過了，然後選了別的。

canonical（中文文件譯作「標準網址」）解決的是一個很無聊但很普遍的問題——同一份內容出現在好幾個網址上。搜尋引擎不希望在結果裡放五個一模一樣的頁面，所以它會挑一個代表。canonical 是你在這場挑選裡表達意見的方式。

只是「表達意見」這四個字，比多數教學文寫得還要精確。

canonical 的效力：建議而非指令

Google 官方文件對這件事的措辭沒有模糊空間：

indicating a canonical preference is a hint, not a rule

出自 Google Search Central 的標準網址說明。同一份文件也列出它實際會參考的訊號：是否使用 HTTPS、轉址的指向、網址有沒有出現在 sitemap 裡，以及 rel="canonical" 標籤。

canonical 是四種訊號之一，不是開關。當這些訊號彼此打架——例如標籤指向 A、sitemap 只收錄 B、而 A 又會轉址到 C——Google 就會自己做決定，而它的決定不需要跟你一致。

這個認知會改變你除錯的方式。看到「Google 選了別的網址」時，第一個該問的不是「標籤是不是壞了」，而是「我有沒有同時送出互相矛盾的訊號」。

重複網址的五個常見來源

遇到的重複極少是內容被抄。多數是同一份內容自己長出好幾個門牌：

協定沒收斂。 http://example.com/ 與 https://example.com/ 如果都回傳 200（也就是兩個都打得開、都有內容），對搜尋引擎而言就是兩個網址。這是最容易被忽略的一種，因為人用瀏覽器看不出差別——瀏覽器會自動補上協定，你根本不會注意到自己走的是哪一條。

www 與非 www 沒收斂。 同樣的道理，www.example.com 與 example.com 是兩個主機名稱。

語言前綴重複。 多語網站常見 / 與 /tw/ 兩個網址內容幾乎相同——一個是預設語言，一個是明確指定中文版。兩邊都能開，內容一樣。

參數。 ?utm_source=fb、?sort=price、?page=1 這類參數會產生無數個技術上不同、內容上相同的網址。

分頁與篩選。 商品列表的第一頁常常同時存在於 /products 與 /products?page=1。

這幾種可以並存，而且會相乘。一個沒收斂協定又沒收斂 www 的網站，光首頁就有四個版本。

自我參照 canonical 的作用與寫法

有個常見的誤解是「canonical 只要設在重複的那幾頁就好」。更穩的做法是每一頁都輸出一個指向自己的 canonical，業界稱為自我參照（self-referencing canonical）。

理由很實際：你不會知道自己的網址被誰用什麼形式引用。有人在社群貼文加了追蹤參數、有人用 http 開頭轉貼、有人補了 www。這些網址一旦被爬到，如果頁面上有指向乾淨網址的 canonical，訊號就會收斂回同一個；沒有的話，它們各自成立。

自我參照要注意的是絕對網址：寫 <link rel="canonical" href="/about"> 這種相對路徑，在 http 與 https 兩種情況下會解析成不同結果，等於什麼都沒收斂。一律寫完整網址，含協定與主機名稱。

canonical 的四種常見設定錯誤

第一種，整站每頁都指向首頁。 這通常是模板寫死造成的。後果不是「內頁的權重都集中到首頁」，而是內頁根本進不了索引——你等於在跟 Google 說每一頁都是首頁的複本。

第二種，兩個近乎相同的頁面各自指向自己。 這是自我參照的反面案例：/ 與 /tw/ 內容幾乎一樣，各自宣告自己是標準網址，於是誰都沒有讓步，Google 只好自己挑一個。可能挑到你不想要的那個，也可能兩個都留著互相稀釋。

第三種，canonical 指向一個會轉址的網址。 標籤說「請用 A」，A 又轉去 B。多一層轉折就多一次判斷，而 Google 完全可能直接跳過你的建議。

第四種，跨協定或跨主機不一致。 頁面在 https://www.example.com/about，canonical 卻寫 http://example.com/about。三個變數（協定、www、路徑）錯一個就前功盡棄。

四種的共同形狀是同一個：訊號互相矛盾。canonical 沒有壞掉，是它被別的訊號蓋過去了。

canonical 與 301 轉址的適用時機

這兩者常被混用，但它們回答的是不同問題。

判斷方式很單純：這兩個網址都還需要有人能打得開嗎？ 需要就用 canonical，不需要就用 301。

商品列表的排序參數頁要留著給使用者點，那用 canonical。網站換域名、舊網址沒有存在的理由了，那用 301。

換域名這件事特別要留意狀態碼。Google 的 HTTP 狀態碼說明裡，301 與 302 的差別是訊號強弱而不是有無：301 被視為 strong signal（強訊號）、302 是 weak signal（弱訊號）。常見的「302 完全不移轉權重」說法比官方措辭來得絕對。

即使如此，實務結論不變：確定不會回頭就用 301。用 302 表達永久搬遷，等於用一個弱訊號去說一件確定的事，搬遷會遲遲無法完成。而這種錯誤在瀏覽器上完全看不出來，因為兩種狀態碼的畫面表現一模一樣。

canonical 是否生效的三層檢查

僅確認原始碼中是否有該行並不足夠，需要分三層檢查。

第一，標籤本身。 用指令列直接看，比在瀏覽器裡翻原始碼快：

curl -s https://example.com/about | grep -i canonical

第二，協定與主機有沒有收斂。 這是我認為最值得優先檢查的一項，因為它最常被忽略而且影響最廣。分別打四個版本，看回應狀態碼：

for u in http://example.com/ https://example.com/ \
         http://www.example.com/ https://www.example.com/; do
  echo "$(curl -s -o /dev/null -w '%{http_code} → %{redirect_url}' "$u")  $u"
done

健康的結果是只有一個回 200，其餘三個回 301 並指向它。如果出現兩個以上的 200，代表同一份內容在多個網址上各自成立。

第三，Google 實際怎麼判斷。 前兩項確認的是你送出了什麼訊號，這一項才是結果。到 Search Console 的「網頁索引」報表，用網址審查工具查單一頁面，它會同時顯示「使用者指定的標準網址」與「Google 選擇的標準網址」。兩者不同時，回頭檢查上面那四種設錯。

這三項都無法保證 Google 一定照辦。 你能做的是把訊號整理到不互相矛盾，剩下的是它的判斷。任何宣稱能「強制指定」標準網址的說法，都與官方文件相牴觸。

重複網址對 AI 搜尋引用的影響

生成式搜尋改變了結果的樣子，但沒有改變索引的機制。ChatGPT、Perplexity 這類服務在回答時引用某個網址，前提仍然是那個網址被抓取、被判定為代表版本。

同一份內容散在四個網址上，對 AI 系統的影響其實比對傳統搜尋更直接：它要判斷「這個主題的來源是誰」，而分裂的網址讓同一個實體看起來像四個。內容再好，也會因為訊號分散而稀釋。

這不是新的技術要求，而是既有的技術基礎在新場景裡的權重提高了。canonical、301、協定收斂這些行之有年的做法，做好不保證內容被引用，但沒做好會讓內容在被納入考慮之前就先流失掉。

要驗證的話，最小成本的方式是把上面那段四個網址的檢查跑一次。多數網站跑完會發現至少一項不合格，而那通常是三十分鐘之內可以修完的事。