Why Do Some Websites Have “www” and Others Don’t? — The Modern Configuration Edition

AI translation notice: This English version was translated from the original Chinese article with AI assistance. Some nuances may differ from the original.

Cover image: Tim Berners-Lee at the 20th anniversary celebration of the World Wide Web in 2009, reunited at CERN with the historic NeXT computer he had used to develop and run the world’s first web server, multimedia browser, and web page editor. Image credit: CERN

The previous post covered where www came from — a naming convention suggested by Tim Berners-Lee, and a necessary way of telling services apart in the early days.

But today, now that the Web has gone from “one machine running one service” to “one IP hosting countless websites,” why is www no longer a necessity? And how should we deal with those headache-inducing DNS details when deploying a site? That is what I want to cover in this post.

Why Did So Many Websites Stop Using www Later?

Because the way the internet gets used changed.

When a website still meant one machine serving one service, www was useful: it kept the web service separate from the mail service and made things easier to manage.

Later, as machines grew more powerful, management also became simpler and easier to maintain. In particular, virtual hosting, the HTTP Host request header (RFC 9110), reverse proxies, CDNs, and cloud platforms gradually became commonplace, so a single IP address could route requests to different websites based on the domain name. The domain name itself no longer had to do the job of explaining what the machine was for.

This also matches the thought Tim arrived at by the end of his answer to Why www?.

At the same time, blahblah.com is four characters shorter than www.blahblah.com. That means it is shorter everywhere it shows up — on posters, business cards, video voiceovers, billboards, and anywhere users type it in by hand. That is obviously better for promoting your own brand and getting people to notice it at a glance, so more and more websites choose the bare domain — blahblah.com, with no subdomain — as the address they present to the world.

That does not mean www is technically outdated.

Keeping www has some practical benefits. It tells the network infrastructure plainly that this is a website; and if you later want to split off api.blahblah.com, static.blahblah.com, or other services, the boundaries stay clearer. Cookie scope (RFC 6265) can also be controlled more carefully: a site sitting on www.blahblah.com will not, by default, send host-level cookies that belong only to the site over to api.blahblah.com.

Where It Actually Gets Tricky: Bare Domains and CNAME

At this point you might think that since www is just a subdomain, you can simply skip it. But things get a little more complicated when you deploy a website, especially the first time you try a CDN, a hosting platform, or a cloud provider.

Here is a first way to understand the two most common DNS records:

A     blahblah.com       -> 203.0.113.10
CNAME www.blahblah.com   -> my-site.hosting-provider.com

An A record points a name straight at an IP address. A CNAME (RFC 1034 §3.6.2, RFC 1035) instead says: for this name, keep looking under another name.

CNAMEs are a good fit for connecting to a hosting platform. When the platform changes its server IP, you do not need to edit your own DNS every day; you just keep pointing at the domain the platform provides. But under the traditional DNS model, once a name has a CNAME, it cannot also have records of other types — RFC 2181 §10.1 states this explicitly.

The problem is that the bare domain blahblah.com is not an ordinary subdomain. That name itself has to carry the domain’s foundational records, such as NS and SOA; it often also holds MX records for email and TXT records for domain verification. Under the traditional rules, a bare domain cannot simply become a CNAME, because those records would then have nowhere to coexist.

This is also why, in the past, many hosting platforms told you: point www.blahblah.com at a CNAME, and have the bare domain do a redirect. As an ordinary subdomain, www can point at the platform quite naturally; the bare domain, because of the historical structure of DNS, is not that straightforward to handle.

How Do Modern DNS Providers Solve This?

Later, DNS providers offered solutions under various names, such as ALIAS, ANAME, or CNAME flattening. Their specific implementations are not entirely the same, but the idea is close: you write a CNAME-like target in the dashboard, the provider resolves that target to an IP for you, and then returns it to the resolver in a form the bare domain can use. Examples include Cloudflare CNAME Flattening, DNSimple ANAME, and AWS Route 53 Alias. The IETF once had a draft-ietf-dnsop-aname draft, but it has not yet become a formal standard.

The provider does the extra resolution work at the DNS edge. As these features became widespread, connecting a bare domain to a CDN or hosting platform was no longer as awkward as before, so “no www” became easy again.

So Which One Should I Choose?

If it is just a personal blog or a small project, you can simply go with each platform’s recommendation — and besides, there is AI now.

If you like shorter addresses, use the bare domain; if you want to keep the traditional habit, or might later separate the site from other subdomain services more clearly, use www. Both approaches can be done well, and neither is much trouble.

Whichever one you choose as the main address, you still have to get redirects and certificates right for the other. DNS has to resolve, the HTTPS certificate has to cover it, and then a 301 has to unify the redirect. Take my own site as an example — I have both configured. Feel free to click and try.

• www.markxu.icu
• markxu.icu

Google Search Central recommends choosing one canonical address and using a 301 redirect, so that link sharing, caching, analytics, and search engine indexing all stay consistent more easily.

Then Why Does Adding www Sometimes Fail to Load?

If a website’s bare domain loads, but manually adding www throws an error, that is uncommon, but it does happen. The reason is usually that the administrator configured only one of the addresses mentioned above.

A complete visit roughly passes through these places in order:

Browser
  -> DNS: does www.example.com have a record?
  -> Server: do I accept www.blahblah.com?
  -> HTTPS: does the certificate cover www.blahblah.com?
  -> Web app: return the page, or redirect to the canonical address

If any one of these steps is not configured properly, something goes wrong.

The simplest case is that DNS has no www record at all. The lookup result is NXDOMAIN, and the browser cannot even find the server.

It is also possible that DNS already points www.blahblah.com at the correct IP, but Nginx, Apache, or the hosting platform has no configuration for that Host, so the server returns a default page, a 404, or simply refuses the request.

There is also an ordering problem that often gets overlooked: if the user visits https://www.blahblah.com, the TLS certificate check happens before the HTTP redirect (RFC 9110 §4.2.2). If the certificate only covers blahblah.com, the browser will block the request at the HTTPS step, before the server has a chance to tell it “please go to the address without www.” That is why certificates usually need to cover both names, or you use a wildcard certificate that includes them both.

A fully configured website often lets both addresses find it, and then picks one as the canonical address:

https://www.blahblah.com  -> 301 -> https://blahblah.com
https://blahblah.com       -> 200

Of course, you can also do the reverse and redirect the bare domain to www; that is entirely your personal choice, and technically the difference is not obvious.

References

• RFC 1034: Domain Names - Concepts and Facilities
• RFC 1035: Domain Names - Implementation and Specification
• RFC 2181: Clarifications to the DNS Specification §10.1
• RFC 6265: HTTP State Management Mechanism
• RFC 9110: HTTP Semantics
• Cloudflare: DNS CNAME record
• Cloudflare: CNAME Flattening
• Google Search Central: Consolidate duplicate URLs