www 還是 non-www？網址版本選擇與收合的完整判斷

快速重點：www 與 non-www 對 SEO 沒有先天高下，會出事的是兩個版本同時存活、訊號與數據被拆開而不自知。先做四項檢查分級，判讀 Google 挑代表網址的規則，用三個問題選邊，再按依賴順序施工、把報表收攏，網址這一題就能結案。

想像一個場景：兩個網址都打得開，數據卻對不起來

想像一個場景：你經營一個賣手工皮革件的小型電商，某天做月報時發現三件怪事。分析報表裡，同一個月的訪客被拆在兩個 hostname 底下；Search Console 的收錄清單，帶 www 與不帶 www 的網址同時出現；回頭查一則合作媒體的報導，對方連的又是另一個版本（示意）。三件事分開看都像小毛病，擺在一起，指向同一個結論：網站有兩個版本同時活著。

這不是罕見情境。www.example.com 與 example.com 在 DNS 裡是兩筆獨立紀錄、兩個不同的主機名稱，天生可以指向不同伺服器。兩邊並存、又沒有收合機制時，排名訊號與分析資料就會被拆開。前綴本身從來不是問題，未處理的並存才是。

會走到這一步，通常不是有人做了錯誤決定，而是沒有人做過決定。主機商把網站開好的那一刻，常見預設就是兩個主機名稱都會回應內容；站做起來、內容上線、連結慢慢累積，各種訊號各自落在當時剛好被使用的那個版本上。等報表對不起來才回頭看，中間已經隔了幾年的外部連結與索引歷史。這也解釋了開場的三個異常，為什麼會在同一份月報裡一起冒出來。

帶著這個狀況上網查資料，通常會撞到三個流傳很廣的答案。「www 只是裝飾前綴」這句話，把一個可以獨立指向伺服器的子網域，講成了網址上的化妝品；「選錯邊會被搜尋引擎扣分」假設 Google 在乎你的品味，它實際在乎的是各種訊號有沒有互相打架；「一線大站都拿掉 www，可見短網址比較強」把品牌的視覺選擇當成技術因果，人家的基礎建設條件跟你沒有關係。三個答案各自偷渡錯誤前提，把題目導向偏好之爭。

把題目換掉，事情會單純很多。該問的不是「www 好還是 non-www 好」，而是三個診斷問題：我的網站有沒有分裂、搜尋引擎目前把訊號算在哪一邊、要怎麼收合成一個版本。往下依序走六站：健檢、判讀、決策、施工、收攏、驗收，每一站都有可以當場照做的檢查，走完你手上也會有一份屬於自己網站的處置清單。

先補一個貫穿全文的技術事實。www 是一個子網域，跟 blog.、shop. 同級，不是網址的必要成分；這層結構的細節，可以從網域的層級與運作讀起。協定再乘上來，http 與 https、有 www 與沒有 www，一份內容可能有好幾個可存取位址，這正是健檢要逐一清點的對象。若網域、網址、子網域這幾個名稱還容易混淆，網域與網址的區分和網址結構的拆解兩篇可以先把它們定義清楚。

四個檢查先跑完，再決定要不要動

十分鐘可以做完全部。依序跑四項：兩個版本（連同 http 變體）的開啟與轉址行為、Search Console 的自選 canonical、憑證涵蓋範圍、依 hostname 拆看的流量報表。四項結果會把你分成健康、半分裂、全分裂三種狀態，直接決定後面要做多少工。檢查刻意由外而內：從使用者看得到的行為，一路查到搜尋引擎眼裡的版本、基礎建設的涵蓋範圍、分析資料的分布。

1. 版本行為測試。用無痕視窗分別打開四個位址：http 與 https，乘上 www 與 non-www。無痕的目的在排除快取與登入狀態的干擾，看到的就是陌生人看到的。正常：三個替代版本一站轉到首選版本，網址列停在首選網址。異常：兩個版本都停在原地顯示內容，或轉址多跳、繞圈。
2. 自選 canonical 檢查。在 Search Console 用網域資源把兩個版本涵蓋進來，挑幾個代表性頁面跑 URL 檢查，看 Google 選取的標準網址。正常：回報的就是你的首選版本。異常：回報的是另一邊。要留意，SERP 偶爾亮出另一個版本還不足以判定分裂，認定依據是 URL 檢查回報的 canonical，而不是結果頁上的偶發顯示。
3. 憑證涵蓋檢查。兩個 hostname 都實際連線一次，看連線是否乾淨、警告有沒有出現。正常：兩邊都先通過連線，再談轉址。異常：其中一邊先跳安全警告，代表憑證沒包到它。
4. 報表分流檢查。在分析工具用 hostname 維度拆看工作階段。正常：流量集中在單一 hostname。異常：兩個 hostname 都有穩定流量，表示使用者與爬蟲真的在用兩個入口。

把開場的皮革電商套進來判讀（示意）：版本行為測試發現 www 與 non-www 都回傳完整內容，誰也不轉誰；URL 檢查回報的標準網址，一頁是 www、一頁不是；報表裡兩個 hostname 幾乎各半。四項全中，這是全分裂，訊號與數據都在漏水，值得排一次完整施工。

「多跳」值得展開一下，因為它經常被當成「有轉就好」而放過。輸入 http://example.com，先被轉到 https://example.com，再被轉到 https://www.example.com，兩跳都是 301，看起來都有處理，但每多一跳就多一次往返，也多一個可以出錯的環節。健檢時要追的是終點落在哪個網址，不是看到轉址就打勾。

三種狀態對應三種工法。健康：替代版本一跳到達、自選 canonical 一致、報表集中，維持現狀即可，把力氣留給內容。半分裂：轉址存在，但 canonical、內部連結或報表仍冒出另一個版本，要做的是收訊號，不是重建。全分裂：兩個版本都活著、沒有任何收合機制，需要按依賴順序完整施工，順序在後面幾站展開。

檢查時有兩個小紀律，可以讓結果更可信。一是抽樣別只看首頁：首頁的行為常被快取與外掛特別照顧過，挑一兩篇內容頁、一個分類頁一起測，才看得出全站的一致性。二是把結果寫下來：四個位址各一行，記下回應狀態、落地網址與憑證結果。之後施工完成再跑一次，前後對照就是現成的驗收清單，不必憑印象判斷「好像有比較好」。

工具面不必多花錢，Search Console 本身就夠跑第二項檢查；還沒安裝的話，Search Console 的設定流程半小時能走完。要看懂後台各種報表，Search Console 的功能導覽值得先讀一遍。收錄狀態怎麼確認、搜尋結果裡出現的版本怎麼查，Google 收錄查詢的操作與Search Console 的實戰檢查技巧各有一套方法可以直接套用。

Google 是怎麼挑代表網址的？

兩邊內容一模一樣，不會被自動扣分。搜尋引擎處理這種情況的機制叫 canonicalization：同一份內容有多個網址時，Google 會依各種訊號的強弱，自行選出一個代表網址來計算與排序。你該做的只有一件事：讓每個訊號都指向同一個版本，降低它判斷的成本。

判讀健檢報告時，把 Google 想成一個一直在做選擇的系統。四個可存取網址都回相同內容時，它必須挑一個；轉址、canonical、內部連結、Sitemap 互相矛盾時，它仍然會挑，只是可能挑得跟你的期待不同。沒有「訊號自動折半」或「剩下四分之一」這種固定算法，任何把權重流失講成確定數字的說法，都拿不出依據。

訊號打架長什麼樣子？一個常見的組合：Sitemap 裡列的是 non-www，伺服器卻把訪客轉到 www，內部連結兩邊混用，外部連結又多半落在舊版本。Google 面對這種局面不會停擺，它會選一個，而且可能選你沒預期的那個。所謂「重複內容處罰」的傳說，多半是把這個選擇過程誤解成懲罰；實際發生的是合併與過濾，被合併的版本分不到自己的曝光紀錄，看起來像被扣分，機制上只是訊號集中到它選的代表網址。

訊號有強弱之分，Google Search Central 對重複網址整併的說明給過明確分層：永久轉址與 rel=canonical 屬於強烈的訊號，在 Sitemap 指定網址屬於較弱的訊號；各種訊號可以疊加使用，但 Google 保留自行選擇代表網址的最終決定權。這個分層比「該用 301 還是 canonical」的二選一問法更有用：兩者是並用關係，不是替代關係。替代版本沒有存在必要時，用永久轉址把它收掉；頁面仍要原地供人瀏覽時，才靠 canonical 表達索引偏好。

把話講白了：重複網址是一種技術債，不是違規之罪。內容品質與連結仍是排名主軸，收合的意義是把既有實力集中到同一個位址，而不是某種流量開關，按下去就會見效。想深挖，重複內容的處理原則講合併策略，canonical 的設定細節講訊號怎麼被讀取，內容面怎麼累積信任，可以再接著讀E-E-A-T 的建立方法。

三個問題問完，www 或 non-www 的答案會自己浮現

選邊不看感覺，看三個輸入：外部連結偏向哪一邊、品牌對外用哪個版本、基礎建設需要多少彈性。前兩題問的是既成事實，通常已經把答案寫好；第三題問的是未來空間。三題問完，產出不是一段心得，而是一個首選網址字串，後面每一站都對齊它。

第一問排在最前面，因為它最貴、也最難搬。反向連結是外部網站對你的投票，Backlinko 一項以 1,180 萬筆 Google 搜尋結果為樣本的排名因子研究回報，頁面排得越前面，背後的連結數量與來源廣度傾向越高。連結分別落在兩個版本時，等於同一份實力被記成兩份紀錄；收合能讓訊號集中，但沒有「六十條加四十條自動合成一百分」這種換算，也別指望合併後流量立刻翻倍。連結怎麼累積、怎麼評估好壞，反向連結的完整攻略有整份說明。

量測不用一步登高。Search Console 的連結報表就能看到主要連結來源與連結數量，網域資源又剛好涵蓋兩個版本，做初步的分布判斷已經夠用；要追更完整的 referring domains 分布與歷史變化，再考慮付費的連結分析工具。判讀時看的不是單一數字，而是傾向：絕大多數連結都落在同一邊，答案已經很清楚；真的勢均力敵，就把決定權交給品牌曝光那一題，別為了不存在的技術優勢硬翻盤。

新站與老站走不同分枝。新站沒有歷史包袱，任選一邊，立刻把收合機制設好，之後不必再糾結；這個階段真正值得花力氣的是網域本身，從網域的申請與挑選、Namecheap 的註冊實務到購買網域的完整流程，把地基一次打對。老站的順序相反：先量測 referring domains 的分布、確認索引現況，再決定值不值得動。優先序固定：連結分布大於品牌曝光一致性，品牌一致性大於純技術偏好。

www 多出來的彈性，其實只有三個地方

「www 比較有彈性」這句話流傳很廣，但很少被講出具體內容。攤開來只有三個可驗證的技術事實：根網域的 DNS 紀錄限制、Cookie 作用域的真實決定因素、子網域命名的維運邊界。三件事弄懂，決策第三問才有答案；拿掉 www 的短網址優勢屬於品牌呈現，已經在第三問處理過，這裡不另列優缺點清單。

根網域的 DNS 限制

DNS 的原始規範裡，根網域節點要承載 SOA 與 NS 這類紀錄，因此不能用 CNAME 直接指向另一個網域名稱，只能用 A 或 AAAA 紀錄指向 IP；www 是子網域，沒有這層包袱，接 CDN 或代管服務時常能直接用 CNAME。這個差異對流量小的網站無感，但換主機、上 CDN、做跨區分流時會浮上檯面：一條能直接指向服務商的紀錄，代表切換當天少一個環節可以出錯。

根網域的解析方式，實際取決於主機商與 DNS 業者的支援：example.com 可以用 A 或 AAAA 紀錄，也可以在支援的平台上使用根網域別名（CNAME flattening）這類方案；www.example.com 則常可直接用 CNAME，也可能依平台要求改用 A 或 AAAA。真正的重點有兩個：兩個主機名稱都要能解析到可處理請求的服務，並且要有涵蓋各自名稱的 TLS 憑證；任一條沒成立，替代網址連都連不上，後面的永久轉址自然讀不到。

Cookie 作用域由屬性決定

常有人說「www 會自動隔離 Cookie」，這個說法不成立。Cookie 的適用範圍由屬性決定，不是由主站有沒有 www 決定：未設定 Domain 屬性的 Cookie 屬於 host-only，只會送回原來設定它的那一台主機；明確寫了 Domain=example.com，同一份 Cookie 才會涵蓋根網域與旗下所有子網域。想把登入狀態限縮在單一主機、或讓靜態資源子網域不收到多餘 Cookie，靠的都是正確的屬性設定；www 頂多讓主站與各服務在命名上分得比較開，隔離效果不會自動發生。

這個機制對兩種情境影響最明顯。一是多服務共用網域的站：登入狀態一旦靠 Domain 屬性放大到整個根網域，旗下每個子網域都會帶著身分 Cookie 跑，範圍就要重新想過；二是靜態資源：資源請求夾帶不必要的 Cookie，等於每次下載都多帶一包行李，請求量大的站是實際成本。兩種情境的解法都在屬性設定，跟主站要不要掛 www 是兩件獨立的事。

子網域命名的維運邊界

主站掛在 www 之下時，app.、static.、shop. 這些服務的命名層級自然分開，維運權限與責任範圍好畫線：哪個團隊管哪個名稱、哪組憑證對應哪個服務、出事時該找誰，一眼就清楚。但要分清楚：這是組織結構，不是 SEO 邊界。子網域不會自動形成權重圍牆，主站與子站之間的內容要怎麼分配，屬於站內架構的取捨，子網域與子目錄的比較講得更細；DNS 指向怎麼設定，照DNS 網域指向的設定教學走一遍即可。

為什麼 DNS 沒通之前，301 形同虛設？

首選版本定案後，施工有依賴順序，不是偏好排列。順序是：先讓兩個版本都解析得到，再讓憑證涵蓋兩個主機名稱，之後 301 才有機會被瀏覽器讀到，然後才輪到 canonical、Sitemap、內部連結與追蹤的統一。順序錯了，輕則連不上，重則轉址繞圈。先看最容易被跳過的那一環。

憑證是整條鏈最容易被跳過的一環。憑證必須同時涵蓋 www 與 non-www 兩個主機名稱，因為替代的 HTTPS 網址要先完成有效的 TLS 連線，瀏覽器才讀得到後面的轉址指令。拆開看是三步：名稱解析先找到伺服器、TLS 憑證完成握手、HTTP 層才回得出 301。憑證少包一個主機名稱，使用者會先看到安全警告，永遠走不到轉址那一步。申請與續期時，直接翻開憑證的 hostname 清單，確認兩個版本都在，別只盯著首選版本。

1. 解析。www 與 non-www 各自要有紀錄可查。漏設替代版本的 A 或 CNAME，輸入那個網址的人會直接撞上「找不到伺服器」，轉址根本無從觸發；兩個方向都要實測，別假設設了一邊、另一邊自然會通。
2. 憑證。確認涵蓋範圍把兩個主機名稱都包進去，這一步沒過，後面全部卡住。
3. 轉址。用 301 或 308 逐頁一對一轉向首選版本；302 類屬於暫時訊號，不適合用在已經定案的版本選擇。工具選擇與常見陷阱，301 與 302 的轉址教學有整份說明。
4. 訊號統一。canonical、Sitemap、內部連結全數改用首選網址，與轉址軟硬並用。站內連結的清理有省力順序：先改選單、頁尾這類全站版面，一處改完等於幾百頁生效，再回頭清內文裡散落的舊連結。
5. 追蹤統一。標記、資源、報表都對齊首選 hostname，細節在下一站展開。

施工順序最常見的破壞者，是想一次做完的急躁。DNS 還沒生效就急著設轉址、憑證還沒涵蓋替代版本就宣布收工、301 上線了 canonical 還指著舊版本，每一種都會製造新的矛盾訊號，讓健檢結果更難判讀。照依賴順序走、每一步驗證過再前進，全程可能多花一兩個小時，省掉的是事後拆彈的整個下午。

轉址鏈的長度也值得計較。Statista 的長期統計顯示，全球網站流量來自行動裝置的比例已連續多年過半，行動網路環境下，每一跳的往返成本更容易被放大。嚴謹地說，沒有「每一跳固定扣幾分」這種保證，但目標很清楚：任何替代版本都應該一跳抵達首選網址，中間不留多餘的停留。假設訪客從 http://example.com 進站，理想路徑是一次就落到 https://www.example.com；如果實際先轉 https 再轉 www，第二跳就是多餘的停留，值得在施工時一併理直。

協定層的升級可以一併處理，HTTP 換 HTTPS 的完整攻略與SSL 憑證的挑選比較把兩件事講透，HTTPS 對 SEO 的影響則說明為什麼值得一次做對。

變更前的一個小動作能省很多事：先向 DNS 供應商確認可調的 TTL 下限，把快取時間暫時壓低，讓舊的解析結果早點過期，切換當天才乾淨；一切穩定後，再把 TTL 調回日常值，同時保留一份可回復的設定快照。

WordPress 的兩個位址欄位，各自管什麼？

WordPress 站在這一題特別容易出狀況，原因在結構：它把網址拆成兩個欄位，用途並不相同。WordPress Address（WordPress 位址）指向核心程式檔案的實際位置，Site Address（網站位址）是對外服務的網站網址；一般單站安裝兩者同值，核心放在子目錄時可以有不同路徑，不同值不等於設定錯誤。官方的搬遷指引同時提醒：更動前先完整備份，資料庫裡含序列化內容的資料要用適當的方式更新，不能只靠手改欄位。

為什麼要拆成兩個欄位？這個設計本來是給進階部署用的：把核心檔案放進子目錄、對外網址留在根路徑，訪客看到的網址乾淨，後台的程式位置也不必曝光。多數人一輩子用不到這個開關，兩個欄位永遠同值；但開關存在，就代表它被誤觸的機會也存在，這正是 WordPress 版本事故特別多的結構性原因。

事故的劇本幾乎都一樣：想把 non-www 換成 www，只改了其中一個欄位就按下儲存。結果要嘛前台轉址迴圈、頁面打不開，要嘛後台登不進去。復原不難，但路徑在後台之外：從組態檔定義網址、進資料庫把選項改回來，或直接用事前備份還原。這也是官方把備份放在提醒第一位的原因，出事時有備份與沒有備份，是兩種完全不同的處境。

「序列化內容」值得用白話講一遍。主題選項、外掛設定、選單配置這類資料，在資料庫裡常以帶長度標記的字串整包儲存；網址一換，字串內容變了、長度標記卻沒有跟著重算，資料就讀不回來了。這也是官方文件堅持「用適當的方式更新」的原因：搬遷工具會連長度一起算好，直接對資料庫做搜尋取代則容易踩到這個雷。看懂這一點，就知道哪些步驟不能省、哪些工具值得用。

有 staging 環境的站，先在預備站把換版本流程完整走一次，記下每個設定的位置與順序，再回正式站照表施工；沒有 staging，至少把兩個欄位目前的值原封不動抄下來，這份紀錄就是你的後路。

影響面不小。依W3Techs 的市占調查（2026 年 6 月），WordPress 驅動全球四成以上的網站，這個坑的影響基數龐大。用 SEO 外掛管理 canonical 的站還要多查一步：外掛輸出的 canonical 通常跟著網站位址設定走，欄位改完後，打開頁面原始碼確認輸出結果再收工，不要信任設定頁的描述。用搬遷外掛換網址的站也一樣：外掛宣稱會同步更新兩個欄位與資料庫內容，跑完仍要親眼核對欄位值、首頁行為與後台登入，三關都過才算完成。

與其事後救援，不如動手前把整條網址體系看一遍：永久連結的設定邏輯決定每一頁的長相，WordPress 架站的完整流程適合還在打底的人，架站費用的拆解則把預算與設定順序一起想清楚。位址欄位動對了，這些設定才不會互相拉扯。把兩個欄位的值、外掛設定與轉址規則放進同一份檢查表，之後任何網址相關的變動都照表跑一遍，事故自然離你遠一點。

把報表收攏到剩一個 hostname

施工完成後，數據要回到「一個網站」的樣貌。GA 這邊確認兩個版本都載入同一個標記、排除不必要的自我參照；GSC 這邊用網域資源看全貌，用 URL 檢查追蹤自選 canonical 的變化。舊網址在搜尋結果殘留一段時間，是正常的過渡現象，不要因此反覆改動設定。這一站做完，前一站的施工才算真正閉環，因為設定面的每個改動，最終都要在數據面被驗證。

判讀的框架很簡單：分裂時，同一份實力被記成兩份紀錄。在 GA4 用 hostname 維度拆看工作階段與轉換，兩邊都有量的那一天，報表就還沒收乾淨。掛同一個 Google tag ID 之下，資料仍可能被 hostname 拆開而失真，判讀前先確認集中；要檢查的是標記載入、跨網域設定與自我參照排除清單，這些步驟在Google Analytics 的完整教學與GA4 工作階段的解析都有逐項說明。追蹤設定是所有網站的共通功課，W3Techs 對 GA 市占的長期調查可以看出這套工具的普及程度。

自我參照多講一句：當一個 hostname 的流量被記成「來自另一個 hostname 的推薦連結」，來源報表就會被自己人污染，投放與內容決策跟著失真。統一之後，這種假推薦會自然消失，報表裡的來源才值得認真看。

Search Console 這邊有個歷史包袱要交代：偏好網域（preferred domain）設定已在 2019 年移除，現在沒有後台選項可以直接指定版本，只能靠網域資源加上一致的訊號表達偏好。網域資源的好處在涵蓋範圍：兩種協定、兩個版本、連同子網域，全部在同一份報表裡看，收合過程中舊網址與新網址的消長，就是用它追的。過渡期讀成效報表時，把舊網址與新網址當成兩列資料並列來看，一邊往下走、一邊往上接，訊號正在轉移的證據就在這兩條線的交叉處。

爬取預算則分級看待：多數中小型網站，版本分裂吃不掉多少抓取量，先把網址統一、清掉伺服器端的錯誤回應就夠；只有量級大、內容替換快、參數網址成堆的站，才值得進到爬取預算的優化那一層。

驗收、停損，與「不換也是一種決策」

收合怎樣算完成？看三件事就夠：

• 替代版本一跳到達首選網址，四個位址測下來沒有中繼站。
• URL 檢查回報的自選 canonical，與首選版本一致。
• 報表的 hostname 集中到剩一個，工作階段不再分家。

三項都過之後，剩下的是時間問題。訊號轉移的時程隨網站規模與抓取頻率而異，沒有人能給你固定週數；被轉走的舊網址會在搜尋結果裡慢慢淡出，這段期間最大的風險是手癢，反覆改設定只會打亂正在進行的轉移。一對一的轉址對應要守住，把舊網址全部倒回首頁是最常見的偷工，等於把每一頁辛苦建立起來的去處一次取消。

什麼時候根本不該換邊？外部連結沒有明顯偏向、品牌曝光兩邊混用、想換的理由只剩「看膩了」。三個條件同時成立時，換邊的風險通常大於收益，維持現狀、把並存收乾淨，就是正確決定。不換也是一種決策，而且常常是成本最低的那一種。

真要換，規格就直接拉到網站搬遷那一級：動工前把每個舊網址的落點盤成清單，動工時逐項確認排名訊號由誰承接，完工後按環節驗收、留下書面紀錄，三道關卡缺一不可，完整的風險控制照網站搬家與改版的指南走。之後想把整體體質再拉一輪，技術 SEO 的完全指南顧地基、站內 SEO 的攻略顧頁面、常見 SEO 錯誤的盤點幫你抓漏；觀念要一次補齊，就讀SEO 從零開始的完整指南。

健檢不是做一次就永遠結案。換主機、改 CDN、接手別人管理的網站，都值得把四個檢查重跑一遍；接手的站尤其常見，前一手的版本選擇不會寫在任何文件裡，只能靠檢查還原。把首選版本寫進網站的基本資料文件，讓每個經手的人都知道答案，這一題才算真正關閉。

回到開場那份對不起來的報表。網址這一題的終點，不是選出比較漂亮的前綴，而是讓每個入口都通往同一個地方。做到這件事，四個檢查的答案會一起變綠，報表也會自己回到一份。