名片上印的是 www 開頭的網址，客戶回到家卻少打了那 3 個字母，螢幕上跳出一行「找不到伺服器」。反過來也一樣，網站只設定了不加 www 的那一邊，凡是習慣在網域前補上那 3 個字母的訪客，一律吃到閉門羹。
這種事之所以發生，是因為加不加 www 的網址，在技術上其實是兩個不同的名稱。只要兩邊設定得不一致，輕則同一份內容被拆成兩個網址，重則其中一邊根本打不開；兩邊都能開、卻沒有統一，則會讓連結、搜尋結果與成效報表各算各的。
www 該不該留在網址裡，沒有標準答案，但「選哪一邊」與「怎麼把另一邊收攏過來」都有明確的做法可循。弄清楚兩個名稱各自的行為，才知道哪一條設定該先做、哪一處最容易出錯。
www 是什麼？
WWW 是 World Wide Web（全球資訊網）的縮寫。Mozilla 維護的網頁技術文件 MDN，在詞彙表裡把它定義成透過網際網路存取、彼此連結的公開網頁系統，也常簡稱 W3 或 the Web。Web 與網際網路（Internet）並不是同一件事，網際網路是底層的網路基礎設施，Web 只是架在它上面的眾多應用之一。1990 年，Tim Berners-Lee 在 CERN 物理研究室用自己的電腦做出第一個網頁伺服器、瀏覽器與網頁，隔年在 alt.hypertext 新聞群組公開宣布。順帶一提，日文網路用語裡的 www 是「笑」的意思，跟網址完全無關。
至於網址開頭的 www，指的其實是另一層東西。網域名稱由右往左讀，最右邊是 .com、.tw 這類頂級網域（TLD），往左是一到多個標籤（label）。在自己擁有的網域底下，可以建立各放不同內容的子網域，MDN 舉的例子是 mozilla.org 底下的 developer.mozilla.org 與 support.mozilla.org。www 就是這種標籤之一，也就是 example.com 底下的一個子網域。
常見的做法是拿它標示「這台是網頁伺服器」，就像用 ftp 開頭標示檔案伺服器、用 mail 開頭標示信件伺服器那樣。但這只是約定俗成的命名習慣，不是任何規定，網址不用 www 開頭，網站一樣能正常運作。
所以「網址裡的 www」與「全球資訊網」雖然是同一個縮寫，卻分屬兩個層次，一個是整套系統的名字，另一個只是網域底下的主機名稱。既然它只是主機名稱的一部分，加或不加，等於在兩個不同的名稱之間挑一個。
加 www 與不加 www 是兩個不同的主機名稱
對 DNS（網域名稱系統，負責把網址對應到伺服器的 IP 位址）、伺服器、瀏覽器與搜尋引擎來說，example.com 與 www.example.com 是兩個不同的主機名稱，各自有各自的 DNS 記錄與伺服器設定。MDN 的說法是，一個網域名稱在語意上代表一台伺服器。兩邊都打得開、內容也一模一樣，是網站設定出來的結果，不是天生如此；沒有設定的話，兩個名稱可能指向不同的伺服器，顯示不同的內容，甚至其中一個根本打不開。
MDN 對「要不要選一邊」的建議很明確，就是選一個當標準位置（canonical name）並一直沿用，所有絕對連結都指向它，用電子郵件或社群分享連結時也用同一個。兩邊都保留也可以，條件是清楚指定哪一個才是標準網址，讓另一個仍能運作並提供預期的網頁。指定的做法有兩種，一是 301 轉址，也就是伺服器回應瀏覽器「這個網址已經永久搬到別處」，並把訪客自動帶過去；二是在網頁原始碼放 rel="canonical" 標籤，告訴搜尋引擎哪一個網址才是正本。Google 的轉址說明文件也舉過同樣的情境：https://example.com/home、http://home.example.com 與 https://www.example.com 3 個網址都能連到首頁時，建議選一個偏好的網址，再用重新導向把其他網址的流量導過去。
換句話說，加不加 www 並不是對錯題，真正要處理的，是兩個名稱並存卻沒有統一的狀態。
www 與裸網域在 DNS、Cookie 與 CDN 的實質差異
「www 比較專業」「不加比較新潮」這類感覺性的說法，並不會改變網站實際的運作方式。真正會讓設定行為不同的，只有 DNS、Cookie（網站存在瀏覽器裡、用來記住登入狀態或購物車的小段資料）與 CDN（把網站內容放到各地節點、就近傳給訪客的內容傳遞網路）3 處。
只有一個網站、用 A 記錄（把網域直接對應到一組 IP 位址的 DNS 設定）指向一台主機的中小企業，多半感受不到這 3 處的差異。但只要接上 CDN 或託管平台，或是網域底下有多個子網域，就會實際遇上；事先知道這幾點，設定時才不會做到一半才發現行不通。
DNS 規範不允許在裸網域設定 CNAME
CNAME 記錄的作用是替一個名稱建立別名，讓它指向另一個名稱。網際網路技術規範 RFC 2181 第 10.1 節寫明，別名所在的名稱，除了 DNSSEC 使用的幾種記錄之外，不可以有其他任何資料。而網域最上層（zone apex，也就是不帶任何前綴的 example.com，俗稱裸網域）一定同時有 SOA 與 NS 記錄，也就是記載這個網域由哪些 DNS 伺服器管理的基本資料，這兩者與 CNAME 無法並存，所以最上層放不了 CNAME。www 是子網域，沒有這個問題。
這條限制實際影響到的，是許多要求用 CNAME 把網域指過去的託管服務。Vercel 的說明文件寫得很直接，DNS 規範禁止在 example.com 這類裸網域使用 CNAME，www.example.com 這類子網域則可以，所以才建議以 www 為主網址、再把裸網域導向它。如果你只是用 A 記錄指向固定的 IP，加不加 www 在 DNS 上就沒有任何差別。
現在也有 DNS 服務提供 CNAME flattening 這類做法。以 Cloudflare 的說明為例，它讓你能在網域最上層使用 CNAME 記錄，由 DNS 服務找出該 CNAME 最終指向的 IP，回應時給的是 IP 而不是 CNAME 記錄。所以這是「比較麻煩」，而不是「做不到」。要留意的是，Cloudflare 也提醒，若某個 CNAME 的目標被第三方服務拿來做網域驗證，對全部 CNAME 開啟 flattening 可能使驗證失敗，因為驗證方不會再看到 CNAME 記錄本身。
Cookie 的 Domain 屬性與子網域的共用範圍
Cookie 預設只會回傳給設定它的那一台主機。MDN 對 Set-Cookie 的 Domain 屬性的說明是，省略 Domain 時，Cookie 只回傳給送出它的主機（host-only cookie），不會提供給該主機的子網域；一旦設定了 Domain，Cookie 對該網域及其所有子網域都有效，子網域一律包含在內。Domain 的值必須是送出 Set-Cookie 的伺服器網域或它的上層網域，不能是 com、co.uk 這類公共尾碼。
放到 www 的選擇上，關鍵條件是「有沒有帶 Domain 屬性」。如果主站掛在裸網域、又設了 Domain=example.com 的 Cookie，同網域下的其他子網域，例如另一個團隊維護的論壇、第三方託管的子網域，也會收到這份 Cookie。把主站放在 www，並讓 Cookie 只設在 www.example.com，這份 Cookie 就只留在這個子網域裡。不過這並不表示裸網域一定會把 Cookie 送給所有子網域，沒帶 Domain 屬性時，Cookie 一樣只回傳給送出它的那一台主機。
只有一個網站的中小企業，幾乎不會遇到這個狀況。有會員系統、又把部分功能放在別的子網域的站，才需要把它列入考量，單一網站不必為了 Cookie 去決定要不要加 www。
CDN 與託管平台多半建議以 CNAME 指向
前兩點落到實際情境，最常見的就是 CDN 與託管平台，這類服務通常希望你以 CNAME 指向它們。Vercel 的說明文件解釋，使用 CNAME 而非 A 記錄，可以避免寫死特定的 IP，遇到 DDoS 攻擊（用大量流量灌爆網站的攻擊）或需要做效能最佳化時，服務商能快速調度流量。這類文件因此常建議把 www 當主網址、裸網域導向它。
不過這是建議，不是強制。同一份文件也說明，若選擇以裸網域為主網域，仍可使用 A 記錄，並透過 Anycast（同一個 IP 由多地節點就近回應的技術）取得可靠度與效能。如果你的 DNS 服務支援讓裸網域也指向 CNAME 的做法，兩種寫法就都接得上。另外，Cloudflare 的 Universal SSL 在完整設定下，憑證同時涵蓋根網域（example.com）與第一層子網域（如 www.example.com），兩邊的憑證通常一次就處理好。
SEO 在意的是網址統一而非 www 本身
很多人想問的是「加 www 會不會影響排名」。以 Google 的文件為準，標準網址的說明裡並沒有規定要用哪一邊，也沒有說沒指定就一定出問題。但兩個版本都開、又沒有統一，確實會帶來實務上的麻煩。
同一份內容有多個網址時，Google 會自行挑選標準版本
同一份內容出現在兩個以上的網址，Google 的文件稱為重複或相似的網頁，系統會自己挑一個標準網址（canonical）顯示在搜尋結果裡。前面提過的 3 個入口範例中，就包含了 www 版本。
想告訴 Google 偏好哪一個，有 3 種信號可用，強度不同，也可以疊加。重新導向是強烈的信號，rel="canonical" 連結註解同樣是強烈的信號，納入 sitemap（列出網站網址、提供給搜尋引擎參考的清單檔）則是微弱的信號。文件也直說，這些方法是鼓勵採用但並非必要，即使沒有指定偏好的標準網址，網站依然可能有不錯的表現，因為不指定時，Google 會客觀認定哪個版本最適合顯示給使用者。
不過文件同時列了 4 個值得明確指定的理由，包括指定要顯示在搜尋結果中的網址、整合相似或重複網頁的信號、簡化特定內容的追蹤指標，以及避免耗時檢索重複網頁。Google 提供給網站管理者查看收錄與搜尋成效的免費工具 Search Console，在網址檢查工具的說明裡也提到，Google 不保證一定選擇你宣告的標準網址，但會把它納入考量。
另外，不少舊教學會教你到 Search Console 設定「偏好網域」。Google 在 2019 年 6 月宣布移除這個設定，並且不再使用既有的偏好網域設定，改請網站以 rel="canonical" 標記或 HTTP 標頭、sitemap 與 301 重新導向來表達偏好，現在不必再去找那個選項。
兩個版本並存會分散連結訊號、檢索時間與報表
兩個版本並存，實務上會出現 3 件事。第一，外部連結有人連 www、有人連裸網域，訊號分散在兩邊，沒有整合到同一個網址。Google 文件說明，指定標準網址能協助搜尋引擎把個別網址的訊號（例如造訪連結）整合成偏好的單一網址。
第二，Googlebot（Google 用來抓取網頁的爬蟲程式）的檢索時間被分掉。文件的說法是，你會希望 Googlebot 在檢索網站時盡可能找出最多內容，最好把時間花在最新或有更新的網頁，而不是相同內容的重複版本。
第三，Google 自己挑的標準網址，可能不是你印在名片、廣告與社群頁面上的那一個，成效報表也會被分成兩邊，要看某一頁的整體表現就得自己加總。Google 文件舉的情境是，想讓使用者進入 https://www.example.com 底下的某個商品頁，而不是帶著追蹤參數的另一個網址，這就是指定標準網址的典型用途，換成 www 與裸網域的狀況，道理完全相同。
所以就 SEO 而言，www 本身不是變數，兩個版本沒有被收攏成一個，才是問題所在。
依站台條件選擇 www 或裸網域，上線後不輕易更換
讀到這裡，下一個問題自然是「那我該選哪一邊」。MDN 的說法是，選哪一個當標準位置由你決定，但選了就要一直用。實務上可以從站台的 3 個條件來判斷。
| 站台條件 | 傾向的寫法 | 原因 |
|---|---|---|
| DNS 服務或託管平台限定以 CNAME 指向 | 使用 www | 裸網域不能設 CNAME，www 可以，裸網域再導向 www |
| 網域下有多個子網域，需要隔離 Cookie | 使用 www | 帶 Domain 屬性的 Cookie 會送往所有子網域，主站放在 www 較容易收斂範圍 |
| 沒有上述限制 | 看品牌與排版偏好 | 不加 www 較短，加 www 較容易一眼看出是網址，屬於偏好問題 |
對設計師來說，還有一個很實際的考量：名片、型錄、包裝上要印的網址，少了 www. 這 4 個字元，排版會寬鬆不少；保留這幾個字元，則在沒有 https:// 前綴的印刷品上，一眼就能看出那是網址。兩種寫法在 Google 文件中都沒有被排除，文件給的是統一網址的做法，並沒有指定要選哪一邊。
新站的狀況單純，選一個沿用即可。已經上線的網站，原則上不要為了好看而改，因為改了就等於整站的網址換了一個名稱。Google 的網站遷移文件在談變更網址時提到，在相同網域內切換 www 與非 www，不需要使用 Search Console 的「網址變更」工具，但其餘該做的事一件也少不了：用 301 導向、更新 canonical 與 sitemap，並在 Search Console 驗證新舊兩個版本。遷移期間，網站排名可能出現短暫波動，文件說這是正常現象；轉址則建議盡可能保留，通常至少 1 年，從使用者的角度則建議長期保留。
把 www 與非 www 統一成同一個網址的設定順序
以下用「標準版本」稱呼你選定的那一邊，「非標準版本」稱呼另一邊，選 www 或選不加 www 的人都適用，範例網址一律用 example.com。統一網址是一串有先後的動作，前一步沒到位，後一步就建在不穩的地方。整串動作的共同依據是 Google 的轉址說明，多個網址都能到同一個頁面時，選一個標準網址，再用重新導向把其他網址導過去，並建議盡可能使用永久的伺服器端重新導向。
轉址之前，兩個名稱都要先在 DNS 解析得到主機
很多人以為轉址是主機設定的事，其實前一步在 DNS。要把非標準版本導向標準版本，得先有一台伺服器收到這個請求，才能回一個 301。所以非標準版本的名稱本身，也要在 DNS 裡指到某台伺服器或 CDN 的邊緣節點。
常見的做法是裸網域放 A（或 IPv6 用的 AAAA）記錄，www 放 CNAME，指到裸網域或服務商給的網址。兩個名稱都要有。只設了標準版本，另一個名稱一打就是「找不到伺服器」，請求根本到不了轉址那一步。
在 CDN 層做轉址時，也有同樣的要求。Cloudflare Pages 的說明文件示範了把 www 以 301 導向裸網域的做法：建立大量轉址規則之後，還必須到 DNS 為 www 子網域建立一筆被代理（Proxied）的記錄，文件用的是 A 記錄，IP 位址填 192.0.2.1 這個保留的佔位位址。文件也提醒，DNS 變更需要一點時間生效，改完別急著判斷失敗，之後再用 curl 檢查回應的 location 標頭與狀態碼是否如設定。
用單次 301 把非標準版本導向標準版本
這是統一的主軸。伺服器端的永久轉址（301，或同屬永久轉址、但會保留原本請求方法的 308）要把非標準版本的任何路徑，導向標準版本的同一個路徑，查詢參數也要一起帶過去。MDN 的流程示意是，伺服器收到 http://www.example.org/whaddup 的請求，而標準網域是 example.org，就回 301，並在 Location 標頭寫上 http://example.org/whaddup，瀏覽器再向標準網域重新發出請求。如果規則只寫到網域、沒有帶上路徑與參數，每個深層連結都會被丟到首頁。
為什麼要用 301，而不是暫時轉址的 302？Google 的說明指出，永久重新導向會在搜尋結果中顯示新的重新導向目標，暫時重新導向則顯示來源網頁。統一網址的目的，就是讓搜尋結果顯示標準版本，所以要用永久轉址。
Cloudflare 的範例規則可以當作具體樣貌：萬用字元比對 https://www.*，目標網址寫 https://${1}，狀態碼 301，並開啟保留查詢字串。這樣 https://www.example.com/products/ 會以 301 導向 https://example.com/products/，https://www.example.com/admin/?logged_out=true 也會連參數一起帶過去。它的邊界也寫得很清楚：這條規則只處理 HTTPS 的請求，http://www.example.com/?all_items=true 與 http://example.com/admin/ 都不在範圍內，要由另一條規則補上。這正是後面用 curl 實測時要把 4 種組合都測過的原因。
實作的位置有 3 種，包括主機的設定檔（Google 的說明文件列了 Apache 用 mod_alias 的 Redirect permanent 或 mod_rewrite、Nginx 用 return 301 的範例，其他伺服器請洽管理員或代管商）、DNS 或 CDN 的轉址規則、主機後台提供的設定。選一處負責就好。兩處同時轉址，只要兩邊的方向不一致，就會彼此衝突。
WordPress 站的網站網址，要與標準版本寫成同一邊
WordPress 站有一個特別之處：它自己也有一層轉址。後台「設定」→「一般」（英文介面為 Settings → General）有兩個網址欄位，WordPress 的說明文件指出，「網站位址 (網址)」（Site Address (URL)）是你希望人們在瀏覽器輸入以進入網站的位址，「WordPress 位址 (網址)」（WordPress Address (URL)）則是 WordPress 核心檔案所在的位址。兩者都應該包含 https://，結尾不要加斜線。如果在 wp-config.php 用 WP_HOME 與 WP_SITEURL 寫死了這兩個值，後台一般設定頁就無法再編輯它們，要切換成另一個版本之前，得先確認這一點。
接著是 WordPress 內建的 redirect_canonical()。開發者文件的說明是，它依網站網址把進來的連結導向正確的網址；因為搜尋引擎把 www.somedomain.com 與 somedomain.com 視為兩個不同的網址，這個功能可以藉由把所有進來的連結導向其中一邊，避免重複內容。原始碼裡有一行 // www.example.com vs. example.com 的註解，並且以 home_url() 的主機來覆寫要導向的主機。所以只要網址欄位寫成標準版本，WordPress 通常會自己把另一邊導過來。不過它不處理 feed、trackback、搜尋、後台網址、POST 請求與 robots.txt 這些例外。
這層轉址不能取代實測，更不能與伺服器或 CDN 的規則方向相反。已上線的站要改成另一邊時，資料庫裡寫死的舊網址也要一併替換，只改設定欄位不夠。WordPress 的文件提醒，直接對整個資料庫做字串取代，可能弄壞佈景主題與小工具存下的序列化資料，建議改用 WP-CLI 的 search-replace 這類工具處理，並提醒無論如何都不要改 GUID 欄位。另外，部分付費外掛的授權會綁定啟用時的網站網址，網址改了之後，記得確認授權狀態是否正常。
canonical、sitemap 與內部連結都指向標準網址
301 只是告訴搜尋引擎「請改走這邊」，網站自己輸出的每個訊號也要指向同一處，否則等於自相矛盾。要檢查的有 3 個地方：
- 每一頁的
rel="canonical"都指向標準版本的絕對網址，標準網頁本身也放自我參照的 canonical。Google 文件建議採用絕對路徑，相對路徑雖然也支援，長期下來卻可能造成問題，例如無意間讓測試網站受到檢索。 - sitemap 只放標準網址。Google 的最佳做法明講，不要為同一個網頁在 sitemap 指定一個網址，卻又用
rel="canonical"指定另一個。 - 內部連結直接連到標準網址，不靠轉址轉過去。文件說，一致地連結到你認定的標準網址，有助於 Google 瞭解你的偏好。
WordPress 與多數 SEO 外掛會依網站網址自動產生這些標記，仍建議抽查頁面原始碼與 sitemap，連同舊文章、側欄、頁尾裡寫死的完整網址一起檢查。廣告連結、電子報與社群頁面上的網站欄位，也在統一時一併更新。
統一之後，用 Search Console 網域資源涵蓋兩個版本
Search Console 有兩種資源類型。網域資源涵蓋所有子網域（m、www 等）與多種通訊協定（http、https），驗證要用 DNS 記錄（架在 Blogger、Google 協作平台這類 Google 產品上的網站除外）；網址前置字元資源則只包含具有指定前置字元的網址，連通訊協定也算在內。Google 的說明建議，希望資源涵蓋任何通訊協定或子網域時，可以改建網域資源。
統一之後，網域資源能一次看到兩個版本的整體數據；只用網址前置字元資源的話，加不加 www、http 與 https 共 4 種組合都得各驗證一次，才看得到完整資料。Google 的網站遷移文件也提醒，要驗證 www.example.com 與 example.com，有使用 HTTPS 的話，還要驗證 HTTPS 與 HTTP 兩種版本。之後觀察網頁索引（收錄）報表與 sitemap 報表，數量是否逐步移向標準網址、非標準網址是否慢慢退場，就是判斷轉址與標準網址訊號有沒有被採納的線索。
設定完成後，以 curl 實測 4 種網址組合都只跳 1 次
設完一定要實測，而且要測 4 種組合，也就是 http 與 https 各搭配 www 與非 www。只測瀏覽器最常輸入的那一種，通常是 https 加標準版本，會漏掉另外 3 種組合裡的漏洞，前面 Cloudflare 的範例規則就只管 HTTPS 的 www 請求。用命令列工具 curl 的 curl -I（只取回伺服器回應的標頭）查看每個網址的狀態碼與 Location 標頭，假設標準版本是 https://www.example.com：
curl -I http://example.com/
curl -I http://www.example.com/
curl -I https://example.com/
curl -I https://www.example.com/Code language: Bash (bash)預期的結果是：標準版本回 200，其他 3 種都以 1 次 301，直接指向標準版本的最終網址。macOS 與 Windows 10 以後的版本都內建 curl，但在 Windows PowerShell 5.1 裡，curl 是另一個指令的別名，要改輸入 curl.exe -I。要追蹤轉了幾跳、最終落在哪，改用 curl -IL。
判讀時有 3 個訊號。非標準版本回 200，代表根本沒有轉址，兩邊都能開，要回頭補上 301 轉址規則。出現多次 301 連續跳轉，是轉址鏈，要把規則合併成一條。Location 指向 http:// 開頭的網址，表示某一處把 https 又轉回了 http。
另外，瀏覽器會快取 301 這種永久轉址，用一般分頁測試，常常「看起來沒轉」或「看起來還是舊的」。測試請用無痕視窗或 curl。
統一網址時最常見的 4 種錯誤
統一網址出的問題，多半不是規則寫錯，而是兩處以上的設定各做各的。
兩個版本都打得開，卻沒有任何轉址
這是最普遍、也最不容易發現的一種，www 與裸網域各自打得開，網址列不變，內容一模一樣，所以經營者看不出任何問題。成因通常是 DNS 的兩個名稱都指到同一台主機，卻沒有任何一處設定 301。結果是 Google 會在兩個版本之間自己挑一個當標準網址，搜尋結果顯示的網址，可能並不是你印在名片上的那一個。
排查的方法很直接：把兩個版本各輸入一次，看網址列有沒有變。有 Search Console 的話，可以用網址檢查工具，對照「使用者宣告的標準網址」與「Google 所選的標準網址」是否一致；前者是網頁用 rel="canonical"、HTTP 標頭或 sitemap 等方式明確宣告的，後者則是 Google 在多個類似網頁中選為標準的網址，兩者可能不同。
修法是回頭補上 301 轉址，不要只靠 canonical。MDN 提到 301 與 canonical 都能指定標準網域，但 301 會把瀏覽器直接導向標準網址；canonical 的做法則是兩個網域都提供相同內容，瀏覽器歷史紀錄會把 www 與非 www 視為獨立的項目。
轉址鏈把 http、非 www 與 https 拆成好幾跳
典型的情況是，http://example.com 先被導向 https://example.com，再從 https 的非標準版本導向 https://www.example.com，兩條規則各跳 1 次，共 2 跳。Googlebot 追得到，Google 的網站遷移文件也說，它可以在轉址鏈中追蹤最多 10 個躍點，但建議直接重新導向至最終目的地；若無法，鏈中的轉址次數理想上不超過 3 次，且少於 5 次。連續轉址會增加使用者的等待時間，也並非所有使用者代理程式與瀏覽器都支援多次連續轉址。MDN 也指出，每次轉址都有額外一次 HTTP 請求的效能成本。
這種轉址鏈的成因，常是 HTTPS 與 www 的規則分別由不同人、在不同時間加上去。解法是把規則一次寫到最終網址，在同一條規則裡同時處理通訊協定與主機名稱，直接導向 https://www.example.com/ 加上原本的路徑。排查時用 curl -IL 數一下 Location 出現了幾次。至於 http 轉 https 本身、憑證申請與 HSTS（要求瀏覽器一律改走 HTTPS 的機制）這些設定，屬於另一個主題，這裡只談主機名稱的合併。
憑證只涵蓋其中一邊，另一邊在轉址前就先跳警告
HTTPS 的加密連線，要在 HTTP 的請求送出之前就先建立好。所以如果憑證只涵蓋標準版本，訪客輸入非標準版本時，瀏覽器會先跳出憑證不符的警告，後面那個 301 根本送不到。這就是「明明統一了 www，卻還是有人看到整頁警告」的原因。
Google 的標準網址文件提醒，要避免為錯誤的主機名稱版本採用憑證，例如用 example.com 的憑證去服務 subdomain.example.com；憑證必須與完整網站網址相符，或是單一網域中可供多個子網域使用的萬用憑證。文件也說，HTTPS 網頁使用無效憑證時，Google 傾向選擇 HTTP 作為標準網址。
一個常見的誤會，是以為萬用憑證 *.example.com 也涵蓋裸網域。RFC 6125 第 6.4.3 節的說明是，萬用字元出現在最左邊的標籤時，*.example.com 會比對 foo.example.com，但不比對 bar.foo.example.com 或 example.com。2023 年取代它的 RFC 9525 也維持同樣的原則，萬用字元只能比對一個標籤。所以憑證的名稱清單，要同時列出裸網域與 www。如果使用 Cloudflare 的 Universal SSL，完整設定下、且兩個名稱都經 Cloudflare 代理時，兩者預設都涵蓋，不必另外處理。
伺服器與 WordPress 轉址方向相反造成的迴圈
伺服器或 CDN 把 www 導向裸網域，WordPress 後台的網站網址卻還寫著 www，redirect_canonical() 又把裸網域導回 www，兩邊各導一次，瀏覽器就會顯示「重新導向次數過多」（ERR_TOO_MANY_REDIRECTS）。MDN 對轉址迴圈的說明是，它可能橫跨好幾台伺服器，每一台都沒有全貌，這時由瀏覽器偵測並顯示錯誤訊息。
成因是統一時只改了一處，另一處還是舊的。排查要看 3 個地方，包括 WordPress 的網站網址、伺服器設定檔、CDN 的轉址規則。修法是讓 3 處都指向同一個標準版本，並只留一處負責轉址。這和 CDN 加密模式與主機各自強制 HTTPS 所造成的迴圈不同，這裡的問題出在兩處對主機名稱的轉址方向相反。
www 留或不留，由主機環境、DNS 服務與品牌排版的偏好決定，兩邊都是正當的選擇。真正要守住的，是讓每一個入口最後都只通往同一個網址。做法是選好一邊，用 1 次 301 把另一邊收攏，再讓網站自己輸出的每個訊號都跟著對齊。設定完成之後，隔一段時間用 curl -I 看一眼 4 種組合，比任何報表都更快發現漏洞。