WWW 仍然属于 URL 吗? Plato区块链数据智能。垂直搜索。人工智能。

WWW 是否仍然属于 URL?

多年来,一场小型的迂腐之战一直在我们的地址栏中肆虐。 在一个角落里有像这样的品牌 谷歌, InstagramFacebook. 该组已选择重定向 example.com 至 www.example.com. 在对面的角落: GitHub上, DuckDuckGoDiscord. 该组已选择进行反向和重定向 www.example.com 至 example.com.

“WWW”是否属于 URL? 一些开发人员对这个问题持有强烈的意见。 在了解了一些历史之后,我们将探讨支持和反对它的论点。

Ws怎么了?

三个W代表 “全球资讯网”,一项 1980 世纪 XNUMX 年代后期的发明,向世界介绍了浏览器和网站。 使用“WWW”的做法源于在子域提供的服务类型之后命名子域的传统:

  • 网络服务器位于 www.example.com
  • FTP 服务器位于 ftp.example.com
  • IRC 服务器位于 irc.example.com

无 WWW 域问题 1:将 cookie 泄漏到子域

“无 WWW”域的批评者指出,在某些情况下, 子域.example.com 将能够读取由 example.com. 这可能是不受欢迎的,例如,如果您是允许客户在您的域上操作子域的 Web 托管提供商。 虽然这种担忧是有道理的,但该行为是特定于 Internet Explorer 的。

RFC 6265 标准化浏览器如何处理 cookie 并明确指出此行为是不正确的。

另一个潜在的泄漏源是 Domain 折扣值 设置的任何cookie example.com。 如果 Domain 值明确设置为 example.com, cookie 也将暴露给它的子域。

Cookie 值 暴露 example.com 暴露 子域.example.com
secret=data
secret=data; Domain=example.com

总之,只要您不明确设置 Domain 值并且您的用户不使用 Internet Explorer,则不会发生 cookie 泄漏。

无 WWW 域问题 2:DNS 问题

有时,“无 WWW”域可能会使您的域名系统 (DNS) 设置复杂化。

当用户键入 example.com 进入他们浏览器的地址栏,浏览器需要知道他们试图访问的 Web 服务器的互联网协议 (IP) 地址。 浏览器从您域的名称服务器请求此 IP 地址——通常是间接通过用户的互联网服务提供商 (ISP) 的 DNS 服务器。 如果您的名称服务器配置为响应 一个记录 包含 IP 地址,“WWW-less”域可以正常工作。

在某些情况下,您可能想改用 规范名称 (CNAME) 为您的网站记录。 这样的记录可以声明 www.example.com 是一个别名 example123.somecdnprovider.com,它告诉用户的浏览器改为查找的 IP 地址 example123.somecdnprovider.com 并在那里发送 HTTP 请求。

请注意,上面的示例使用了 WWW 子域。 无法定义 CNAME 记录 example.com. 按照 RFC 1912, CNAME 记录不能与其他记录共存。 如果您尝试为 example.com, 名称服务器 (NS) 记录 example.com 包含域的名称服务器的 IP 地址将不允许存在。 结果,浏览器将无法确定您的名称服务器在哪里。

一些 DNS 提供商将允许您解决此限制。 Cloudflare 将他们的解决方案称为 CNAME 扁平化. 使用这种技术,域管理员配置 CNAME 记录,但他们的名称服务器将公开 A 记录。

例如,如果管理员为 example.com 指向 example123.somecdnprovider.com, 以及一条 A 记录 example123.somecdnprovider.com 存在指向 1.2.3.4,然后 Cloudflare 会公开一条 A 记录 example.com 指向 1.2.3.4.

总之,虽然对于希望使用 CNAME 记录的域所有者来说,这种担忧是有效的,但某些 DNS 提供商现在提供了合适的解决方法。

无 WWW 的好处

大部分 反对的论据 WWW 是实用的或装饰性的。 “No-WWW”的拥护者认为说和打字更容易 example.com 比 www.example.com (对于不太懂技术的用户来说,这可能不那么令人困惑)。

WWW 子域的反对者还指出,放弃它会带来微不足道的性能优势。 通过这样做,网站所有者可以减少每个 HTTP 请求的 4 个字节。 虽然这些节省对于像 Facebook 这样的高流量网站来说可能会有所增加,但带宽通常并不是稀缺资源。

万维网的好处

支持 WWW 的一个实际论据是在具有更新的顶级域的情况下。 例如, www.example.miami 可以立即识别为网址 例子.miami 不是。 对于具有可识别的顶级域(例如  .

对您的搜索引擎排名的影响

目前的共识是您的选择不会影响您的搜索引擎性能。 如果您希望从一个迁移到另一个,您需要配置永久重定向 (HTTP 301) 而不是临时重定向 (HTTP 302)。 永久重定向确保您的旧 URL 的 SEO 价值转移到新的 URL。

支持两者的技巧

网站通常选择 example.com or www.example.com 作为他们的官方网站并为另一个配置 HTTP 301 重定向。 理论上可以同时支持 www.example.com 和 example.com. 在实践中,成本可能超过收益。

从技术角度来看,您需要验证您的技术堆栈是否可以处理它。 您的内容管理系统 (CMS) 或静态生成的站点必须将内部链接输出为相对 URL,以保留访问者的首选主机名。 您的分析工具可能会分别记录到两个主机名的流量,除非您可以将主机名配置为别名。

最后,您需要采取额外的步骤来保护您的搜索引擎性能。 Google 会将网址的“WWW”和“非 WWW”版本视为 重复的内容. 为了删除其搜索索引中的重复内容,谷歌将显示它认为用户更喜欢的两者中的任何一个——无论好坏。

为了保持对您在 Google 中的显示方式的控制,它建议插入规范链接标签。 首先,确定哪个主机名将是官方(规范)主机名。

例如,如果你选择 www.example.com,您必须在  标记 https://example.com/my-article:

此代码段向 Google 表明“WWW-less”变体表示相同的内容。 一般来说,Google 会更喜欢您在搜索结果中标记为规范的版本,在本例中就是“WWW”变体。

结论

尽管双方都进行了激烈的竞选活动,但只要您了解好处和局限性,这两种方法仍然有效。 要覆盖所有基地,请务必设置从一个基地到另一个基地的永久重定向,一切就绪。

时间戳记:

更多来自 CSS技巧