The www Prefix: A Technical Look at Both Sides
For as long as users have typed URLs, a quiet disagreement has persisted over whether the www subdomain belongs in a web address. Major sites like Google, Instagram, and Facebook redirect example.com to www.example.com, while GitHub, DuckDuckGo, and Discord do the reverse, sending www.example.com traffic to the bare domain.
The origin of the three Ws dates to the late 1980s and the naming convention of using subdomains to indicate a service: www.example.com for a web server, ftp.example.com for FTP, and irc.example.com for IRC. Today, the debate is less about history and more about practical engineering trade-offs.
Evaluating Cookie Leak Risks with Bare Domains
One cited concern with dropping www is that subdomain.example.com could read cookies set by example.com. This is problematic in scenarios like web hosting, where clients operate subdomains on a shared parent domain. However, this behavior was specific to Internet Explorer, and RFC 6265 explicitly standardizes the proper handling that prevents such leaks.
A more realistic concern is the Domain attribute on cookies set by example.com. If a Domain value is explicitly set to example.com, the cookie is exposed to all subdomains. As long as no explicit Domain value is set and users avoid legacy browsers, bare domains do not introduce a cookie leak vulnerability.
| Cookie value | Exposed to example.com | Exposed to subdomain.example.com |
|---|---|---|
secret=data | ✅ | ❌ |
secret=data; Domain=example.com | ✅ | ✅ |
DNS Complications at the Apex Domain
Bare domains can also create DNS headaches. When a browser resolves example.com, a standard A record pointing to the server's IP works fine. The problem emerges when you want to use a CNAME record, such as aliasing www.example.com to a CDN provider's hostname.
Per RFC 1912, CNAME records cannot coexist with other records at the same name. Defining a CNAME for example.com would preclude an MX record for mail delivery to @example.com. Without www, you cannot have both a CDN alias and a mail exchanger at the root of your domain.
DNS providers have developed workarounds. Cloudflare, for instance, offers CNAME flattening, where the administrator configures a CNAME for the bare domain but the nameserver resolves it to an A record. For example, a CNAME pointing example.com to example123.somecdnprovider.com would expose an A record for example.com at the IP of the CDN host, sidestepping the RFC limitation.
Practical Arguments on Both Sides
Advocates for dropping www point to usability: example.com is shorter to say, type, and easier for non-technical users to grasp. There is also a nominal performance benefit, as omitting the prefix shaves four bytes from each HTTP request. While this could accumulate on high-traffic properties, bandwidth is rarely a bottleneck in modern infrastructure.
The case for keeping www is strongest with newer or ambiguous top-level domains. A URL like www.example.miami is immediately clear as a web address, whereas example.miami may be mistaken for something else. This concern fades for well-known .com domains.
Implications for SEO and Canonicalization
The choice between www and the bare domain does not generally affect search rankings. When migrating between them, it's essential to configure HTTP 301 permanent redirects rather than 302 temporary ones to transfer SEO value to the new URLs.
Supporting both simultaneously is possible but comes with complications. Content management systems must output relative URLs to preserve the visitor's chosen hostname, analytics tools need configuration to treat both hosts as aliases, and search engines must be told the two versions are duplicates. Google treats www.example.com and example.com as separate URLs, so it will decide which to display unless instructed otherwise.
To retain control over search results, pick a canonical hostname and insert canonical link tags in the non-canonical version's HTML. For instance, if www.example.com is the chosen hostname, the page at https://example.com/my-article must include:
<link href="https://www.example.com/my-article" rel="canonical">This signals to Google that the bare-domain version is the same content, and generally the marked canonical page takes precedence in results.
Final Considerations
Both configurations are valid for production use. The key is to choose one official hostname, permanently redirect traffic from the other, and be mindful of DNS constraints and cookie attributes. With those steps in place, the www debate becomes simply a matter of preference.
