www 与 Apex 域名整合：301/308 重定向对 SEO 和运营效率的重要性

www.与 Apex 域名，为何必须合二为一？(301/308 重定向的重要性)

您是否曾仔细观察过 Chrome、Edge、Safari 等现代浏览器？当您在地址栏输入 www.naver.com 或 www.google.com 时，会发现 www 悄然消失，只剩下主域名（Apex Domain）。有时甚至连移动版 m. 域名也会被隐藏。

这是现代浏览器为了使地址栏更简洁而采用的“微不足道的子域名（Trivial Subdomains）”隐藏策略。从用户角度看，地址变短可能更舒适，但作为一名网页开发者，我们需要深入思考：“浏览器隐藏显示”与“实际作为独立域名运行”是截然不同的问题。

重定向应用前后对比流程图

DNS 和搜索引擎机器人清晰地“看见”www

在实际的 DNS 处理过程或对于搜索引擎机器人 (如 Googlebot) 来说，www.example.com 和 example.com 是截然不同的目标。如果这两个地址都返回 200 OK 响应并显示相同内容，技术上就相当于运营着两个拥有“重复内容”的网站。

全球 IT 公司如何解决这个问题呢？我们通过 curl 命令直接验证一下。

1. 雅虎日本的案例

$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...

雅虎日本在通过 Apex 域名访问时，会发送 301 Moved Permanently 重定向到带 www 的地址。

2. 谷歌的案例

$ curl -I https://google.com/
HTTP/2 301 
location: https://www.google.com/
...

$ curl -I https://www.google.com/
HTTP/2 200 
...

谷歌也一样。访问 google.com 会重定向到 www.google.com，最终只有 www 域名返回 200 响应。

为什么必须将流量重定向到其中一个域名？

这不仅仅是为了“看起来更简洁”，其中蕴含着明确的 SEO（搜索引擎优化）和运营效率考量。

1. Canonical Tag 的局限性

许多开发者认为只要设置了 <link rel="canonical" href="..."> 标签就万事大吉了。然而，Canonical 标签仅仅是给搜索引擎的一个“提示”。机器人仍需抓取这两个 URL，这会浪费抓取预算（Crawl Budget）。当机器人本可以抓取您网站的新内容时，却在抓取现有内容的“副本”。

2. 链接权重（Link Juice）的分散

当其他网站链接到您的内容时，有些人会带 www，有些人则不带。如果没有进行重定向处理，该页面本应积累的权威性（Authority）就会分散到两个域名上，从而在搜索排名竞争中处于劣势。

解决方案：在 Web 服务器层面强制重定向

这种处理方式在应用程序（如 Django, Node.js 等）代码层面之外，于 Nginx 或 Apache 等 Web 服务器（基础设施）层面进行最为高效。因为在请求到达应用程序之前，服务器能立即将其重定向，从而减少资源消耗并提高速度。

以下是在运营 example.com 时，将所有请求统一到 Apex 域名 (https://example.com) 的 Nginx 配置示例。（如果想统一到 www，只需更改目标地址即可。）

# 1. www (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 308 https://example.com$request_uri;
}

# 2. www (HTTPS) -> Apex (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 308 https://example.com$request_uri;
}

# 3. Apex (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 308 https://example.com$request_uri;
}

# 4. 实际服务逻辑 (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... 服务设置及 Proxy Pass 等
}