提問：

1、不加www有哪些好處和壞處？

2、去掉www是否會影響網站的SEO（主要是排名和收錄）？（前提是過去有加www）

3、用什么方式去跳轉最好？（如301）

這個問題琢磨過很久，下面分享一下心得。

1、不加www有哪些好處和壞處？

不加 www 的裸域名好處主要是域名更加簡短、容易記憶。壞處就多了，講幾個主要的技術原因：

裸域名只能綁定 DNS 的 A 記錄，不能綁定 CNAME 記錄。也就是說你不能把裸域設定為另外域名的別名。很多時候這對管理不是很方便，特別是使用第三方托管服務的時候。如果第三方遷移服務器導致 IP 地址變更，你必須自己去更改 DNS 的 A 記錄。

比如你的個人博客采用 Tumblr 的服務，如果使用裸域，你需要手動將你域名的 A 地址指向 Tumblr 指定的 IP
地址。Tumblr 如果遷移了機房，所有通過這種方式設定個人域名的用戶都必須更改自己的 DNS 才能繼續使用，否則服務就會中斷。使用子域名的
CNAME 記錄就相對簡單很多，只需要將 www 子域名的 CNAME 字段指向 http://domains.tumblr.com
這個域名，之后如果 Tumblr 更改 IP 地址，他們只需要重新設置 http://domains.tumblr.com 這個域名的 A
記錄，而無需要求每個用戶去更改 DNS 記錄。

這個技術上的限制導致許多大型的第三方服務商不支持使用裸域。典型的如 Google 的服務，現在都不能使用裸域。Google
的服務用戶基數大，不得不采用 DNS 級別的分布式，使用到的 IP 地址太多，而且變動大。讓用戶綁定 A
記錄的話不利于負載均衡，維護起來也是幾乎不可能完成的任務。同理，大部分 CDN 也不支持裸域。

裸域的 cookie 的作用范圍太大。假如知乎也采用裸域，那么知乎所有 cookie 的作用范圍就包括 http://zhihu.com
下的所有子域名。也就是說訪問 http://foo.zhihu.com 和 http://bar.zhihu.com 的時候都會帶上
http://zhihu.com 裸域頁面設置的 cookie。從安全、隱私、可擴展性、以及管理的角度而言，這對很多大型網站來說是不可接受的。

URL 的正則匹配，如果帶 www 前綴的并且以 .com/.net/.org
結尾的，通常成功的機會要大很多。這個你會在許多文本編輯器里面遇到。如果 URL 不是 www
開頭，并且也不是三大頂級域名結尾的，匹配成功的概率就要小很多。這是使用過程中有時候會讓人很抓狂的點，重不重要全看你的用途和場合了。

2、去掉www是否會影響網站的SEO（主要是排名和收錄）？（前提是過去有加www）

早先裸域剛開始流行的時候確實有傳聞說不利于 SEO，但現在看來似乎并無任何問題。如果有的話也是搜索引擎的
bug，給他們提一下他們應該會很樂意去改。Google 的站長工具里面有工具可以幫助你做 URL
遷移的，可以有效的解決這個問題，再配合下一部分的跳轉，不用擔心對 SEO 有任何負面影響。

3、用什么方式去跳轉最好？（如301）

不管你決定使用還是不使用裸域，最好不要在同時保留 www 前綴和裸域的
URL，這樣既不方便用戶的瀏覽器區分訪問歷史，也會對你做訪問統計帶來不少麻煩。最佳的方式是采用 301 跳轉，并且跳轉的時候保留 URL
里域名后的全部內容。比如，如果你決定使用裸域 http://example.com，那么請務必將

http://www.example.com/foo/bar?spam=egg

301 跳轉到

http://example.com/foo/bar?spam=egg

去。或者反過來，如果你決定不使用裸域，那么請務必將

http://example.com/foo/bar?spam=egg

301 跳轉到

http://www.example.com/foo/bar?spam=egg

這樣的跳轉需要在 web 服務器里單獨配置，很多 DNS 管理界面提供的簡單的跳轉到新域名的根目錄無法實現這樣的功能（僅僅跳到 http://example.com/ )，對用戶體驗和搜索引擎 SEO 而言都是非常糟糕的。

下面給出如何在 nginx 里面實現上述的跳轉：

# redirect http(s)://www.example.com to http(s)://example.com

server {

server_name www.example.com;

return 301 $scheme://example.com$request_uri;

}

# redirect http(s)://example.com to http(s)://www.example.com

server {

server_name example.com;

return 301 $scheme://www.$host$request_uri;

}