你应该在你的域名中使用www吗？

关注

翻译最新推荐文章于 2026-03-22 00:17:30 发布 2.1k 阅读 AI 写同款· GEO 优化 ›

使用API在CloudFlare上批量添加域名的DNS - www转@ - by PHP 目标为CloudFlare上的所有的域名添加一条DNS记录（www.xxx.com转xxx.com）： TYPE NAME CONTENT CNAME www @ 另一个例子：https://blog.csdn.net/qq285744011/article/details/88357409 每个域名，只允许存在一条A纪录（where type ... 阅读详情

原文地址：https://bjornjohansen.no/www-or-not
渣翻译，有英文阅读能力的可以去原网址阅读，正文部分的括号内有译者注的部分是译者的补充说明，其他则是原文的补充说明
自豪地采用谷歌翻译

你应该在你的域名中使用www吗？

20多年了，关于是否应该在你的域名中使用www的争论一直存在，所以你应该使用www吗？

历史背景

尽管人们经常互换着使用域名与主机名的术语。不同点在于，它们不仅是语义上的，我会稍微简化一下这个描述。有如下观点：
作为一个IT管理员，你的网络（译者注：这里应该是说主机所拥有的网络地址，所以早期人们访问web服务应该是通过IP地址访问的？。）就是你的域名。为域名命名是合理的，DNS解析就是为此而生的。所以你会注册一个域名，比如“example.com”。现在，在这个域名下你会有你的主机，每个连接到网络的机器都被视为主机。用于提供万维网文档服务的计算机自然会在您的域下获得主机名“www”，因此给出了完全合格的域名“www.example.com”，不论是否你有没有一个网络服务，你都将对网络中的所有其他主机执行相同的操作。这就是你能够保持网络中主机井井有条的方式。

为了访问域名“example.com”的网络服务，你会去访问到“www.example.com”的主机。顺便说一句：当恐龙(译者注：原文的单词为dinosaurs)漫游到互联网时，就没有虚拟主机这样的东西了。所有Web服务器都提供单个Web站点（至少每个IP地址），您使用的主机名无关紧要，只要它指向正确的IP地址即可。

裸域名，比如，域名没有www，类似于“example.com”，这样的域名在DNS的术语中称为“源”。随着万维网在1990年代中期的普及，一些管理员开始将裸域名指向与www主机相同的IP地址。这将允许网站访问者在其Web浏览器中仅键入“example.com”，而不是完整的主机名“www.example.com”。

SEO来了

自从源“example.com”和主机名“www.example.com”可以指向不同的IP地址时，并且自1997年1月以来，在同一IP地址的不同网站上 - SEO的知识开始告诉我们必须选择一个规范的主机名，另一个应该指向那里（使用HTTP 301响应代码）。

因此，选择一个主机名是有道理的。但是要选哪个呢？只要你选择了一个主机名，对于SEO而言已经没有问题了。但是还有其他问题而不仅仅是SEO。请继续阅读。

人类对URL的理解

在世纪之交，我在营销机构工作时，有一个真实的担忧是：如果我们遗漏“www”部分，那么人们可能不会理解它是万维网地址。我的意思是，我们刚开始遗漏了“http://”。此外，由于遗留问题，我个人更喜欢使用完整的“正确”主机名，即“www.example.com”。

今天，我不认为那是一个问题了。不论你是否有www，人们都会认为那是一个web地址。如果你有一个俗称的顶级域名，因为一个版本无论如何都会重定向到另一个版本。如果你的规范的主机名是“www.example.com”并且你仅仅在广告内容中使用“example.com”，那没有任何问题。因为它看起来更好。同样，如果您拥有新的顶级域名（数千个新的顶级域名之一），例如.beer，您可能希望包含www的原因与我们很久以前的营销原因相同。

非www更漂亮，更容易

我必须承认：“example.com”对于用户输入来说要更简短一些。更容易读出（你怎么一口气读出“www”？）它只需要更少的空间。完全可以理解人们开始放弃“www”部分，并将源（译者注：也即裸域名）作为规范主机名。

那么为什么是否包含www仍然是一个问题呢？

现在为什么我们仍然还在辩论这个问题？人们不能只使用他们喜欢的东西，我们其他人会保留它（译者注：应该是说还有人想要使用以www开头的主机名）吗？答案是肯定的。但是你想，如果你是一个web站点的管理员，你可能想做出有根据的选择。因为与互联网上的大多数东西一样，当我们开始使用它们时，并非所有事情都被考虑过，比如cookie。

Cookies会传递到子域

对一个主机名设置cookies，它也将会发送给所有的子域。比如，如果web站点“example.com”设置了一个cookie，当访问“www.example.com”时，浏览器也将会发送这个cookie。听起来是一个好事情，因为它们是同一个web站点，对吧。但是cookie也将会发送给“cdn.example.com”,发送给“email.example.com”，发送给“intranet.example.com”，发送给“thirdpartyservice.example.com”，等等很多。许多第三方服务让您可以像这样使用您的域名

一个来自于“www.example.com”将不会发送给其他的兄弟主机，类似上面写的主机名。你的浏览器理解了它们并不是子服务，而是完全不同的服务，并且不应该去访问你的cookies

不必要的cookies会损害性能

HTTP和cookies的工作方式，浏览器的每个请求都会发送cookies到web服务。这意味着如果你的网站为源域名（“example.com”）设置了一个cookie，这个cookie也必然在访问子域名服务，比如“email.example.com”,或者“intranet.example.com”的每个请求都会携带上。这会减慢通信速度，让你的用户体验更差.

cookies可以由第三方阅读

因此，如果您的网站位于源域名（“example.com”）并且已登录CMS，则CMS将向您的浏览器的当前会话发出cookie以保持你的登录态。然后，当你访问“someinternalservice.example.com”时，服务的管理员就可以读取你的cookie了。复制这个cookie后，就可以以你的身份登录并操作CMS。同样的事情也适用于其他的子服务，比如：“email.example.com”，当你访问“example.com”时，资源提供商，比如cdn，static等也会访问到你的cookies。

如果您担心“example.com”上的任何内容的安全性，确保你的访问URL前面有“www”内容。如果这都不能帮助您选择是否应该使用www，我不确定什么内容会帮到你了。HTTPS和2FA都不会帮助你，因为cookie是神奇的标记。但其他安全措施，如IP限制将有所帮助。

如果您愿意，可以共享子域中的Cookie

现在，如果你有一个服务在子域名上，比如“sso.example.com”，RFC6265标准允许你为源域名设置一个cookie，它可以分享到“example.com”或者“www.example.com”,因此避免把裸域名作为主机名，实际上可以给你更多的灵活性。

DNS源不能是一个CNAME

谈及灵活性，我们必须再次回到DNS中。

DNS的源有一个限制，必须是A类型记录，这意味着它必须指向固定的IP地址。
当您的站点变大并将其移动到托管服务，或者想要将其指向Web应用程序防火墙或DDoS缓冲区时，你可能想要使用CNAME类型记录，将主机名指向供应商管理的另一个灵活主机名，具体取决于您的流量和需求。
现在，如果你的站点是被托管到“example.com”源上。你不能做上面的操作，但是“www”主机名是CNAME记录则没有问题，因此，如果您想要任何扩展灵活性，无论是现在还是将来，你应该从头开始使用www主机名。