www 與 non-www 網址差異全解析：SEO 影響、優缺點比較與正確設定方法
www 與 non-www 本身不會改變 Google 排名，真正的 SEO 風險在於兩個版本同時被索引造成的重複內容、權重分散與資料失真。Google Search Centra…
www vs non-www 差別與 SEO 影響：偏好網域收斂才是真戰場
www 與 non-www 本身不會改變 Google 排名，真正的 SEO 風險在於兩個版本同時被索引造成的重複內容、權重分散與資料失真。Google Search Central 官方文件說明，www.example.com 與 example.com 對搜尋引擎是兩個不同的網址，內容相同時會被當成重複頁面處理，正確做法是鎖定單一偏好網域，用 301 轉址與 canonical 標籤收斂成一個版本。
重點先看：www 或 non-www 選哪個都不影響排名，真正會拖垮 SEO 的是兩個版本同時被索引。根據 Google 官方說明，301 永久轉址能傳遞累積的排名權重，是收斂偏好網域的首選做法。
很多剛架站的站長，對話常常從一句話開始：「我的網址到底要不要加 www？」不少人在申請 網域時就卡在這一步，深怕選錯了排名從此翻車。老實說，這個糾結大多擺錯了重點。選 www 還是 non-www 純粹是技術配置問題，真正會讓你的網站 SEO 出問題的，是兩個版本同時存在卻沒有收斂。網址本身在 SEO 裡的角色，也是很多人沒先搞清楚就急著選版本的原因之一。這件事其實不複雜，從本質差異、優缺點、SEO 風險，到 301 與 canonical 標籤設定，再到 WordPress 後台檢查，有一套可以照著走的判斷流程。
www 與 non-www 的本質差異
www 是 World Wide Web（全球資訊網）的縮寫，本質上是一種子網域前綴，例如 www.example.com；non-www 則是直接使用裸網域（apex domain），例如 example.com。兩者在技術上都指向同一個網站，但對搜尋引擎來說是兩個完全不同的網址，這正是後面所有 SEO 風險的源頭。要把這層差異看清楚，先回頭理解網址的組成結構會很有幫助，連帶也能釐清網域與網址怎麼區分。
要理解 www 為什麼存在，得回到網路還很年輕的那個年代。早期沒有託管商，品牌只能把網站資料放在自家伺服器上自己管。一台伺服器可能同時跑好幾種服務：對外開放的網頁、對內傳檔的 ftp、收發信件的 mail。為了讓人知道哪個位置是給一般使用者看的網頁，就用 www 這個子網域來區分，ftp 用 ftp.、信件用 mail.，各司其職。那是一個用子網域做伺服器分工的年代。
但這套分工邏輯，今天已經沒有絕對必要。現代託管技術成熟，虛擬主機、雲端主機能在一台機器上用網址路徑或設定檔搞定不同服務，不必再靠 www 這三個字來切分。再加上裸網域看起來更乾淨，所以越來越多新站直接用 non-www 開場。不過 www 並沒有消失，很多大型網站、媒體、企業官網還是繼續用，原因出於它在技術上有 non-www 沒有的好處，後面講 Cookie 作用範圍時會一併提到。
有一個觀念得先講死：www 與 non-www 之間的差別，本質在於「它們是兩個不同的網址」，排名高低與此無關。根據 Google Search Central 的說明，搜尋引擎會把 www.example.com 與 example.com 當成兩個獨立網址處理。這個認知沒建立，後面談的重複內容、SEO 地雷、權重分散都會聽得很模糊。
- www：子網域層級，例如 www.example.com，早期用來標示對外網頁伺服器。
- non-www：根網域（裸網域），例如 example.com，網址更短、更直接。
- 共通點：兩者頁面內容可以完全相同，這正是搜尋引擎判定重複內容的觸發條件。
www vs non-www 優缺點比較：選擇前該知道的技術與體驗差異
www 的優點是能限制 Cookie 作用範圍、與多數 CDN 及 DNS 記錄相容性較高；non-www 的優點是網址更短、更好記、更適合品牌呈現。選擇應該依網站規模、是否使用多個子網域、CDN 需求與品牌美觀決定，不能只看哪個網址比較短。版本之外，網址命名與結構規劃得好壞，對長期收錄的影響同樣不容小覷。
這裡得替 www 平反一下。網路上太多文章一口咬定「選 non-www 就對了」，理由不外乎「比較短、比較好看」。短當然沒錯，但如果你營運的是一個有多個子網域的中大型站點，www 反而更省事。原因出在 Cookie 的作用範圍。
當你在裸網域 example.com 設定 Cookie，這個 Cookie 預設會傳遞到所有子網域，包括 blog.example.com、shop.example.com、app.example.com。意思是使用者每次開你的子網域頁面，瀏覽器都會把這坨 Cookie 帶過去，拖慢載入速度，也讓 CDN 快取變得困難，因為帶 Cookie 的請求無法被乾淨地快取。反過來，如果你主網域是 www.example.com，Cookie 就只會作用在 www 這個子網域，乾淨俐落地跟其他子網域切開，這是 RFC 6265 對 Cookie Domain 屬性的預設行為。對一個跑很多子網域的站，這個差別是真的有感。
這個機制可以再拆細一層。Cookie 的範圍由 Domain 屬性決定：設成 example.com 時，瀏覽器會把這個 Cookie 套用到 example.com 本身與所有子網域；設成 www.example.com 時，則只套用到 www 這一層。差別看似只是幾個字元，落到一個跑著會員系統、購物車、追蹤像素的中大型站點，每個子網域請求都會把整套 Cookie 上傳一遍，對行動裝置與慢網速使用者的影響尤其明顯。在行動流量已占全球網路流量過半的今天，這類效能損耗會直接反映在載入體驗與跳出率上 [來源：Statista〈Share of mobile web traffic worldwide quarterly 2015-2026〉 https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 2026-04-28]。這也是為什麼講求效能的站，會傾向把主網域放在 www，再用 Set-Cookie 時指定 Domain=www.example.com，或乾脆搭配靜態資源專屬子網域（例如 static.example.com）來做到零 Cookie 的乾淨快取。
另一個常被忽略的點是 DNS 與 CDN 相容性。裸網域的 DNS 只能用 A 記錄指向一個 IP，而不少大型 CDN（例如部分雲服務）在裸網域的設定上有限制，或得靠 CNAME Flattening 這類技巧才能搞定。www 就沒這個問題，它是一般的子網域，可以自由用 CNAME 指向任何 CDN。說到底，www 並非絕對更好，只是在某些技術情境下比較不會踩雷。
舉一個具體的設定落差。假設你用的是某家大型 CDN，它會給你一組主機名稱（例如 yourzone.cdncdn.net）要你用 CNAME 指過去。在 www.example.com 這層，你只要在 DNS 加一筆 CNAME 記錄把 www 指到那組主機名稱，幾分鐘生效。但在裸網域 example.com 這層，DNS 規範原本不允許根網域掛 CNAME，於是你得看主機商有沒有提供 CNAME Flattening（把 CNAME 在根網域「壓平」成 A 記錄），沒有的話就只能改用 A 記錄綁死一組 IP，日後 CDN 換節點或做流量調度時彈性就變小。這條技術門檻在小型站看不出差別，但對需要跨區流量調度、做 failover 或接多家 CDN 的站，www 的相容性會讓維運省下不少麻煩。
| 比較項目 | www | non-www |
|---|---|---|
| 網域層級 | 子網域 | 裸網域（根網域） |
| 網址長度 | 較長，多出 4 個字元 | 較短，視覺簡潔 |
| Cookie 作用範圍 | 可限定在 www，不外溢子網域 | 預設外溢到所有子網域 |
| CDN／DNS 相容性 | 支援 CNAME，相容性高 | 裸網域 A 記錄限制較多 |
| 品牌記憶度 | 較冗長 | 好記、好輸入 |
| 適合場景 | 多子網域、大型站、用 CDN | 小型品牌站、部落格 |
換個角度想，這張表的訊息其實很單純：www 與 non-www 沒有絕對的優劣，只有適不適合你的網站架構。小型品牌站、部落格，non-www 短網址在視覺與記憶上吃香；但如果你打算做一個有論壇、商城、會員系統的多子網域站，www 在 Cookie 隔離與 SSL、CDN 設定上會讓你少很多事。
重點再強調一次：兩個版本之間沒有誰比較好，鎖定一個之後就要貫徹到底。最糟的情況是兩個版本都開著、都收流量、都進 Google 索引，重複內容與權重分散的問題就會跟著來。
www 與 non-www 同時存在的 SEO 風險：重複內容、權重分散與資料失真
兩個版本同時存在會被 Google 當成內容一模一樣的兩個頁面，導致重複內容判定、反向連結權重分散、爬取預算浪費，以及 Google Analytics 資料被拆開計算，整體排名與分析都會失真。這些風險才是 www 與 non-www 議題真正該優先處理的部分。
我把這稱為「沉默的 SEO 漏洞」，因為它不像 低品質內容或被降權那樣有明顯症狀。你的網站看起來好好的，流量也在跑，但權重其實一直被分攤到兩個網址上。拆開來看，主要有四個層面的傷害。
重複內容稀釋排名訊號
既然 www 與 non-www 是兩個獨立網址，而你的內容又一模一樣，Google 就得在這兩個版本之間做選擇。它會自己挑一個當主要版本來排名，另一個則被歸類為重複。問題是你沒辦法保證 Google 挑的就是你想要的那個版本，更麻煩的是，兩個版本各自的排名訊號會被拆開計算，無法集中累積。一篇明明有潛力的文章，排名訊號被劈成兩半，等於自己把站內 SEO 的力道打折。這也是為什麼 Google 搜尋演算法面對兩個相同內容的網址時，會傾向只挑一個版本排名；背後那套比對相關性的評分機制，可從BM25 如何決定檢索排序一窺原理。
再細看 Google 處理重複內容的方式。當系統偵測到兩個或多個內容實質相同的網址，它會進行「叢集化（clustering）」，把這群網址視為同一組，再從中選出一個代表版本（canonical URL）參與排名，其餘版本則降級為備援，通常不出現在主搜尋結果。Google 會根據頁面本身的訊號強度、被連結的數量、https 與否、sitemap 中的宣告等多重線索來挑代表版本。問題在於：你完全無法保證它挑的版本就是你心中那個。如果它把 non-www 選成代表版本，而你所有行銷素材、名片、廣告到達頁都打 www，使用者的點擊與外連權重就會持續灌到「非代表版本」上，等於在系統眼中自廢武功。把這個風險關掉的唯一方法，就是你主動用 301 與 canonical 明確宣告偏好版本，把選擇權從 Google 手中拿回來。
反向連結權重被分散到兩個版本
反向連結是 Google 排名的重要訊號之一。假設 A 網站連到你的 www.example.com，B 網站連到你的 example.com，這兩條連結的權重會分別加到各自的網址版本上，無法集中。除非你設了轉址或 canonical，否則這些來之不易的反向連結價值就被攤薄了，這在 Backlink 指南裡是被反覆強調的觀念。對一個認真經營內容的站來說，這種無形的流失是最心痛的，因為你根本不知道自己損失了多少。
這層流失的代價有多高，可以從一份大規模數據看出來。Backlinko 分析了 1,180 萬個 Google 搜尋結果後發現，排名 #1 的結果平均擁有比 #2 至 #10 多出 3.8 倍的反向連結，也就是說反向連結的累積量與排名位置高度相關 [來源：Backlinko〈Search Engine Ranking: We Analyzed 11.8 Million Google Search Results〉 https://backlinko.com/search-engine-ranking 2025-04-14]。當你的外連被拆到 www 與 non-www 兩個版本，等於是主動放棄集中累積這個關鍵訊號的機會，把排名競爭力從一開始就打折。
同一份研究還點出一個更刺眼的數字：大約 95% 的網頁連一條反向連結都沒有 [來源：Backlinko〈Search Engine Ranking: We Analyzed 11.8 Million Google Search Results〉 https://backlinko.com/search-engine-ranking 2025-04-14]。多數站長要拿到任何一條外連都得費盡功夫，好不容易累積起來的連結卻因為版本沒收斂而被拆散，這在實務上是最容易被忽略、卻也最划不來的失分。把這兩個數字擺在一起看就更清楚：外連本來就稀缺，每一條都該集中灌到同一個網址，任何拆分都是在稀釋你手上最珍貴的排名籌碼。
爬取預算被同一份內容吃掉兩次
搜尋引擎的爬取預算（crawl budget）是有限的。根據 Google Search Central 對爬取預算的說明，爬蟲分配給每個網站的抓取資源有上限，網站規模越大、頁面越多，這個上限越顯得珍貴。當同一份內容同時存在 www 與 non-www 兩個網址，爬蟲可能會把同一份內容爬兩次，等於把預算浪費在重複的頁面上，導致你真正希望被收錄的重要頁面反而排不到。對小型站影響有限，但對頁面數量龐大的網站，這就是實實在在的爬取預算浪費。
判斷要不要在意爬取預算，有一個粗略的界線。一般經驗上，頁面數在數千以下、更新頻率不高的小型站，Google 的爬取速度通常遠遠夠用，重複版本造成的浪費多半看不出影響。但若你的站屬於大型內容站、電商、論壇、新聞媒體，動輒數萬到數百萬個網址，爬取預算就會成為收錄速度的硬瓶頸。這類站點每多一個被重複爬取的版本，就等於擠掉了其他新內容被發現的機會。觀察的方法是到 Search Console 看「網頁索引」報表，若你看到大量「已檢索，但目前未建立索引」或收錄進度異常緩慢，又同時存在 www 與 non-www 兩組網址都在被抓取，那多半就是爬取預算被吃掉的訊號。
GA 資料被拆成兩份，判讀失準
這個是看過最多站長中招的坑。當 www 與 non-www 兩個版本同時收流量，Google Analytics 會把這兩份流量分開記錄。某篇文章在 www 版本有 500 次瀏覽，在 non-www 版本有 300 次，但你看到的報表可能是分開的兩筆，看起來像兩篇表現普通的文章，而不是一篇表現不錯的文章。跳出率、工作階段、轉換率全都會被這種拆分扭曲，你做的任何分析與決策都建立在失真的資料上，這也是網站流量下滑時最容易被忽略的隱形原因。
Google Analytics 之所以會把兩個版本拆開，是因為它預設把不同主機名稱視為不同網站。GA 在計算工作階段時，會比對追蹤程式碼所在頁面的網域，www.example.com 與 example.com 對它來說是兩個不同的來源，於是同一個使用者在兩個版本之間跳轉，可能被算成兩次獨立的工作階段，轉換也可能被歸因到錯誤的版本。這個影響層面很廣：行銷活動的成效歸因失準、A/B 測試的數據失真、工作階段定義被打亂，連帶讓你對「哪一篇內容真的有效」的判斷出錯。畢竟 GA 是目前最普及的分析工具，市占涵蓋範圍極廣 [來源：W3Techs〈Usage Statistics and Market Share of Google Analytics〉 https://w3techs.com/technologies/details/ta-googleanalytics 2026-06-29]，多數站長的決策幾乎都建立在它的報表上，資料一旦失真，後面的判斷全跟著歪。根解的辦法始終只有一個：收斂偏好網域，讓所有流量彙整到單一網址。
「www 與 non-www 本身不會改變 Google 排名，真正會拖垮 SEO 的是兩個版本同時被索引，導致重複內容、反向連結權重分散與爬取預算浪費。」
退一步看，這四個風險的共同根源只有一個：你讓 Google 同時看到兩個版本的網站。把這個根源解掉，四個風險會一起消失，而解法就是收斂偏好網域。過渡期想避免次要版本繼續被收錄，也可以評估用 noindex 暫時擋住的輔助做法。
四個風險的嚴重程度評分表
並非每個風險對每個網站都同等致命，影響程度會依網站類型而不同。底下這張評分表把四個風險依「影響範圍、可逆性、發現難度」三個維度做分級，方便你照自己的站點類型抓出最該優先處理的項目。評分採 1 到 5 分，分數越高代表該風險對該類型網站的殺傷力越大。
| 風險項目 | 小型部落格 | 中型品牌站 | 大型內容/電商站 | 說明 |
|---|---|---|---|---|
| 重複內容稀釋排名 | 3 | 4 | 5 | 頁面越多，被拆分的訊號越分散 |
| 反向連結權重分散 | 4 | 5 | 5 | 外連稀缺，任何拆分都會稀釋 |
| 爬取預算浪費 | 1 | 2 | 5 | 小型站預算充裕，大型站才吃緊 |
| GA 資料拆分失真 | 3 | 4 | 4 | 影響決策正確性，不分規模 |
從這張表可以看出一個清楚的優先順序：不論網站規模，反向連結權重分散都排在前段，因為外連是所有站點都稀缺的資源；而爬取預算浪費對大型站的殺傷力遠高於小型站。拿著這張表對照自己的站點類型，就能決定收斂偏好網域時，要先盯著哪一個指標驗收。
301 轉址與 canonical 標籤，該怎麼把偏好網域收起來
最推薦的做法是設定 301 永久轉址，把次要版本完整導向主要版本並傳遞權重；若無技術資源修改伺服器，可改用 canonical 標籤告訴搜尋引擎首選版本，但 301 仍是首選，因為它直接搬移權重與流量。
決定偏好網域之後，第一件事就是把另一個版本收掉。收的方法有兩條路：301 轉址與 canonical 標籤。我強烈建議兩條都做，301 當主力，canonical 當第二道保險。
301 轉址：收斂偏好網域的首選
301 是「永久移動」的 HTTP 狀態碼，會通知搜尋引擎與使用者這個網址已經永久搬到新位置。根據 Google Search Central 對 301 轉址的說明，301 轉址能將舊網址累積的大部分排名權重傳遞到新網址。對收斂偏好網域來說，這是最直接有效的方法，因為它不只告訴爬蟲版本統一，連使用者與外部連結的流量也一併導向主要版本。
如果你的主機是 Apache，可以在網站根目錄的.htaccess 檔案寫入轉址規則。假設你的偏好網域是 non-www，也就是要把 www.example.com 導向 example.com，可以這樣寫：
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
反過來，如果你的偏好網域是 www，要把 example.com 導向 www.example.com，則是：
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
改.htaccess 之前請務必備份原檔，寫錯規則可能讓整站 500 錯誤，備份外掛能幫你先做一份完整快照。Nginx 主機則是在 server 區塊用 return 301 處理，邏輯一樣，只是語法不同。如果你對伺服器設定不熟，也可以用 WordPress 轉址外掛或 搬家轉址攻略來處理，不用碰程式碼。
給 Nginx 使用者補一段對應的設定。若偏好網域是 non-www，要在監聽 www.example.com 的 server 區塊裡加一行 return 301 https://example.com$request_uri;，並讓 example.com 的 server 區塊成為實際提供內容的預設主機。相反方向也一樣，只要把目標改成 www.example.com 即可。Nginx 不像 Apache 有 .htaccess 可在每個目錄覆寫，所有規則都集中在設定檔，改完記得用 nginx -t 測試語法、再 reload 生效，避免設定錯誤導致整站掛掉。
canonical 標籤：301 之外的第二道保險
canonical 標籤是一段放在 HTML <head> 裡的標記，用來告訴搜尋引擎「這個頁面的首選版本是哪個網址」。根據 Google Search Central 對 canonical 標籤的說明，canonical 能幫助搜尋引擎在多個相似網址之間判斷主要版本。它的好處是操作門檻低，不需要改伺服器，但效果不如 301 直接，因為它只是「建議」，搜尋引擎不見得完全遵從。
假設你的偏好網域是 www，可以在 non-www 頁面的 <head> 加入：
<link rel="canonical" href="https://www.example.com/" />
對 WordPress 站長來說，好消息是近期的 WordPress 版本會自動產生 canonical 標籤，不需要手動加，但你還是要回頭確認 301 是否設對，因為 canonical 解決不了使用者與流量被分散的問題，只有 301 能把人真的導過去。這也是為什麼我一直把 301 當主力。
- 收斂偏好網域，首選 301 轉址，權重、流量、使用者一次導到位。
- canonical 標籤門檻低，但只是給搜尋引擎的建議，當第二道保險用。
- 兩者並用時，301 負責轉向，canonical 接手被快取或漏掉的頁面。
不管你選哪個方法，目的都只有一個：讓 Google 只索引你偏好的一個版本。確認收斂是否成功，可以到 Google Search Console 或參考 Search Console 操作技巧看網址檢查結果，或是用 收錄查詢確認另一個版本已經不再被索引。
301 與 canonical 怎麼分工：收斂偏好網域的雙保險策略
很多人會問，既然 301 已經把版本收掉了，為什麼還要再補 canonical？答案在於這兩個機制作用的對象與時機不同。301 是伺服器層級的硬轉向，使用者與爬蟲一打開次要版本，就會被直接搬到主要版本，權重也會隨之轉移；但 301 生效需要時間發酵，舊網址在 Google 索引裡還會殘留一陣子，這段空窗期若有任何頁面因為快取、CDN 或舊連結沒走完轉址，就可能被當成獨立網址處理。canonical 補的就是這個縫隙：它在 HTML 層級持續向搜尋引擎宣告首選版本，即使某個次要版本的頁面被爬到，canonical 也會把它指回主要版本，避免產生新的重複判斷。
| 比較維度 | 301 轉址 | canonical 標籤 |
|---|---|---|
| 作用層級 | 伺服器／HTTP | HTML <head> |
| 對使用者 | 直接轉向到新網址 | 無影響，使用者看到原頁面 |
| 對搜尋引擎 | 強制搬移權重與索引 | 提供建議，由搜尋引擎決定是否採納 |
| 生效速度 | 即時轉向，權重轉移需時間 | 需等爬蟲重新抓取後生效 |
| 適合場景 | 版本統一、搬家、刪除頁面 | 相似內容、參數網址、分頁 |
| 主要風險 | 設定錯誤可能造成迴圈或整站掛掉 | 被搜尋引擎忽略，效果不保證 |
實務上的搭配順序是這樣：先設好 301，把絕大多數次要版本的流量與權重一次導過去；再補上 canonical，處理那些因為各種技術因素沒走完 301 的漏網之魚。兩者並行的好處是覆蓋面最廣，缺點是設定變多、除錯也更複雜。對技術資源有限的小型站，只做 301 通常已經夠用；但對頁面數量大、外部連結來源複雜的中大型站，雙保險值得多花那一點設定成本。
WordPress 站長實作：檢查與修改 www 與 non-www 設定
登入 WordPress 後台到「設定」然後「一般」，查看「WordPress 位址（網址）」與「網站位址（網址）」兩欄，即可確認目前使用的版本；兩欄必須一致且指向正確網域。除非有明確需求，否則不要輕易切換，以免影響已累積的排名與收錄。
很多 WordPress 使用者根本不知道自己現在用的是哪個版本，這很正常，因為後台預設不會特別標示。但這件事你得搞清楚，否則後面所有技術 SEO 設定都會對不上。WordPress 是目前市占最高的內容管理系統，全球過半的 CMS 站點都建立在它之上 [來源：W3Techs〈Usage Statistics and Market Share of WordPress〉 https://w3techs.com/technologies/details/cm-wordpress 2026-06-29]，意味著這套檢查流程適用於絕大多數站長。檢查的方法很直接。
- 登入 WordPress 後台，左側選單點「設定」裡的「一般」。
- 找到「WordPress 位址（網址）」與「網站位址（網址）」兩個欄位。
- 確認這兩欄的網址是否完全相同，且開頭是 http 還是 https、有沒有 www。
- 兩欄必須一致，並與你設定的偏好網域相同，否則會產生轉址迴圈或重複內容。
- 確認無誤後，到主機端補上對應的 301 轉址，把另一個版本收掉。
- 提交主要版本的 sitemap，並到 Search Console 觀察次要版本是否逐步退出索引。
這裡要特別提醒一個 WordPress 常見的坑：改網址欄位時，如果兩欄不一致，或忘了先把 301 設好就貿然切換，網站可能直接打不開，出現太多重新導向的錯誤。所以我才會反覆講，修改網址前務必先備份，並準備好對應的 301 規則，確認能正確導向再下手。
如果你的網站已經在 Google 累積了排名，貿然從 www 切換到 non-www（或反過來），短期內可能出現收錄與排名波動。這不代表一定會掉排名，但你需要把 301、canonical、sitemap 提交、Search Console 偏好網域設定這幾件事一次做到位，讓 Google 盡快理解新版結構。搭配 Rank Math、SEO 外掛評測或 SEO 外掛教學可以幫你檢查 canonical 與轉址設定是否正確，省下手動排查的功夫。
還有一個不少人忽略的設定：Search Console 裡的偏好網域。你應該同時新增 www 與 non-www 兩個資源，然後在設定裡指定哪一個是偏好版本，並提交對應版本的 sitemap，順手補上網站結構與技術性 SEO 檢查。資源還沒建好的話，先完成Search Console 安裝設定再來指定偏好版本。這能加速 Google 收斂到你要的版本，縮短波動期，搭配報表日期的快速區間比對切換前後的數據，更能確認收斂是否到位。
收斂偏好網域前的健檢清單
動手改設定之前，先把現況摸清楚，能避免絕大多數的切換事故。這份清單把收斂偏好網域該做的檢查與準備動作依先後順序排好，照著走可以讓整個過程透明可控。每一項都建議在實際切換前完成，寧可多花十分鐘檢查，也不要事後花十天救火。
- 確認目前偏好版本：用瀏覽器分別打開 www 與 non-www，看哪一個會被 301 導向另一個，導向終點就是你現在實際的偏好版本。
- 盤點外部連結：用 反向連結工具查一下，多數外連指向哪個版本，這有助於你判斷要保留哪一個以減少權重流失。
- 備份網站：包含資料庫與檔案，備份外掛或主機快照都行，確保出問題時能完整還原。
- 記錄現有設定：截圖或抄下 WordPress 後台兩欄網址、現有的 301 規則、canonical 設定，作為回滾的依據。
- 準備好反向 301 規則：先在測試環境跑過一次，確認規則能正確把次要版本導向主要版本，不會產生迴圈。
- 挑離峰時段執行：避開流量高峰，萬一出問題影響面最小，也方便即時觀察數據。
- 執行後立即驗收：用瀏覽器與 curl 檢查 HTTP 狀態碼是否回 301、目標是否正確，再到 Search Console 觀察收錄變化。
- 更新 GA 與廣告到達頁：把 Google Analytics 追蹤的網域版本、Google Ads 到達頁網址都指向新的偏好版本。
這份清單的精神很單純：把不可逆的動作往前推到可逆的準備階段。所有可能在切換當下出錯的環節，都先在備份與測試環境跑過一遍，真正上線時就只剩執行與驗收。對已經累積排名的站，這個前置作業尤其重要，因為任何一次處理馬虎都可能讓排名短期波動。
常見的轉址錯誤與排查方法
收斂偏好網域最常見的失敗，往往出在 301 規則本身。規則寫錯的症狀很有辨識度，對症排查可以把除錯時間壓到最短。底下整理幾個最常踩的錯誤與對應的排查思路。
- 轉址迴圈（ERR_TOO_MANY_REDIRECTS）：www 與 non-www 互相指向對方，或 WordPress 後台兩欄網址與主機 301 規則衝突。排查時先暫時關掉主機端 301，只看後台兩欄是否一致，再逐條把 301 規則加回去，找出造成迴圈的那一條。
- 用了 302 而非 301：302 是暫時轉向，不會把權重傳遞過去。用瀏覽器開發者工具或 curl 檢查回傳狀態碼，確認是 301 而非 302 或 307，否則收斂形同沒做。
- 只轉首頁、沒轉內頁：規則漏寫 path 傳遞，導致 www.example.com/post-a 沒被導到 example.com/post-a。確認 RewriteRule 帶有
$1或對應的 path 變數，並測試至少一個內頁網址。 - http 與 https 同時收斂沒處理：版本收斂常與 http 到 https 的強制轉址疊加，順序錯了會再次迴圈。建議先统一協定（http 全部 301 到 https），再在同一協定下做 www 與 non-www 的收斂。
- canonical 指向相對路徑：canonical 用了相對路徑或漏寫協定，搜尋引擎可能誤判。canonical 一律用絕對網址（含 https 與網域），避免歧義。
- CDN 或快取把舊版本卡住：設完 301 後部分訪客仍看到舊版本，多半是 CDN 或瀏覽器快取。設定完成後記得清除 CDN 快取，並觀察幾天確認全域生效。
排查時一個好用的習慣是建立一個固定的測試網址清單，包含首頁、一篇內頁、一個分類頁，每次改完規則都逐個用 curl 看回傳的狀態碼與 Location 標頭。這個動作不到五分鐘，卻能抓掉九成以上的設定錯誤，遠比等使用者回報「網站打不開」再回頭找問題省事。
www 或 non-www 到底選哪一個：依場景給的決策建議
對一般品牌網站、部落格，non-www 網址短、好記，是新站的常見選擇；但若網站規模大、使用多個子網域、需要 CDN 或嚴格的 Cookie 隔離，www 在技術管理上更省事。決定後就不要再換，並立刻設好 301 與偏好網域。
講到這裡，回到最初那個問題：到底選哪一個？答案不是制式的「選 non-www」，要依你的網站架構來決定。各種情境的建議整理在底下的決策表，你可以對照自己的狀況。
| 網站類型 | 建議版本 | 理由 |
|---|---|---|
| 個人部落格、小型品牌站 | non-www | 網址短、好記，無多子網域需求 |
| 企業形象官網（單一站點） | non-www | 品牌呈現簡潔，技術負擔低 |
| 多子網域站點（部落格＋商城＋論壇） | www | Cookie 隔離乾淨，不外溢子網域 |
| 使用 CDN 或雲端主機的大型站 | www | DNS 與 CDN 相容性高，設定省事 |
| 已有排名的既有網站 | 維持現狀 | 除非必要否則不換，避免短期波動 |
二維決策矩陣：用規模與子網域複雜度挑版本
上面的決策表給的是單一條件下的建議，但現實裡網站同時有多個特徵，很難只看一個維度。底下這個二維矩陣把「網站規模」與「子網域複雜度」兩個最關鍵的因素交叉，幫你在兩個維度同時拉扯時找到落點。橫軸是子網域數量，縱軸是網站規模，格子裡標出建議的版本與一句決策理由。
| 規模 ＼ 子網域 | 單一站點（無子網域） | 2 到 3 個子網域 | 4 個以上子網域 |
|---|---|---|---|
| 小型（數十頁） | non-www，簡潔優先 | non-www，Cookie 影響尚小 | www，Cookie 隔離開始有感 |
| 中型（數百至數千頁） | non-www，品牌呈現吃重 | www 或 non-www 皆可 | www，Cookie 與 CDN 雙重考量 |
| 大型（數萬頁以上） | www，預留擴充與 CDN 彈性 | www，相容性與隔離雙贏 | www，多子網域＋大規模必選 |
這個矩陣呈現的趨勢是：只要子網域數量往上拉、網站規模往上拉，www 的優勢就會同步放大。落點在右上角的站點幾乎沒有懸念，www 在 Cookie 隔離、CDN 相容性、爬取預算管理上都佔盡便宜；落點在左下角的小型單一站點，non-www 的簡潔就顯得更值得。真正會讓人猶豫的是中間地帶，這時可以再加一個判斷條件：你有沒有打算在未來一年內擴充子網域或上 CDN？有，就往 www 傾斜；沒有，non-www 完全夠用。版本可以一次選對，省掉日後切換的風險。
選擇本身不影響排名，影響排名的是你有沒有把兩個版本收斂成一個。新站選 non-www 讓網址更短更好記，是多數人的自然選擇，也沒有問題；但若你預期網站會長到多個子網域、需要 CDN 或嚴格的 Cookie 控制，www 在技術管理上反而更省事。決定後第一件事，是把偏好網域與 301 設好，這才是所有站長都會踩、也都該優先處理的重複內容地雷。如果 排名還是沒起色，問題多半出在 網址優化或 SEO 基礎沒到位，與 www 這三個字無關。
說實在的，與其在 www 這三個字上糾結一個下午，不如把那個時間拿去檢查你的網站有沒有兩個版本同時被索引。前者是美學問題，後者是會吃掉你排名的技術債。一個剛架好的網站，把網站結構、SERP 排名機制、偏好網域收斂一次到位，後面遇到排名或收錄異常時才不會亂了手腳。如果是剛起步，新手架站教學與 30 分鐘架站能幫你把地基打穩，架站成本也可以先抓個底。
常見問題：www 換 non-www 會掉排名嗎、GA 怎麼設定
www 換 non-www 本身不會直接掉排名，但若沒做好 301 與偏好網域設定，短期可能因權重未正確傳遞而波動；GA 則要在資源設定中確認追蹤的網域版本，並透過 301 收斂流量，才能讓資料正確彙整。
www 換 non-www 會掉排名嗎？
換版本本身不會扣分，301 永久轉址能把舊網址累積的排名訊號逐步搬到新版本，根據 Google Search Central 的說明，301 會把舊網址累積的大部分權重傳遞到新網址。真正會掉排名的，是漏掉 301、canonical 指錯、或 sitemap 沒重送，讓搜尋引擎一時分不清哪個才是主要版本。備份、設轉址、重送 sitemap、盯著收錄變化這幾步做齊，波動通常很短；至於 EEAT 與內容品質，跟網址有沒有 www 無關。這套搬移流程本質上與網站搬家、改版時的 SEO 處理同源，處理越嚴謹波動越短。沒有設偏好網域，GA 資料會怎樣？
流量、跳出率、轉換會被拆到 www 與 non-www 兩個版本分開計算，整體表現看起來比實際差。根據 Google Analytics 對獨立網域的計算方式，不同網域版本的資料預設不會合併。根本解法是收斂偏好網域，讓兩個版本的流量都導向同一個網址，資料自然彙整。設定 GA 時也要確認追蹤的網域版本與偏好網域一致，必要時加上 結構化資料核對。canonical 標籤和 301 轉址哪個比較好？
能設 301 就優先設 301。它連使用者的流量一起導過去，canonical 只處理搜尋引擎看到的首選版本，沒辦法解決訪客與反向連結被分到兩個網址的問題。把 301 當主力、canonical 當補漏的備案，會比較穩。兩者的完整差異可以參考轉址類型的比較。
WordPress 怎麼檢查目前用 www 還是 non-www？
後台「設定」的「一般」頁面，看「WordPress 位址（網址）」與「網站位址（網址）」兩欄。兩欄要完全相同，且與你設定的偏好網域一致。確認後再到主機端補 301，把另一個版本收掉。主機選擇可參考 SiteGround、Cloudways或 Namecheap的設定文件。Google Search Console 要怎麼設定偏好網域？
分別新增 www 與 non-www 兩個資源，在設定裡指定偏好版本，並提交對應版本的 sitemap。新版 Search Console 雖然簡化了偏好網域設定，但分開新增資源、確認收錄狀態仍是必要動作，能幫你及早發現兩個版本同時被索引的問題，熊貓演算法對重複內容的判斷也會因此更穩定。www 對 Cookie 與子網域有什麼好處？
www 是子網域，Cookie 預設只作用在 www 這一層，不會外溢到 blog.、shop. 等其他子網域。裸網域設的 Cookie 則會傳遞到所有子網域，拖慢載入也干擾 主機與頻寬成本相關的快取效率。對跑多個子網域的站，www 的 Cookie 隔離能提升整體效能。