網址加不加 www，差別到底在哪裡？
輸入 www.example.com 能打開網站，輸入 example.com 往往也一樣能進首頁。但對負責維運網站的人來說，事情沒有這麼簡單——www.example.com 與 example.com 在 DNS 架構上其實是兩台不同的「主機名稱」（hostname）。
要不要用 www，牽涉的不只是網址好不好看，還包括 DNS 記錄怎麼設、SSL 憑證要涵蓋哪些網域、Cookie 的作用範圍、CDN 能不能正常接入，以及搜尋引擎如何判斷哪一個才是「正規網址」。真正要回答的問題，從來不是「www 比較好還是裸網域比較好」，而是：網站要選定哪一個當主要網址，其餘版本又該如何妥善導流。
www 是什麼？為什麼有些網站沒有它？
以 https://www.example.com/products 為例，www 其實是網域底下的一個子網域（subdomain），性質和 blog.example.com、shop.example.com、api.example.com 完全一樣。早期 www 常被用來標示「這台主機是提供網頁服務的」，但隨著網站架構演進，它早已不是架站的必要條件。
www.example.com 和 example.com 都可以是網站的主要網址。後者一般稱為裸網域（naked domain），在 DNS 技術文件中也常見 apex domain 或 zone apex 的說法。換句話說，www 不是「有網站就一定要加」的固定格式，而是一種架構上的選擇。
兩者真正的差異：在 DNS，不在外觀
單看網址本身，www 和裸網域幾乎沒有分別；真正需要留意的，是它們在 DNS 設定上的限制不同。
www.example.com 作為子網域，可以直接建立 CNAME 記錄，指向其他服務：
www.example.com → CNAME → cdn.example-provider.com
這種做法在接 CDN、雲端平台或其他第三方服務時相當常見。
裸網域則比較特殊。傳統 DNS 規範不允許 CNAME 與同名稱的其他記錄共存，而 zone apex 本身又必須存在 SOA、NS 等區域記錄，所以傳統 CNAME 無法直接掛在 apex 上。這也是為什麼不少 CDN 或雲端服務的設定教學會建議使用 www.example.com，而不是直接把 example.com 設成 CNAME。
不過這不代表裸網域無法搭配 CDN。現在許多 DNS 服務商已提供 CNAME flattening、ALIAS 或 ANAME 等機制，讓 apex domain 也能達到類似 CNAME 的效果——例如 Cloudflare 的 CNAME flattening，就能讓 zone apex 解析到其他網域對應的 IP。
如果打算讓裸網域接入 CDN、負載平衡或其他第三方平台，關鍵是先確認目前使用的 DNS 服務商是否支援對應的 apex domain 設定，而不是預設裸網域「做不到」。
www 會影響網站速度嗎？
網路上常見「www 比較適合 CDN」或「裸網域比較快」之類的說法，但實際上 www 本身並不會直接決定速度。真正影響網站快慢的，是 CDN 節點距離、快取命中率、DNS 回應時間、伺服器效能、資源大小與網路環境等一連串因素。
www 與裸網域比較容易牽動效能的地方，其實是 Cookie 的作用範圍。如果 Cookie 被設在較高層級的 example.com，符合條件的所有子網域請求都可能一併帶上這些 Cookie。舉例來說，若網站把圖片、CSS、JavaScript 放在 static.example.com，就得注意 Cookie 是否被不必要地夾帶到這些靜態資源請求裡，徒增流量與延遲。
也因此，不少網站會把靜態資源獨立到專屬子網域，並刻意控制 Cookie 的作用範圍——這是效能優化時常見的做法。結論是：不是用了 www 網站就一定比較快，關鍵在於整體架構與 Cookie 設定是否合理。
www 會影響 SEO 嗎？
這大概是最多人在意的問題。答案是：單純用 www 或裸網域，本身並不會讓網站獲得更好的排名。
Google 會把不同的 URL 視為不同網址，因此網站需要透過 redirect、canonical、sitemap 與內部連結，讓搜尋引擎清楚知道哪一個網址才是主要版本——這個過程 Google 稱為 URL canonicalization（網址正規化）。
假設網站決定以 https://www.example.com 作為主要網址，那麼以下版本都應該統一導向這個主要網址：
http://example.comhttps://example.comhttp://www.example.com
這麼做的重點不是「www 對 SEO 比較好」，而是避免同一個網站同時存在多個可被索引的版本，讓搜尋引擎自己去猜哪個才是正版。
為什麼「兩個網址都能開」反而是問題？
如果 https://example.com 和 https://www.example.com 都能打開一模一樣的首頁，對使用者來說似乎是好事——不管輸入哪個都能瀏覽。但對搜尋引擎而言，這是兩個不同的 URL。若網站沒有明確的正規化策略，搜尋引擎就得根據各種訊號自行判斷主要版本，判斷結果不一定符合網站的期待。
正確做法是選定一個主要網址，其餘版本一律用永久轉址導向它：
https://example.com → 301 → https://www.example.com
如此一來，不論使用者輸入哪個版本，最終都會收斂到同一個網址。
301 轉址與 canonical，差在哪？
這兩個名詞經常一起出現，但作用不同。
301（永久轉址）是實際把使用者與爬蟲都導向另一個網址：
example.com → 301 → www.example.com
若某個網址已經永久搬到另一處，Google 建議直接使用 301 或其他永久轉址處理，這也有助於把原網址累積的訊號整合到新 URL 上。
canonical 則是在頁面原始碼中告訴搜尋引擎「這個頁面希望以哪個 URL 作為正規版本」：
<link rel="canonical" href="https://www.example.com/products/cdn">
簡單說，301 是實際轉址，canonical 是告訴搜尋引擎「正規版本是誰」的訊號。如果網站已經設好 www 與裸網域之間的轉址規則，也該同步檢查 canonical、sitemap 與內部連結是否指向同一個版本，三者不一致等於白做。
HTTPS 跟 www 是兩件事，但要一起處理
很多網站討論 www 時，會連帶碰到 HTTPS 的問題。實際上一個網站可能同時存在四個版本：
http://example.comhttps://example.comhttp://www.example.comhttps://www.example.com
這其實是兩個獨立的決策：要不要用 HTTPS，以及要不要用 www。www 是子網域，HTTPS 是通訊協定，兩者可以自由組合。網站正式上線時，通常會一起規劃：選定 https://www.example.com 為主要網址後，其餘三個版本就統一轉址過去，一次完成 HTTPS 強制轉址與 www 正規化。
SSL 憑證別只顧著 www
網址正規化裡容易被忽略的一環是 SSL 憑證。假設主要網址是 https://www.example.com，但使用者仍輸入 https://example.com——如果憑證沒有涵蓋 example.com，瀏覽器在建立 HTTPS 連線時就會直接跳出憑證錯誤，而網站原本設好的 301 轉址根本還沒機會執行，因為 TLS 憑證驗證發生在 HTTP 請求之前。
因此，若網站需要同時接受 www 與裸網域的 HTTPS 請求，憑證必須同時涵蓋：
example.comwww.example.com
另外要注意，萬用字元憑證 *.example.com 通常不包含裸網域本身，別誤以為裝了萬用字元憑證就萬無一失。
到底該選 www 還是裸網域？
如果網站架構偏複雜，需要接 CDN、負載平衡、第三方服務，或未來預計擴充 api、blog、shop 等多個子網域，選 www 作為主要網址通常更容易理解與管理。
但如果網站希望網址簡短、品牌長期就是用裸網域，而且 DNS 與 CDN 架構都能完整支援 apex domain，裸網域一樣可以穩定運作。不需要糾結「SEO 比較喜歡哪一個」，真正該評估的是：
DNS 是否容易管理？
需要用到的第三方服務是否支援？
未來是否會增加子網域？
品牌網址是否已經固定下來？
團隊能不能維持一致的 URL 架構？
只要選定一個主要版本，並讓其他版本正確轉址過去，www 與裸網域都能成為穩定的網站架構。
最重要的原則，不要讓兩個版本各自運作
假設網站決定使用 https://www.example.com，理想狀態是所有非主要版本層層轉址、最終收斂到同一個網址並回傳 200：
http://example.com → 301 → https://example.com → 301 → http://www.example.com → 301 → https://www.example.com → 200
不必每個環境都照這個順序做，但最終結果一定要是「非主要版本 → 主要版本」，而不是讓 example.com 和 www.example.com 各自回傳 200、獨立運作。網站能打開不代表網址架構沒問題——DNS、SSL、301、canonical、sitemap、內部連結，都應該指向同一套網址策略，而不是各管各的。
上線前後可以逐項檢查
| 檢查項目 | 確認內容 |
|---|---|
| 主要網址 | 是否已明確選定 www 或裸網域 |
| HTTP | 是否統一導向 HTTPS |
| www／裸網域 | 非主要版本是否正確轉址 |
| DNS | A、AAAA、CNAME 等記錄是否符合架構 |
| SSL 憑證 | 是否涵蓋所有實際會用到的網域 |
| Canonical | 是否一致指向主要網址 |
| Sitemap | 是否只使用正規網址 |
| 內部連結 | 是否避免混用不同網址版本 |
| CDN | 是否能正常接收主要網域的請求 |
| Search Console | 是否持續觀察索引狀態與網址表現 |
這些項目看似分散，其實都在處理同一件事：讓網站、瀏覽器、CDN 與搜尋引擎，對「哪個網址才是主要網址」有一致的認知。
結論：www 不是 SEO 選擇題，而是架構選擇題
www 與裸網域最大的差異，不在於哪個比較好看，也不在於哪個比較容易被 Google 收錄。www 是子網域，裸網域是 zone apex，兩者在 DNS 設定方式上本來就不同，也可能牽動 CDN、第三方服務與整體網站架構的規劃。從 SEO 的角度看，真正重要的從來不是「選 www 還是裸網域」，而是選定之後能不能保持一致。
無論網站最終選擇 https://www.example.com 還是 https://example.com，只要其他版本都能正確導向主要網址，並同步處理好 HTTPS、canonical、sitemap 與內部連結，就能建立起清楚、一致的網址架構。
如果網站正在改版、導入 CDN、調整 DNS 或重新規劃網域，與其糾結「到底要不要加 www」，不如先確認一件更根本的事：現在的網址策略，是否每個環節都設定得一致——這才是 www 與裸網域議題裡，真正值得被認真對待的地方。
網址與 SEO 常見問題
延伸閱讀：
✔DNS是什麼？DNS運作流程、設定教學、攻擊手法全解析！
✔什麼網站需要CDN？網站使用CDN有什麼好處？｜Skycloud
✔為什麼網站速度這麼慢？網站速度慢怎麼辦？常見原因與解決方法｜Skycloud
✔DNS詐騙是什麼？原理與風險一次看懂｜Skycloud
'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_372_3728'%20x1='19.2966'%20y1='17.8555'%20x2='4.40396'%20y2='14.991'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2336BCD4'/%3e%3cstop%20offset='1'%20stop-color='%2362E0B9'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
親身體驗高速、安全的穩定服務
'/%3e%3cpath%20d='M38.0476%2033.4361C38.563%2033.9451%2039.3985%2033.9451%2039.914%2033.4361C40.4294%2032.927%2040.4294%2032.1018%2039.914%2031.5927L28.4218%2020.2421L16.9296%2031.5927C16.4141%2032.1018%2016.4141%2032.927%2016.9296%2033.4361C17.445%2033.9451%2018.2805%2033.9451%2018.7959%2033.4361L28.4218%2023.9289L38.0476%2033.4361Z'%20fill='%23222222'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_1305_5534'%20x1='53.5'%20y1='53.5'%20x2='-6.00852'%20y2='43.6145'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2336BCD4'/%3e%3cstop%20offset='1'%20stop-color='%2362E0B9'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)