www vs non-www 怎么选:定一个主机名,然后让五个地方对上

www vs non-www 定的是「这个站的主机名是哪一个」,不是排名问题。没有任何 Google 文档说过哪种更好。有文档的是:两个独立的 robots.txt 作用域、Search Console 里两个资源,以及跳转说清之前它们是一组重复网址。含决策表、四行自检和六行一致性表。

抓取与收录7 分钟读完2930 次阅读
www vs non-www 怎么选:定一个主机名,然后让五个地方对上

www vs non-www 要解决的是「这个站的主机名到底是哪一个」,定一次,然后在五个地方把它钉死。没有任何 Google 文档说过哪一种排名更好,别人也拿不出数据。有文档的部分更窄也更有用:这两个主机名是两个独立的 robots.txt 作用域、Search Console 里两个不同的资源,而且在你用跳转说清楚之前,它们是一组重复网址。

读这篇前你要有什么

能改 DNS,能在主机或 CDN 上配跳转。这一章只管「一个站选一个主机名」。旁边那个决策——某个内容板块该放子域还是放子目录——是另一回事,在 subdomain vs subfolder 怎么选 里。已经跳通了、只想核一遍的,直接翻到交付物那一节。

两个都能打开,要不要管

出海站最常见的进入方式就是这一句。域名解析配完,带 www 和不带 www 两个地址都能打开首页,看起来挺好。要管,但不是因为排名。

爬虫解析的是主机名。它不知道 example.comwww.example.com 属于同一家公司,协议里也没有任何东西告诉它。三个有文档支撑的后果,只有第三个跟排名沾边。

第一个是 robots.txt,也是最锋利的一个。Google 写明「the rules listed in the robots.txt file apply only to the host, protocol, and port number where the robots.txt file is hosted」,并在自己的表格里给了这个例子:放在 https://www.example.com/robots.txt 的规则,对 https://www.example.com/ 有效,对 https://example.com/ 无效robots.txt specifications,Google Search Central,2026-09-07 访问)。规则挂在一个主机名上,另一个主机名就是没有规则。

Search Console 一直没数据,多半是这件事

这是中文出海圈里反复出现的一种报修:站跑了几个月,Search Console 里的曝光和点击一直很薄,怀疑站被降权了。先看一眼你验证的是哪个主机名。

URL 前缀资源「includes only URLs with the specified prefix, including the protocol (http/https)」,而网域资源「includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp)」(Search Console 资源类型,2026-09-07 访问)。验证的是 www 那个前缀资源,而真实流量落在不带 www 的地址上,报表当然是空的。这不是降权,是量错了对象。

第三个后果是规范化。Google 把 canonical 定义为「the URL of a page that Google chose as the most representative from a set of duplicate pages」,并列出了参与这个选择的东西:「whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations」(Canonicalization,2026-09-07 访问)。两个主机名端出同一批页面就是一组重复,你不表态,Google 也会自己挑一个。

选哪个主机名不是 SEO 决策。选完不去钉死它,才是。

www vs non-www 到底怎么选

选择本身风险很低,基本是运维层面的事。照这张表往下走,命中第一条就停。

你的处境选哪个为什么
已经在跳且跳通了保持不动改一次等于一场迁移,换不来任何有文档的好处
现有外链多指向某一个那一个已有流量少走一跳
服务商不支持裸域指向主机名www服务商约束,不是偏好
还有别的子域,想隔离 cookiewww让裸域不带站点 cookie
品牌写法一直不带 www不带 www和别人怎么打、怎么引一致
以上都不是都行没有任何有文档的排名差别

定之前先确认第三行。有些服务商不允许裸域像子域那样指向一个主机名,会给你一条它自家的别名记录顶替。去问清楚你用的那家支持什么,别照抄别人的配置。

动手做:在五个地方钉死它

五步。每一步当天就能验,第二步是真正承载信号的那一步。

  1. 把赢的那个写下来,带协议,写成完整的源——https://www.example.com 或者 https://example.com。完成标志:一个字符串,后面每一步都拿它对。
  2. 把输的那个用永久跳转指到赢的那个,并保留路径。不是只跳首页:输的那边的 /pricing 必须落到赢的那边的 /pricing。完成标志:首页和一个深层路径各请求一次,都跳到对应路径。
  3. 把每个页面的 rel="canonical" 改成用赢的那个主机名。完成标志:抓三个页面,canonical 里的主机名和第一步那个字符串一致。
  4. sitemap 本身和里面每一条网址都指向赢的那个。完成标志:sitemap 里搜不到输的那个主机名。
  5. 在 Search Console 里加上赢的那个。能用 DNS 验证就选网域资源,它一次盖住两个主机名。完成标志:这个资源能报出你选的那个主机名的数据。

内链虽然不单列一步,也得提一句。用输的那个主机名写成的绝对内链,会让每一个读者和每一个爬虫白走一次跳转。用相对链接,或者用赢的那个写绝对链接,都能躲开。

交付物:四行自检 + 六行一致性表

拿自己的域名跑一遍。它同时验两个方向的跳转,并把页面声明的 canonical 打出来——这一对事实决定了你那个选择有没有真的钉住。

# 把 example.com 换成你的域名
D=example.com

# 1. 两个主机名各自什么状态?期望一个 301、一个 200
curl -sI  "https://$D/"      | head -n 1
curl -sI  "https://www.$D/"  | head -n 1

# 2. 深层路径跳过去之后还是不是原来那条路径
curl -sI  "https://www.$D/pricing" | grep -i '^location:'

# 3. 页面自己声明的 canonical 是哪个主机名
curl -sL  "https://$D/" | grep -o '<link[^>]*rel="canonical"[^>]*>'

然后确认同一个主机名出现在下面六个地方。任何一行对不上就是整个 bug,没有部分得分,因为每一行是被不同的东西读的。

位置要确认什么谁在读
跳转输的那个永久跳转且保路径爬虫和读者
canonical每个页面都写赢的那个收录
sitemap每条网址都用赢的那个发现
robots.txt在赢的主机名上能取到抓取
内链相对,或绝对但用赢的那个读者和爬虫
GSC 资源覆盖赢的那个你自己

这六行里有两行比其他的重,Google 直接说了。跳转是「a strong signal that the target of the redirect should become canonical」,rel="canonical" 是「a strong signal that the specified URL should become canonical」,而写进 sitemap 只是「a weak signal」(Consolidate duplicate URLs,2026-09-07 访问)。同一页还补了一句「these methods can stack and thus become more effective when combined」——这正是六行都要做、而不是只做最重那一行的理由。

三种做错的方式

第一种是跳转把路径吃掉了。规则写成「输的那个主机名上所有请求一律跳到赢的那个的首页」,看起来是通的,因为你测的就是首页。于是过去发出去的每一条深链都落到首页,而不是它本来指名的那个页面。测一个深层路径,别只测根。

第二种是跳转链。输的主机名先跳到赢的那个的 HTTP,再跳到 HTTPS,一次请求变成三次。每一跳都是一次抓取。把主机名和协议在一跳里同时定死,然后去看整条跳转链,而不是只看最后那个状态码。

第三种是 canonical 和跳转对着干。跳转指向 www,标签里写的却是裸域,六行里最重的两行在互相拉扯。Google 明说「indicating a canonical preference is a hint, not a rule」——最后由它决定,而当你自己的信号互相矛盾时,它不一定按你以为的那样决定。

这一章到哪儿为止

三条边界,第一条最要紧,因为网上关于它的自信说法特别多。

  1. 没有任何 Google 文档说过哪一种主机名排名更好,我们也没做过能隔离这个变量的测试。这件事在线上站根本测不出来——你得有两个只差一个主机名的完全相同的站。谁给你报一个「带 www 更好」的结论,他引用不了任何东西。
  2. 本章只管主机名,不管协议。同时提供 HTTP 和 HTTPS 会在下一层制造同样的重复,而 Google 把协议也列进了规范化因素。HTTPS 还没强制的,先去修那个。
  3. 合并不等于合并历史。输的那个主机名上已收录的页面要慢慢重新处理,看它进展的是另一份报表、另一件事。

动手之前还有一件事值得确认:爬虫到底够不够得着赢的那个主机名。跳到一个被防火墙或 CDN 规则挡住的主机名,比你一开始的重复更糟,这一步用 AI 爬虫检测。主机名定下来之后,同一个问题的单网址版本——一个页面的好几个地址该留哪个——在 canonical 标签留哪个网址。第五步要建的那个资源,怎么建在 Search Console 验证怎么选

常见问题

www 和不带 www 哪个对 SEO 更好

就已公开的 Google 文档而言,都不更好。有文档的差别是作用域:两个独立的 robots.txt 作用域、两个独立的 URL 前缀资源,以及在跳转把它们合并之前是一组重复网址。按运维条件选,选完钉死。

www 和不带 www 算两个网站吗

对 robots.txt 来说是,而且是明说的——规则只对文件所在的那个主机名有效,Google 自己的例子就把 www 上的 robots.txt 标成对裸域无效。对 Search Console 的 URL 前缀资源来说也是。对收录来说,它们是一组重复,Google 会合并到一个 canonical 上;你不说,它自己挑。

出海站买完域名要不要马上配跳转

要,而且这是成本最低的时候。站上还没有外链、没有收录、sitemap 还是空的,改一遍只要动一处配置。等到几百个页面收录之后再改,就是一场迁移了。

从 www 换到不带 www 会掉排名吗

我们给不出数字,别人也给不出——需要一个在线上站做不出来的对照实验。能说的是:换主机名是一场有实打实工作量的迁移,而且没有任何有文档的好处。所以只要某一个方向已经跳通了,保守的答案就是别动。

Search Console 里两个主机名都要加吗

用网域资源就不用,按 Google 的定义它包含所有子域和多种协议。用 URL 前缀资源的话,每个主机名加协议都要单独建一个,因为这种资源只包含带那个确切前缀的网址。

本文属于 QueryWin 实操手册 · 第 2 阶

www vs non-www 怎么选:定一个主机名,然后让五个地方对上