本文讲述了一个很常见但容易被低估的问题：网站到底该用 www.example.com，还是直接用 example.com。
实践结论
- www 和不带 www 没有天然优劣，二者在协议层面都只是一个主机名。
- 真正重要的是：全站只保留一个主域名作为规范地址（canonical host），其余入口全部 301 跳转过去。
- 对搜索引擎、浏览器、CDN、证书、日志统计来说，最关键的是“一致性”，不是“www 本身”。
1. 基本概念
在 HTTP URL 里，http:// 或 https:// 后面的第一段就是 host，也就是域名主机名。www.example.com 和 example.com 都是合法 host。
从 URI 规范看，host 只是 URI 的一个组成部分，语义上是大小写不敏感的注册名；DNS 名称则由 label 组成，www 只是最左侧的一个子域名标签。
这意味着：
- www.example.com 不是“更正式”的域名。
- example.com 也不是“更高级”的域名。
- 它们是两个不同的 URL host，除非你主动做统一，否则搜索引擎和用户都可能把它们当成两个入口。
2. 先给结论：推荐怎么做
推荐原则
- 选一个作为主域名。
- 另一个做 301 永久跳转。
- 页面内所有绝对链接、站点地图、规范标签、Open Graph 地址都统一到主域名。
- 搜索控制台和监控里同时保留两个入口，但只让一个版本参与索引。
常见选择
- 偏传统、偏大型站点、偏 CDN/多机房场景：通常选 www.example.com
- 偏品牌、偏极简、偏单站点展示：通常选 example.com
我的建议
如果你没有强烈业务约束，优先按下面的标准来选：
- 如果未来可能接多台源站、多个子系统、多个地域、多个独立应用，选 www
- 如果你希望域名最短、品牌最干净，且站点结构简单，选不带 www
真正要避免的是“两个都能直接访问且都返回 200”。
3. 为什么必须统一一个主域名
3.1 SEO 与重复内容
Google 明确说明，同一个网站可能通过多个 URL 访问；这时搜索引擎会尝试选择一个 canonical URL。站长应该帮助搜索引擎明确哪个 URL 是主版本。
如果 www 和非 www 都返回同样内容：
- 可能形成重复内容
- 外链权重可能分散
- 索引和统计可能分裂
- 站点地图和站内链接如果不统一，会进一步放大混乱
Google 还明确建议，站点所有规范化手段要保持一致，不要在 sitemap、rel=canonical、跳转规则里互相打架。
3.2 浏览器和用户体验
用户通常不关心 www 是否存在，但很容易注意到：
- 书签地址不一致
- 登录态在两个 host 间表现不一致
- Cookie 作用域没配好时，两个版本可能出现“明明是同站点，却像两个站”
3.3 运维和统计
如果不统一：
- Nginx / CDN 日志会分成两份
- Search Console 数据会分成两份
- 访问分析、告警、黑名单规则、缓存命中率都更难看
4. 权威资料怎么说
4.1 Google Search Central
Google Search Central 说明：
- 一个页面可能对应多个 URL
- Google 会尝试识别 canonical URL
- 站点所有 canonical 化方法应该保持一致
- 不推荐用 noindex 来解决同站重复 URL 问题，rel=canonical 更适合
这对 www 和非 www 的问题本质上就是同一类问题：两个主机名对应同一内容时，应该明确主版本并统一出口。
4.2 Google 对 www / non-www 的历史说明
Google 早期就明确提到：
- https://www.example.com/ 和 https://example.com/ 可能指向同一位置
- 但搜索引擎不能自动假定它们一定相同
- 如果两个版本都存在，最好只提交一个版本的网站地图
这意味着对搜索引擎来说，“你有没有做统一”比“你选了哪个”更重要。
4.3 MDN 的建议
MDN 专门写过 www 与非 www 的选择指南，核心观点很实用：
- 两者都能用
- 最重要的是让站点在技术上对两种访问都工作
- 再通过规范标签、重定向等方法把其中一个作为标准版本
4.4 Cloudflare 的实践建议
Cloudflare 的文档直接把 www 和 apex 域名之间的 301 跳转做成了标准操作示例：
- www.example.com -> https://example.com
- example.com -> https://www.example.com
这说明在真实线上环境里，主机名统一不是理论问题，而是最常见的基础运维动作。
5. 选 www 还是不选 www
5.1 选 www 的优点
- 更容易做未来扩展
- 更容易和 apex 域名分离出 Cookie、静态资源、API 子域
- 传统上更方便做负载均衡和多机房架构
- 某些 DNS 提供商对 apex 域名的能力限制更复杂，而 www 是标准子域名，配置更灵活
5.2 选不带 www 的优点
- URL 更短
- 更像“品牌主页”的表达
- 用户复制、输入和展示都更简洁
- 对纯展示型站点、单体博客、轻量官网比较直观
5.3 怎么选更稳妥
可以直接用下面这条原则：
- 单站、少子域、强品牌展示：选 apex
- 中大型站点、未来会扩展子域、会接 CDN/多源站：选 www
如果你现在犹豫不决，通常说明你的站点未来会扩展。此时更适合选 www，因为它更容易留出架构空间。
6. 规范化设计的标准做法
6.1 301 跳转
核心要求：
- 从非主域名到主域名，使用 301
- 保留路径
- 保留 query string
- 不要使用 302 作为常态
示例：
- https://example.com/a/b?q=1 -> https://www.example.com/a/b?q=1
- https://www.example.com/a/b?q=1 -> https://example.com/a/b?q=1
6.2 rel="canonical"
页面 <head> 中要输出规范链接，指向主域名版本。
例如：
<link rel="canonical" href="https://www.example.com/article/abc" />如果你决定主域名是 apex，就写：
<link rel="canonical" href="https://example.com/article/abc" />注意：
- canonical URL 要和站点实际跳转目标一致
- canonical 不要一会儿指 www，一会儿指非 www
6.3 Sitemap 只保留一个版本
站点地图里的 URL 必须统一成主域名，不要混写两个 host。
错误示例：
- https://example.com/a
- https://www.example.com/a
正确示例：
- 全部都用一个版本
6.4 站内链接统一
全站内部链接建议统一输出绝对主域名，或者统一输出相对路径。
优先级建议：
- 页面内导航和 SEO 相关链接：用主域名绝对地址
- 内容正文中的内部跳转：可以用相对路径，减少迁移成本
6.5 证书与 HTTPS
无论你选 www 还是 apex，都要保证 HTTPS 证书覆盖你的实际访问域名。
常见情况：
- 证书覆盖 example.com 和 www.example.com
- 或者使用通配符证书覆盖 *.example.com，再加上 apex 单独 SAN
注意：通配符证书通常只覆盖一个子域层级，所以 *.example.com 能覆盖 www.example.com，但不能自动覆盖 www.blog.example.com。
6.6 Cookie 域作用域
如果站点登录态、用户态、灰度或 AB 测试依赖 Cookie，要提前想清楚：
- Cookie 只给主域名
- 还是给 .example.com 这种跨子域作用域
如果你把 www 当主站，并且未来有 api.example.com、admin.example.com、static.example.com，Cookie 作用域要更明确地设计。
7. 最佳实践证明链
这里把“为什么这么做”串成一条最实用的证明链。
7.1 协议层证明
RFC 3986 把 host 作为 URI 的独立组成部分，host 是区分资源的关键部分。
这说明：
- www.example.com 和 example.com 在协议层就是不同 host
- 如果你不做统一，客户端、搜索引擎、缓存系统都可能把它们当作不同入口
7.2 搜索引擎层证明
Google 说明同一内容可通过多个 URL 访问时，应该明确 canonical。
这说明：
- 主域名选择不是审美问题
- 它是搜索引擎归一化问题
7.3 工程层证明
Cloudflare 提供了直接的 www -> apex 和 apex -> www 的 301 重定向示例。
这说明：
- 行业默认做法不是“同时保留两边”
- 而是“先选一个，再统一把另一个导过去”
7.4 运维层证明
Google 早就提醒，两个版本的站点统计可能分散；可以在 Search Console 里都添加，但 sitemap 只能提交一个版本。
这说明：
- 统计、监控、诊断都需要单一主版本
- 保留双入口只适合兼容，不适合索引和统计
8. 推荐实施方案
方案 A：主域名选 www
适合：
- 企业官网
- CMS/内容站
- 未来可能扩展子域名的项目
部署要求：
- example.com 301 到 www.example.com
- 站点地图、canonical、OG URL 全部用 www
- Cookie 域名策略单独设计
方案 B：主域名不带 www
适合：
- 个人博客
- 产品落地页
- 简洁品牌站
部署要求：
- www.example.com 301 到 example.com
- 站点地图、canonical、OG URL 全部用 apex
- 注意根域名的 DNS 和证书配置
9. 在你这个项目里怎么落地
- 先确认站点主域名到底是 www 还是非 www
- 统一 Site.URL
- 统一 canonical
- 统一 sitemap
- 统一后台配置、主题配置、内容导入数据里的绝对链接
- 在反向代理/CDN 层做 301
10. 反向代理 / CDN 示例
Nginx 示例：非 www 跳转到 www
server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com;
return 301 https://www.example.com$request_uri;
}Nginx 示例：www 跳转到非 www
server {
listen 80;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl http2;
server_name www.example.com;
return 301 https://example.com$request_uri;
}Cloudflare 规则思路
- 匹配源 host
- 保留 path
- 保留 query string
- 返回 301
11. 常见错误
- 两个域名都返回 200
- 301 了首页，却没 301 子路径
- canonical 指向一个域名，sitemap 却是另一个域名
- OG URL、RSS 链接、邮件通知链接还在混用两个 host
- 证书只配了一个 host，另一个 host 访问会报 TLS 错误
- Cookie 域名没设计好，登录态在两个 host 之间丢失
12. 快速检查清单
- 主域名只选一个
- 另一个域名全站 301
- 保留路径和 query string
- 页面 <head> 输出正确 canonical
- Sitemap 只保留一个 host
- 内链统一
- 证书覆盖实际访问域名
- Cookie 作用域与子域策略一致
- Search Console 两个版本都加，但只提交一个版本的 sitemap
13. 最终建议
如果你是新项目：
- 想做长线、可扩展站点，选 www
- 想做极简品牌站，选不带 www
如果你是已有项目：
- 不要纠结“哪个更高级”
- 先选一个作为标准，再把另一边彻底规范化跳转过去
真正的最佳实践不是 www 或非 www，而是：
- 单一规范主机名
- 全站一致化
- 301 永久跳转
- canonical / sitemap / 内链 / 证书 / Cookie 全部对齐