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://www.mingpaixinxi.com 这个域名,之后如果 Tumblr 更改 IP 地址,他们只需要重新设置 http://www.mingpaixinxi.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://kuyihu.com,那么请务必将
http://www.kuyihu.com/foo/bar?spam=egg
301 跳转到
http://kuyihu.com/foo/bar?spam=egg
去。或者反过来,如果你决定不使用裸域,那么请务必将
http://kuyihu.com/foo/bar?spam=egg
301 跳转到
http://www.kuyihu.com/foo/bar?spam=egg
这样的跳转需要在 web 服务器里单独配置,很多 DNS 管理界面提供的简单的跳转到新域名的根目录无法实现这样的功能(仅仅跳到 http://kuyihu.com/ ),对用户体验和搜索引擎 SEO 而言都是非常糟糕的。
下面给出如何在 nginx 里面实现上述的跳转:
# redirect http(s)://www.kuyihu.com to http(s)://kuyihu.com
server {
server_name www.kuyihu.com;
return 301 $scheme://kuyihu.com$request_uri;
}
# redirect http(s)://kuyihu.com to http(s)://www.kuyihu.com
server {
server_name kuyihu.com;
return 301 $scheme://www.$host$request_uri;
}
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://www.mingpaixinxi.com 这个域名,之后如果 Tumblr 更改 IP 地址,他们只需要重新设置 http://www.mingpaixinxi.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://kuyihu.com,那么请务必将
http://www.kuyihu.com/foo/bar?spam=egg
301 跳转到
http://kuyihu.com/foo/bar?spam=egg
去。或者反过来,如果你决定不使用裸域,那么请务必将
http://kuyihu.com/foo/bar?spam=egg
301 跳转到
http://www.kuyihu.com/foo/bar?spam=egg
这样的跳转需要在 web 服务器里单独配置,很多 DNS 管理界面提供的简单的跳转到新域名的根目录无法实现这样的功能(仅仅跳到 http://kuyihu.com/ ),对用户体验和搜索引擎 SEO 而言都是非常糟糕的。
下面给出如何在 nginx 里面实现上述的跳转:
# redirect http(s)://www.kuyihu.com to http(s)://kuyihu.com
server {
server_name www.kuyihu.com;
return 301 $scheme://kuyihu.com$request_uri;
}
# redirect http(s)://kuyihu.com to http(s)://www.kuyihu.com
server {
server_name kuyihu.com;
return 301 $scheme://www.$host$request_uri;
}