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;
}
