www 與 non-www 網址差異：SEO 影響與設定

三秒鐘先講結論：兩個版本對 SEO 平起平坐，真正會出事的是「沒選邊」

「網址到底要用 www.example.com 還是 example.com？」兩者對使用者可能像同一個網站，技術上卻是不同主機名稱。若兩邊回傳相同內容又沒有一致轉址與 canonical，搜尋引擎就得自行選代表版本，站內與外部連結訊號也可能互相衝突。

所以這篇的核心答案，我直接擺在第一段。

對 Google 來說，www 跟 non-www 沒有誰天生比較強。會讓你受傷的從來不是「選錯邊」，而是「兩邊都活著、卻沒有告訴 Google 誰才是本尊」。選一個、然後把另一個徹底收進來，這才是這一題唯一該認真做的事。

下面我會把這件事的來龍去脈一次拆給你看：為什麼這兩個網址在技術上是兩個不同的東西、選邊的時候該用什麼標準判斷、決定之後要做的三件設定、還有那個最常被略過的反向連結與追蹤被劈成兩半的問題。如果你僅想快速對照，我先用一張表把幾個常見情境理清楚，細節再往下看。

先把概念掰直：www 不是裝飾品，它是一個子網域

很多人把 www 當成一個「看起來比較像網址的前綴裝飾」，跟網址前面那個小鎖頭一樣，純粹是視覺習慣。這個理解是錯的，而且這個誤解本身就是一切問題的源頭。

換個方式想。www 其實是一個子網域（subdomain），跟你後面可能會用的 blog.、shop.、app. 在結構上完全是同一類東西。www.example.com 跟 example.com，在 DNS 系統裡是兩個獨立的紀錄，可以指向完全不同的伺服器。技術上你甚至可以把 www 版連到 A 公司的主機、把 non-www 版連到 B 公司的主機，呈現兩個完全不同的網站。這不是假設，這是 DNS 原本就允許的設計。

那為什麼早期大家都用 www？說穿了，就是歷史路徑。一九八九那年 Tim Berners-Lee 在 CERN 提出 World Wide Web 的時候，把 www 當成提供網頁服務的那台機器的名字，跟提供檔案下載的 ftp.、收信的 mail. 區分開來。那個年代一台機器僅做一件事，用子網域命名服務類型是工程慣例。三十多年過去了，這個習慣留下來，但「它僅是一個子網域」的本質沒有變過。

對搜尋引擎而言，www 跟 non-www 是兩組不同的網址。兩邊若回傳相同內容，搜尋引擎通常會選出代表網址，但你仍應用一致的永久轉址與 canonical 清楚表達首選版本，避免訊號互相衝突。想知道網址結構還有哪些 SEO 隱憂，可以回頭看〈網址（URL）是什麼？〉跟〈如何區分網域與網址〉。

Google 眼中的真相：同一內容可能有四個可存取網址

講到這裡，我想帶你看一個很多人沒意識到的數學問題。一個網站其實不是「兩個版本」，而是「四個版本」。

假設你的網域是 example.com，那麼在沒有做任何設定的情況下，這四個網址對 Google 來說都是合法、都會被嘗試抓取的獨立位址：

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

協定（http 跟 https）乘上 www 與否，一份內容可能有四個可存取網址。這不代表 Google 必然建立四份索引，也沒有「訊號固定僅剩四分之一」的算法；問題在於搜尋引擎必須自行選代表網址，外部連結與站內訊號也可能分散或互相衝突。這裡先把焦點放在 www，協定則應一併統一到 https。

這是站內重複網址的典型成因，但不是一種自動套用的「重複內容處罰」。搜尋引擎會嘗試選出 canonical；若你的轉址、內鏈、Sitemap 與 canonical 說法不一致，選出的版本就可能不是你對外宣傳的網址。相關處理邏輯可參考〈SEO 重複內容指南〉。

這類問題不是站長做了什麼違規行為，而是沒有一致告訴搜尋引擎哪個網址才是代表版本。結果可能是 Google 自行選到不同版本，或讓報表、內鏈與分享網址變得零散，增加維護與判讀成本。

選哪一邊？別看排名，看這三個維度

既然兩邊對 SEO 沒有先天高下，那選擇的標準就應該從別的地方拿。我自己的判斷流程固定看三個維度，依序檢查。接下來這張表是網站健檢時常用的檢查清單，你也可以拿回去對著自己的網站走一遍。

這三個維度的優先級，我會這樣排：已存在的歷史連結大於品牌曝光，品牌曝光又大於單純的技術偏好。反向連結與既有網址要搬遷，需要完整轉址與監測；品牌素材則可逐步更新。老站應先查外部連結與索引版本，再決定是否值得為外觀偏好改網址。

反過來說，如果你是新站、還沒有任何歷史包袱，那恭喜你，這是最輕鬆的情況：挑一個你順眼的，立刻把合併機制設好，後面就不會再被這件事糾纏。把網域本身怎麼挑、怎麼註冊先弄懂的話，可以參考〈網域申請購買全攻略〉跟〈Namecheap 網域註冊完整教學〉、〈網域怎麼買？從挑選到設定的完整註冊指南〉，先把域名這層地基打好。

www 藏起來的紅利：DNS 彈性、Cookie 隔離、CDN 切換

這一節是我想特別多講的價值。多數講 www 的文章僅會告訴你「www 是歷史習慣，現在沒差」，但這其實僅說了一半。對某些類型的網站來說，www 這三個字母還真的在背後替你做了一些 non-www 做不到的事。這不是 SEO 排名層面的差距，而是基礎建設層面的彈性，而基礎建設的彈性最後會回頭影響你網站能長到多大。

DNS 的根網域限制

第一個差異藏在 DNS 紀錄裡。根網域（也就是 example.com 這個沒有前綴的位址）在傳統 DNS 規範下，僅能用 A 紀錄指向一組 IP 位址，不能用 CNAME 紀錄指向另一個網域名稱。這個限制來自 RFC 1034，原因是根網域同時要承擔 SOA 紀錄跟 NS 紀錄，不能再被 CNAME「霸佔」整個節點。

這件事的實際影響是：如果你想用 CDN 或把主機託管給某個雲端服務，對方通常會給你一個網域名稱要你用 CNAME 指過去。這時候如果你的主網域是 non-www，就僅能在根網域上靠「CNAME flattening」或 ALIAS 紀錄這類各家 DNS 商自己實作的功能來變通；但如果你用 www.example.com 當本尊，它是一個子網域，天生就能直接用 CNAME，零摩擦接上任何 CDN 或代管服務。DNS 設定背後的原理，可以看〈DNS 是什麼？網域名稱指向設定教學〉把基礎打穩。

說白了，流量小的時候這個差異你完全無感；但當你的站長大到要上 Cloudflare、要切換主機、要做跨區分流，www 那條 CNAME 能直接用的彈性，會讓你少掉很多半夜被叫起來改 DNS 的痛苦。

Cookie 的作用域

第二個差異是 Cookie 的作用域（cookie scope）。Cookie 若未設定 Domain 屬性，預設是 host-only，僅會送回設定它的主機，不會自動送到所有子網域；若明確設定 Domain=example.com，才會涵蓋根網域與子網域。因此隔離效果取決於 Cookie 屬性，而不是單看主站有沒有 www。

若登入 Cookie 被設定成涵蓋整個根網域，靜態資源子網域也可能收到不必要的 Cookie；使用 host-only Cookie 或獨立資源網域可降低這類傳輸。www 可以讓主站與其他子網域的命名更清楚，但仍要正確設定 Cookie 屬性，不能把隔離視為自動發生。

子網域與主站的乾淨邊界

當主站是 www.example.com，命名上可以清楚區分主站與 app.、static. 等服務，但這僅是維運結構，不會自動形成 SEO 隔離或權重邊界。子網域與子目錄的內容架構取捨，可參考〈子網域 vs 子目錄全解析〉。

把這三點合在一起看，你會發現 www 在 DNS、Cookie、子網域結構這三個基礎層面上，替你預留了一組 non-www 比較難給的擴充性。把它當成時代的化石，是低估了它。對一個打算長大、會用到多個子網域跟 CDN 的網站來說，這組紅利是真實存在的。

non-www 的反擊：短、俐落、當代品牌都在用

講完 www 的好處，我也得替 non-www 說句公道話，不然就不公平了。

把 www 拿掉、直接用根網域當主網址，是常見的品牌選擇。brand.com 字元較少，印在名片、廣告或介面上較精簡；這是視覺與傳播偏好，不是 SEO 優勢。

從行銷的角度，non-www 的優勢是真實的：好記、好念、好排版。尤其當你的品牌名稱本身已經夠長，再前面加一個 www 僅會讓網址列看起來像一串密碼。如果你的網站規模不會長到需要大量子網域跟 CDN 的等級，non-www 那種「少幾個字就是清爽」的體感，是值得納入考量的。

口頭說出網址時，brand.com 也比較短。不過現代瀏覽器與正確轉址通常能處理使用者是否輸入 www 的差異，因此這項選擇主要影響品牌呈現，不宜直接換算成流量增幅。

所以選哪一邊從來沒有標準答案，僅有「跟你的需求對得起來的答案」。品牌導向、視覺導向、輕量網站，non-www 完全合理；技術複雜、子網域多、要做基礎建設的站，www 的彈性會回報你。兩邊都不是錯的，錯的永遠是「兩邊都放著不管」。

選定之後：永久轉址、canonical 與一致的站內訊號

決定本尊後，核心工作是把替代版本永久轉向首選網址，並讓 canonical、內部連結與 Sitemap 保持一致。Google Search Console 已在 2019 年移除「偏好網域」設定，現在不能靠後台選項指定 www 或 non-www。

第一件是永久轉址。你在伺服器或主機層把非本尊版本逐頁用 301 或 308 轉向首選版本。302、303、307 屬於暫時轉址，搜尋引擎通常會保留來源網址；JavaScript 轉址也可能被處理，但速度與可靠性不如伺服器端轉址。完整細節可參考〈301 與 302 轉址完整教學〉。

第二件，canonical 標籤。你在每一頁的 <head> 裡，用 <link rel="canonical"> 指向這一頁的本尊網址。canonical 是一種「軟性合併」的訊號，告訴搜尋引擎「如果這個頁面有很多個網址版本，請統一把這個網址當成標準版本來計算排名」。它跟 301 的差別在於：301 是真的把使用者跟搜尋引擎都送去另一個網址，使用者看得到網址列跳轉；canonical 則是頁面還在原地、僅在原始碼裡宣告標準版本，使用者不會感覺到任何變化。這兩者一個是硬合併、一個是軟合併，搭配使用最穩。canonical 怎麼設、設錯會出什麼事，看〈Canonical URL 完全指南〉就夠了。

第三件是統一站內訊號：內部連結、Sitemap、結構化資料與分享網址都使用首選版本。Search Console 可以建立 Domain property，統一查看 http、https 與各子網域資料；URL Inspection 則可檢查 Google 選出的 canonical。操作可參考〈Google Search Console 完整教學〉與〈Google Search Console 安裝教學〉。

永久轉址與 rel=canonical 都是強烈的 canonical 訊號，Sitemap 則較弱；這些訊號可以疊加，但不是固定缺一不可的「三件套」。對已淘汰且不需保留的重複網址，永久轉址通常是最清楚的處理方式。

DNS 那一層先講好：根網域的 A 紀錄跟 www 的 CNAME

合併三件套是搜尋引擎那邊的事，但回頭看基礎建設，DNS 那一層你得先確保兩個版本都「指得到對的地方」。很多人做完 301 轉址卻發現 non-www 版本根本打不開，問題就出在 DNS 沒設好。

標準的設法是這樣：根網域 example.com 用一筆 A 紀錄指向你主機的 IP；www 子網域 www.example.com 則可以選擇用 A 紀錄或 CNAME 紀錄，指向同一個地方。兩個版本都要能解析、都要連得到你的主機，這樣 301 轉址才有意義。如果 non-www 的 A 紀錄沒設、僅有 www 有設，那麼當有人輸入 example.com，根本連不上你的主機，301 也就無從觸發，使用者僅會看到一個找不到伺服器的錯誤頁。

反過來也一樣。如果你選 non-www 當本尊，卻忘了設 www 的 CNAME 或 A 紀錄，那麼所有打 www.example.com 的人（而這通常是一批習慣加 www 的年長使用者或舊連結）會直接撞牆，連被 301 救回來的機會都沒有。DNS 是整件事的地基，地基沒打好，上面蓋什麼都會歪。這部分的原理跟實作，我會建議你直接配著〈DNS 是什麼？網域名稱指向設定教學〉操作一遍。

設完 DNS 之後，TTL（快取存活時間）會影響既有解析結果多久更新。重要更動前，可在 DNS 供應商允許的範圍內提前降低 TTL；各家最低值與實際傳播時間不同，切換前仍要保留回復方案，完成並穩定後再調回正常值。

WordPress 站最常自爆的地方：兩個位址欄位不同步

如果你是用 WordPress 架站，這一節請特別看仔細，因為 WordPress 站在 www 這一題上踩雷的頻率，可能是所有平台裡最高的。WordPress 全網大約驅動了四成以上的網站（依 W3Techs 的市場佔有率調查，2026 年 6 月），這也意味著這個坑影響的人非常多。

問題出在後台「設定」裡的「一般設定」頁面。那裡有兩個欄位，一個叫「WordPress 網址（URL）」，一個叫「網站位址（URL）」。這兩個欄位的網址，www 與否必須完全一致。一個設 https://example.com、另一個設 https://www.example.com，是 WordPress 站最經典的自爆方式，輕則出現太多重新導向的迴圈、網站打不開，重則後台進不去、要回去資料庫手動改 wp_options 那兩個欄位才能救回來。

這種狀況在實務裡反覆出現，清一色都是「本來是 non-www，聽了某個建議想改成 www，僅改了一個欄位就按下儲存」，然後整站就卡住了。正確的流程是：先決定好要哪一邊，把兩個欄位都設成同一個網址，儲存之後，再去處理 301 跟 canonical。順序不能顛倒。如果你對 WordPress 的網址結構跟永久連結還不熟，先把〈WordPress 永久連結設定教學〉看過一次，了解整個 URL 體系再動手會安全很多。

若使用 SEO 外掛管理 canonical，它通常會參考 WordPress 的網站網址設定，但仍要在原始碼中確認輸出結果。〈WordPress 架站新手教學〉與〈WordPress 架站費用全面拆解〉則適合還在規劃階段、想先把基礎架構弄對的人。

反向連結與追蹤被劈成兩半：你看到的流量其實是打折的

到這裡，我想把鏡頭拉近，看一個這一題裡最容易被低估的損失：反向連結（backlink）的權重分散。這也是這一題裡、解釋完最容易讓人倒抽一口氣的地方。

反向連結一直是 Google 排名機制裡分量極重的訊號之一。Backlinko 分析一千一百八十萬筆 Google 搜尋結果的研究指出，排名首頁的網頁跟指向它的反向連結數量之間，存在明確的正相關，連結愈多、來源愈多樣，排名傾向愈好。換句話說，每一條外部連結都不是裝飾品，它是實實在在、會推動排名的資產。

如果 www 與 non-www 都能開啟同一篇文章，外部網站也可能分別連到兩個版本。Google 可能透過 canonicalization 合併訊號，但轉址、canonical、內鏈與 Sitemap 若互相矛盾，就會增加判斷成本。沒有「六十條加四十條便各剩半套權重」這種固定算法。

這就是為什麼我前面不斷強調「選一個、合併到底」是這一題的核心。反向連結的累積是一個漫長、昂貴、需要真實別人願意連你的過程，把它無端劈成兩半，等於自己把最珍貴的排名資產稀釋掉。想更完整理解反向連結的運作機制，可以看〈反向連結是什麼？SEO 外連建立完整攻略〉。

追蹤設定的盲點

網址不一致也會妨礙流量分析。以 Google Analytics 為例（其市占可見 W3Techs 的長期調查），若兩個版本都安裝同一個 Google tag ID，資料仍可送進同一個 GA4 資源；真正要檢查的是兩邊是否都正確載入標記，以及 hostname、跨網域與不必要的自我參照是否讓報表被拆開。

更麻煩的是，當你想分析「這篇文章帶來多少工作階段（session）」的時候，如果 GA 把 www 跟 non-www 當成兩個不同的來源，你的轉換率、跳出率、工作階段路徑全都會失真。一篇文章明明帶來了完整的影響力，卻因為被切成兩個 hostname 而看不出全貌。GA4 的工作階段跟資源設定怎麼抓才準，可以看〈Google Analytics 完整教學〉跟〈GA4 工作階段完整解析〉。

對大型、更新頻繁或參數網址很多的網站，重複主機版本也可能浪費抓取資源；一般中小型網站通常不必把爬取預算當成首要問題。優先修正網址一致性與伺服器錯誤，再視規模參考〈爬取預算優化〉。

行動優先時代，這件事比十年前更不能拖

你可能會想：這個 www 的問題，網路上十年前就在講了，現在還需要這麼認真嗎？我的答案是：需要的程度不但沒有降低，反而更高了。原因跟行動裝置有關。

Statista 的數據顯示，全球網站流量裡來自行動裝置的比例，近年長期維持在五成以上，行動優先（mobile-first）早已是 Google 索引你網站的實際方式。在這個前提下，任何會拖慢行動裝置載入體驗的技術債，都會被放大檢視。

網址不一致常伴隨重新導向鏈。每多一跳都要增加一次網路往返，行動網路較慢或不穩時尤其明顯。轉址延遲可能拖慢導覽，但不能直接說成 Core Web Vitals 對每一跳固定扣分；實務目標仍是讓所有替代版本一次抵達最終網址。

所以正確的做法不僅是合併 www 跟 non-www，還要確保合併是「一步到位」的。使用者不管從哪個版本進來，都應該在一次 301 之內就抵達最終的本尊網址，不要產生中間多餘的跳轉。把協定升級那層一起處理好，搭配〈HTTP 換 HTTPS 完整攻略〉跟〈SSL 憑證是什麼？免費與付費 SSL 比較〉，把 https 這層一次補齊，你的網址結構才會是乾淨、不重複跳轉的狀態。

SSL 憑證是另一個常跟 www 糾纏在一起的坑。憑證要涵蓋 www 跟 non-www 兩個版本，否則當非本尊版本被 301 轉出去之前，它得先完成 TLS 握手，沒有憑證就會跳出安全警告，使用者根本到不了你 301 要送他去的本尊版本。買憑證或申請 Let's Encrypt 免費憑證的時候，記得確認涵蓋範圍把兩個 hostname 都包進去。

範例拆解：把分裂的網址收回來

假設網站對外一律使用 non-www，但部分舊連結仍指向 www，而且兩邊都能回傳相同頁面。檢查時應分別開啟兩個版本，確認替代網址是否一次永久轉向首選網址，再用 URL Inspection 查看 Google 選出的 canonical。

處理方式是逐頁把 www 永久轉到對應的 non-www 網址，讓頁面的 self-canonical、內部連結與 Sitemap 都使用 non-www。這能減少互相衝突的網址訊號，但不保證特定排名或流量增幅。

我不會給你一個「合併之後流量翻倍」的浮誇數字，因為那不是我能誠實承諾的事。每一個網站的起點、外部連結分布、競爭強度都不一樣，合併帶來的改善幅度也會不一樣。我能告訴你的是：網址分裂是一種「你不知道自己正在流血」的損失，而把它收起來，是你能把過去累積的每一分實力都集中到同一個地方的第一步。如果你想知道怎麼用 GSC 檢查自己是不是也在不知不覺中分裂，〈Google 網頁收錄查詢教學〉跟〈Google Search Console 實戰教學〉會帶你實際走一遍檢查流程。

這類技術債會讓搜尋引擎與分析工具較難判讀代表網址。內容品質仍是核心，但轉址、canonical、Sitemap 與內鏈也要一致，才能把訊號清楚集中到同一個版本。相關內容品質觀念可延伸閱讀〈E-E-A-T SEO 指南〉。

已經上線想換邊？一份不讓流量崩盤的搬家清單

有些讀者看完前面，可能會興起一個念頭：「我現在是 www，想換成 non-www，能不能直接換？」能，但這本質上是一次小型的網站搬家，不能裸奔。我把該走的步驟整理成一份清單，照著做可以把風險壓到最低。

第一步，盤點目前的外部連結分布，評估換邊是否值得承擔短期波動。第二步，在新版本準備好 DNS、SSL 憑證與主機設定。第三步，逐頁設定永久轉址，維持一對一對應，不能全部倒回首頁。第四步，更新全站 canonical、內部連結、GA4 標記與 Sitemap，並建立 Search Console Domain property 監測。第五步，持續觀察索引與流量；完成時間會因網站規模、抓取頻率與訊號一致性而異，不宜預設固定週數。

這份清單的核心精神，跟一次正式的網站搬家其實是同一套邏輯：每一個網址都要有去處、每一份訊號都要有承接、每一個環節都要有人盯著驗證。完整的搬家風險管理，可以搭配〈SEO 網站搬家、網站改版完整指南〉一起看，那篇談的是更大規模的域名轉移，但背後「不讓流量無預警崩跌」的原則是完全相通的。

還有一件事要提醒：換邊之後，那些已經被你 301 轉走的舊網址，在搜尋結果裡不會立刻消失，它們會帶著舊網址顯示一陣子，然後慢慢被新網址取代。這段過渡期是正常的，不要看到舊網址還在就慌張地再去改動設定，反而會打亂 Google 正在進行的訊號轉移。耐心，是這一類技術調整裡最被低估的工具。

收尾行動清單：五步把兩個版本收成一個

收尾前，這裡是一份可以直接執行的五步行動清單。不管是新站或老站，都能用它檢查網址版本是否一致。

1. 先確認你現在的本尊是哪一邊。打開你的網站，分別輸入 www 版跟 non-www 版，看哪一個會被自動轉向、哪一個留在原地。停在原地的那個，就是你目前實際上的本尊。
2. 查 Google Search Console 的索引狀態。建立 Domain property，並用 URL Inspection 查看代表頁面的 Google-selected canonical。搜尋結果偶爾顯示替代版本，不能單獨當成網址分裂的鐵證。
3. 決定本尊並統一訊號。把非本尊版本逐頁永久轉向首選網址，並統一 canonical、內部連結與 Sitemap。
4. 檢查 DNS、SSL 憑證、GA 資源都涵蓋兩個版本。確保非本尊版本在被 301 之前能正常完成連線、憑證有效、追蹤不漏。憑證僅買單邊、GA 僅設一個 hostname，是最常見的兩個漏網之魚。
5. 持續觀察訊號轉移。在 GSC 看 canonical 與索引狀態，在 GA4 依 hostname 檢查流量是否集中。過渡期避免反覆改動設定。

這五步走完，你的網站就從「兩個互相搶資源的自己」變回「一個集中全部實力的自己」。SEO 裡有很多複雜的事，但這一題的本質其實很樸素：把分散的東西收攏，把說不清楚的事講清楚。

我常說，SEO 不是花錢，是存錢。你每修掉一個像這樣的隱形技術債，就是在替自己的網站存下一筆會在未來持續生利息的資產。這些基礎功不性感、不會上社群熱門，但它們決定了你的內容到底能不能被看見。如果你想從更大的視角檢視自己網站還有哪些技術層的漏洞，〈技術性 SEO 完全指南〉、〈站內 SEO 終極攻略〉、〈5 個 SEO 優化地雷〉這幾篇會幫你把檢查範圍拉得更完整，〈SEO 搜尋引擎優化：從零開始到排名首頁的實戰策略〉則適合想一次把整體觀念理清楚的人。

網址選邊沒有標準答案，重點是做出選擇並維持一致。打開網站分別測試兩個版本，再確認替代網址是否一次永久轉向首選網址，就能先排除最常見的設定問題。