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

www vs non-www 要解决的是「这个站的主机名到底是哪一个」,定一次,然后在五个地方把它钉死。没有任何 Google 文档说过哪一种排名更好,别人也拿不出数据。有文档的部分更窄也更有用:这两个主机名是两个独立的 robots.txt 作用域、Search Console 里两个不同的资源,而且在你用跳转说清楚之前,它们是一组重复网址。
读这篇前你要有什么
能改 DNS,能在主机或 CDN 上配跳转。这一章只管「一个站选一个主机名」。旁边那个决策——某个内容板块该放子域还是放子目录——是另一回事,在 subdomain vs subfolder 怎么选 里。已经跳通了、只想核一遍的,直接翻到交付物那一节。
两个都能打开,要不要管
出海站最常见的进入方式就是这一句。域名解析配完,带 www 和不带 www 两个地址都能打开首页,看起来挺好。要管,但不是因为排名。
爬虫解析的是主机名。它不知道 example.com 和 www.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 | 服务商约束,不是偏好 |
| 还有别的子域,想隔离 cookie | www | 让裸域不带站点 cookie |
| 品牌写法一直不带 www | 不带 www | 和别人怎么打、怎么引一致 |
| 以上都不是 | 都行 | 没有任何有文档的排名差别 |
定之前先确认第三行。有些服务商不允许裸域像子域那样指向一个主机名,会给你一条它自家的别名记录顶替。去问清楚你用的那家支持什么,别照抄别人的配置。
动手做:在五个地方钉死它
五步。每一步当天就能验,第二步是真正承载信号的那一步。
- 把赢的那个写下来,带协议,写成完整的源——
https://www.example.com或者https://example.com。完成标志:一个字符串,后面每一步都拿它对。 - 把输的那个用永久跳转指到赢的那个,并保留路径。不是只跳首页:输的那边的
/pricing必须落到赢的那边的/pricing。完成标志:首页和一个深层路径各请求一次,都跳到对应路径。 - 把每个页面的
rel="canonical"改成用赢的那个主机名。完成标志:抓三个页面,canonical 里的主机名和第一步那个字符串一致。 - sitemap 本身和里面每一条网址都指向赢的那个。完成标志:sitemap 里搜不到输的那个主机名。
- 在 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」——最后由它决定,而当你自己的信号互相矛盾时,它不一定按你以为的那样决定。
这一章到哪儿为止
三条边界,第一条最要紧,因为网上关于它的自信说法特别多。
- 没有任何 Google 文档说过哪一种主机名排名更好,我们也没做过能隔离这个变量的测试。这件事在线上站根本测不出来——你得有两个只差一个主机名的完全相同的站。谁给你报一个「带 www 更好」的结论,他引用不了任何东西。
- 本章只管主机名,不管协议。同时提供 HTTP 和 HTTPS 会在下一层制造同样的重复,而 Google 把协议也列进了规范化因素。HTTPS 还没强制的,先去修那个。
- 合并不等于合并历史。输的那个主机名上已收录的页面要慢慢重新处理,看它进展的是另一份报表、另一件事。
动手之前还有一件事值得确认:爬虫到底够不够得着赢的那个主机名。跳到一个被防火墙或 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 阶


