截至 2026 年 6 月，www 和根域名之间的选择几乎纯粹是审美问题。真正的麻烦从这一刻开始：你在 yoursite.com 和 www.yoursite.com 上发了同样的页面，两者之间又没有跳转——Google 这时看到的是两个站点，本该叠在一个 URL 上的外链权重被劈成了两半。决策很小，执行必须精确，因为 DNS、host 的主域设置、canonical 标签和 Search Console 这四处都得对齐。
一句话总结
- 选一个 host 作主域。新独立站通常选根域名（
yoursite.com），更短、更符合输入习惯；只有当www已经攒了外链时才留www。 - 另一个版本 301（或 308）跳过来。Google 把两者都当作强力的永久 canonical 信号；真正伤 SEO 的只有”完全不跳转”或”信号混乱”。
- 目标是一跳。
http://www应该直接落到https://apex，而不是先经过http://apex绕一圈。 - 每页设同一个 canonical 标签，用
curl -sI验证只有一跳，并注册一个 Search Console Domain property，让 apex 和www一起被覆盖。
问题背景
历史上 www 是一个 hostname 约定，指向 web 服务器，而根域名可能服务于邮件、FTP 等。现代托管把这个区分塌缩了：两个名字都能指向同一个 web 服务。如今关键是选一个做规范，让另一个 301 重定向过来，让搜索引擎、浏览器和复制粘贴的用户都收敛到一个 URL 上。
有一个技术上的不对称至今仍在。你随时可以给 www 这样的子域名设 CNAME，但多数 registrar 不允许在 apex（@）上设 CNAME。那些只给你 CNAME 目标的 host（Vercel、Netlify）靠厂商专用 A 记录或 Cloudflare 的 CNAME flattening 绕开这个限制。这让 apex 配置时略微麻烦一点，但用起来并不更差。
判断标准
https://yoursite.com和https://www.yoursite.com都能加载站点（之间没重定向）。- Search Console 两个 property，或者同一内容的曝光分裂。
- 外链一半指 root 一半指
www。 - canonical 标签指向另一版本。
dig +short两个 hostname 各自独立返回 IP。
各家 host 怎么处理跳转
如今你基本不用自己写跳转。截至 2026 年 6 月，下面是各家替你代劳的方式：
| Host | 内置 apex↔www 跳转 | 你需要配置 |
|---|---|---|
| Vercel | 是，自动 | 两个域名都加，把一个标 Primary，另一个自动 301 |
| Firebase Hosting | 是，勾选启用 | 在连接域名向导里勾选”将所有请求重定向到第二个域名” |
| Cloudflare Pages | 是，用 Redirect Rules | 加一条 Redirect Rule（见步骤 4） |
| Netlify | 是，自动 | 设主域，别名自动 301 |
| 裸 VPS / nginx | 否 | 写一个 server 块把另一个 host 301 过去 |
快速结论
选一个。多数现代独立站选根域名（yoursite.com），因为更短、也符合大家敲域名的习惯。把另一个版本 301 重定向到所选域名，然后让 DNS、host 的主域设置和 canonical 标签三处一致。
开始前准备
- 改之前 24 小时把 DNS TTL 调到 300s。
- 选好主域（apex 或
www），写下来。 - 知道 DNS 是 registrar 管还是 Cloudflare 管。
实操步骤
-
决定并写下来。 新站默认 apex。已有
www站且外链多就留www。 -
两个名字都加 DNS 记录，最终解析到同一处。 Vercel（apex 作主域），截至 2026 年 6 月：
Type Name Value TTL
A @ 76.76.21.21 300
CNAME www cname.vercel-dns.com. 300较新的 Vercel 项目会拿到一个项目专属的 CNAME 目标，形如 xxxxxxxx.vercel-dns-016.com，而不是共享的 cname.vercel-dns.com。旧值仍可解析，但粘贴前先跑 vercel domains inspect yoursite.com 确认你项目实际要求的记录。
Firebase Hosting 给你 apex 的 IP 199.36.158.100，外加一条 IPv6 的 AAAA 记录。把 @ 和 www 都指到同一条 A 记录；加完 TXT 后 Firebase 会显示要用的验证值：
Type Name Value TTL
A @ 199.36.158.100 300
A www 199.36.158.100 300
AAAA @ 2620:0:890::100 300-
host 里把一个标 primary。 Vercel：Project → Domains → 把
yoursite.com设 Primary，www.yoursite.com自动 301。Firebase：在 Hosting → 添加自定义域名时，勾选”将所有请求重定向到第二个指定域名”，让 apex 和www合并到一个上。 -
host 不自动跳转（Cloudflare 前置）时，加 Page Rule 或 Redirect Rule：
# Cloudflare Bulk Redirects（CSV 导入）
source_url,target_url,status,preserve_query_string,preserve_path_suffix
https://www.yoursite.com/*,https://yoursite.com/$1,301,true,true或者 Cloudflare Redirect Rules UI：
当请求匹配
Hostname 等于 www.yoursite.com
则
类型: Static
URL 重定向: https://yoursite.com${uri.path}${uri.query}
状态码: 301
保留 query string: ON- 每页 canonical 指主域。 Astro layout 里：
<link rel="canonical" href={`https://yoursite.com${Astro.url.pathname}`} />部署后验证：
grep -R 'rel="canonical"' dist | grep -v 'https://yoursite.com' | head
# 有输出 = 漏到非主域-
Search Console 加主域为 property。 用 Domain property（TXT）覆盖 apex 和
www，sitemap 提交的 URL 用主域。 -
curl验证跳转：
curl -sI https://www.yoursite.com | head -3
# HTTP/2 301
# location: https://yoursite.com/
curl -sI http://yoursite.com | head -3
# HTTP/1.1 301 Moved Permanently
# Location: https://yoursite.com/
curl -sI https://yoursite.com | head -3
# HTTP/2 200理想是一跳：http://www → https://apex 不应先经过 http://apex 或 https://www。Google 大约能跟到十跳，但它更偏好一跳，SEO 实践也建议控制在三跳以内，所以发现链条就把它压平。
- 更新你能改的外链（社媒资料、GitHub README、邮件签名）。301 处理搜索引擎可见的入站链接；人眼看得到跳转闪一下。
执行检查清单
- DNS 同时有 apex 和
www记录，最终指同一 host。 - host 的 “primary domain” 与所选主域一致。
curl -sI显示非主域到主域一跳 301。- 每页 canonical 指主域。
- Search Console Domain property + sitemap 用主域。
上线后验证
dig +short A yoursite.com和dig +short A www.yoursite.com都能解析。- 两个 URL 各跑一次 Lighthouse：一个返回 200，一个显示跳转。
- 4 周后 Search Console Performance 显示流量只在主域上。
容易踩的坑
- apex 和
www都发同一内容、互不重定向。Google 眼里就是重复内容，权重也被劈开。 - apex 和
www指向不同 build（一个 staging 一个 prod）。重定向只配了一半时常见。 - 选了
www，却照着默认 apex 的 DNS 文档配，结果配出错记录。 - canonical 标签和实际地址不一致：apex 页面 canonical 写
www，或反过来。这种不一致会让 Google 对你选的 URL 犯嘀咕。 - 一个版本提交 Search Console，canonical 标签却指向另一个。选一个，全站统一。
- 多跳跳转（
http://www→http://apex→https://apex）。它仍然能用，但每多一跳都更慢、信号也更弱。压成一跳。
FAQ
- Google 在意我选哪个吗？ 不在意。Google 官方建议是选一个、把另一个跳过去，apex 和
www它没有偏好。伤 SEO 的是信号混乱，而不是你选了哪个。 - 跳转用 301 还是 308？ 都行。Google 把两者都当作强力的永久 canonical 信号。一般用 301，除非你的框架默认 308（有些框架在 HTTPS 升级时会用）；只是别拿临时的 302 或 307 来做永久迁移。
www过时了吗？ 审美上基本是，多数新站不用。技术上仍然没问题，而且 DNS 上略占优：www子域名上的CNAME普遍支持，而 apex 上的CNAME不行。- 后面能换吗？ 能，但当作一次迷你域名迁移来办：配好 301、更新 Search Console property、改掉每一处 canonical 标签。恢复期会有小幅排名波动。
- Host 只支持一个名字怎么办？ 现代 host（Vercel、Firebase、Netlify、Cloudflare Pages）多数两个都支持并自动重定向。不支持的话，用 Cloudflare 前置域名再加一条 Redirect Rule。
- Cloudflare CNAME flattening 在 apex 上行吗？ 行。当 host 要求
CNAME目标、而 registrar 不让在@设CNAME时，这就是标准做法。Cloudflare 解析这个 CNAME 后对外提供 A 记录，所以仍然符合规范。
Google 关于合并重复 URL 的权威说明，见 Google 官方 canonicalization 文档。
相关阅读
标签: #独立开发 #域名 #DNS #Canonical #SEO