www, World Wide Web, is a subdomain prefix that has been conventionally placed before domain names to indicate a website address since the early days of the internet. In www.example.com the www is a subdomain of example.com: technically identical in DNS terms to any other subdomain like blog.example.com or shop.example.com: but carrying the historical convention that this subdomain hosts the public-facing website.

The www prefix originated in the early 1990s at CERN, the European Organisation for Nuclear Research, where Tim Berners-Lee invented the World Wide Web. The convention of prefixing the website’s hostname with www was a pragmatic way to distinguish the web server from other internet services that organisations operated on different subdomains, mail.example.com for email servers, ftp.example.com for file transfer servers, news.example.com for newsgroup servers. Each service had its own descriptive subdomain. The web server got www.

This convention spread rapidly as the web grew through the 1990s and early 2000s. Nearly every website launched during this era used the www prefix, making it so universal that many users assumed it was a required part of all web addresses. Browser manufacturers accommodated this assumption, typing example in a browser address bar and pressing Ctrl+Enter automatically expanded it to www.example.com in many browsers.

Today the www prefix is optional for most websites, millions of sites serve their content directly from the root domain example.com without any subdomain prefix. But www remains widely used, is still the default for many platforms and hosting providers, and carries no SEO advantage or disadvantage compared to the root domain when configured correctly.

Why www became the standard

The www convention emerged from practical networking decisions in the early web and became self-reinforcing through imitation and user expectation.

Service differentiation on shared infrastructure: in the early internet organisations ran multiple network services on the same domain, web, email, FTP, Gopher, Telnet. Different subdomains pointed to different servers handling different services. www for web, ftp for file transfer, mail for email. The naming scheme was intuitive and descriptive, www meant World Wide Web.

Technical advantages of subdomains: subdomains offer technical advantages over root domains for web hosting. CNAME records can be used for subdomains but not apex domains: making subdomains easier to connect to CDNs, hosting platforms, and other services that provide hostnames rather than fixed IP addresses. Web infrastructure often worked more cleanly with subdomain-based hostnames. The www subdomain facilitated this.

Cookie scope control: cookies set on www.example.com are scoped to that subdomain and not shared with other subdomains like api.example.com or mail.example.com. Serving a website at example.com: the root domain, means cookies are potentially shared across all subdomains. For organisations running multiple services on subdomains the cookie isolation provided by www was technically valuable.

Self-reinforcing convention: as more websites used www users came to expect it. As users expected it more websites used it. Marketing materials, business cards, and media coverage normalised www.example.com as the format for web addresses. Browser auto-completion reinforced the convention, browsers learned to complete partial domain entries with www prefix. The convention became so entrenched that deviating from it was noteworthy, early adopters who dropped www were making a deliberate statement.

www today, required or optional?

www is entirely optional for modern websites, there is no technical requirement to use it, no SEO advantage from using it, and no meaningful user experience difference when configured correctly. The choice between www and no-www is a matter of preference, technical considerations, and organisational convention.

The no-www movement: starting in the mid-2000s a movement emerged advocating for dropping the www prefix, example.com instead of www.example.com. The argument was that www is redundant, everyone knows that example.com is a website, the www prefix adds no information. Prominent websites like Facebook, Twitter, and GitHub adopted root domain serving. The no-www.org website formalised the position.

Practical considerations favouring www: despite the no-www argument there are legitimate technical reasons to prefer www in some situations.

The CNAME restriction at the apex means root domains cannot use CNAME records, limiting flexibility for connecting to CDNs and hosting services that provide hostnames. www subdomains have no such restriction. Organisations using infrastructure that provides hostnames rather than stable IP addresses may find www technically simpler to manage.

Cookie scope is another consideration. Setting cookies at example.com shares them across all subdomains. If the organisation runs authenticated services on subdomains, api.example.com, admin.example.com: cookie leakage from the main website could create security issues. www provides subdomain-level cookie isolation.

Some CDNs and enterprise hosting configurations work more smoothly with subdomain-based setups than with root domain serving.

The only rule, pick one and redirect the other: the most important www decision is not which to use but ensuring that only one is canonical and the other redirects to it. www.example.com and example.com should never both serve content simultaneously without a redirect between them. Search engines seeing identical content at two different URLs create duplicate content issues. SEO equity splits between the two addresses. Canonical URL signals become ambiguous.

Choose either www or no-www as the canonical form and configure a permanent redirect from the non-canonical to the canonical. All traffic, all backlinks, and all SEO equity consolidates at the chosen canonical form.

www as a DNS subdomain

From a pure DNS perspective www is nothing special, it is a subdomain label like any other. www.example.com is configured in the example.com DNS zone exactly like blog.example.com or any other subdomain, with a CNAME record or A record specifying where requests should be directed.

The most common www DNS configurations are:

CNAME to hosting infrastructure: www.example.com CNAME sites.hostingplatform.com. Requests for www.example.com are resolved through the CNAME to the hosting platform’s current IP address. This is the most flexible configuration, the CNAME automatically follows IP address changes at the hosting platform. Used for connecting www to web hosting, CDNs, and redirect management services.

A record to server IP: www.example.com A 203.0.113.42. Requests for www.example.com go directly to the specified IP address. Used when the web server has a fixed IP address. Requires manual update if the server IP changes.

CNAME to root domain: www.example.com CNAME example.com. The www subdomain is an alias for the root domain, they resolve to the same IP address. Technically valid but creates a DNS loop concern in some implementations and is generally not recommended as a canonical configuration.

No www record: the www subdomain has no DNS record configured. Requests for www.example.com return NXDOMAIN, domain not found. Any visitor typing www reaches an error rather than the website. This is a misconfiguration for most websites, both www and no-www should be handled, with one redirecting to the other.

www and redirect management

The www/no-www redirect is one of the most universal redirect configurations, virtually every website needs to handle both variants and redirect one to the other. Getting this redirect right is fundamental to correct URL canonicalisation and SEO.

www to root domain redirect: www.example.com permanently redirects to example.com. The root domain is the canonical form. Visitors and crawlers arriving at the www address are sent to the root domain. All backlinks, regardless of which form they use, consolidate their equity at the root domain.

This redirect requires the www subdomain to be reachable, it must have a DNS record pointing to redirect infrastructure that can return the redirect response. If www has no DNS record at all visitors who type www.example.com receive DNS errors rather than being redirected.

Root domain to www redirect: example.com permanently redirects to www.example.com. The www subdomain is the canonical form. Visitors and crawlers arriving at the root domain are sent to www. All equity consolidates at the www subdomain.

This requires the root domain to be connected to redirect infrastructure. The CNAME restriction at the apex means the root domain connection requires A records pointing to stable IP addresses or ALIAS records providing CNAME-like behaviour, rather than the simpler CNAME configuration used for www.

Handling HTTPS and HTTP variants: a complete www/no-www redirect configuration handles all four combinations of protocol and subdomain:

• http://example.com → https://www.example.com

• https://example.com → https://www.example.com

• http://www.example.com → https://www.example.com

• https://www.example.com → serves content

Or in the reverse configuration for root-domain canonical:

• http://www.example.com → https://example.com

• https://www.example.com → https://example.com

• http://example.com → https://example.com

• https://example.com → serves content

Missing any variant means some visitors receive errors or inconsistent experiences depending on how they arrive.

Redirect chains from www misconfiguration: a common redirect chain source is handling www and HTTPS in separate redirect steps. The server redirects HTTP to HTTPS as one redirect, then redirects www to root as a second redirect, creating a two-hop chain for visitors who arrive at http://www.example.com. The chain should be collapsed to a single redirect directly to the canonical HTTPS root domain URL.

HSTS and www: HSTS, HTTP Strict Transport Security, can be scoped to a domain including or excluding subdomains. An HSTS header with includeSubDomains directive applies to all subdomains including www. A domain using HSTS should ensure the HSTS configuration is compatible with the www redirect strategy, the browser’s HSTS cache must not create conflicts with the configured redirect.

www and SEO

From an SEO perspective there is no advantage to using www over no-www or vice versa. Google and other search engines treat both equally as long as one properly redirects to the other. The choice is entirely a technical and preference decision.

Canonical URL consistency: the most important SEO consideration with www is consistency. All internal links should use the canonical form consistently, mixing example.com and www.example.com in internal links creates unnecessary redirect hops and inconsistent URL signals. After choosing a canonical form all internal links should use it.

Google Search Console property: Google Search Console treats www.example.com and example.com as separate properties, each requires separate verification and provides separate data. The canonical form should be the primary verified property. The non-canonical form can also be verified to monitor crawl errors on that variant but the canonical property is where primary monitoring happens.

Backlink equity consolidation: backlinks from external sites may use either the www or no-www form, the linking site’s author chose which to use. Permanent redirects from the non-canonical form ensure all backlinks regardless of which form they use consolidate their equity at the canonical URL. Without the redirect backlinks using the non-canonical form contribute their equity to a different URL than the canonical, splitting the domain’s authority.

International and regional considerations: for sites targeting specific countries some registrars and hosting providers default to www when configuring domain forwarding to regional hosting. Understanding whether the www prefix is added by infrastructure configuration or by deliberate choice helps avoid accidental www adoption when no-www was intended, or vice versa.

Common www mistakes

Both www and no-www serving content: the most common www mistake. Both variants are accessible and return 200 OK with identical content. Duplicate content issues arise. SEO equity splits between two URLs. Fix by choosing one canonical form and redirecting the other permanently.

www has no DNS record: the root domain serves content at example.com but there is no DNS record for www.example.com. Visitors who type www receive DNS errors. Even if www is not the canonical form it should have a DNS record pointing to redirect infrastructure that sends visitors to the canonical root domain.

No-www redirect missing from HTTPS: the redirect from www to no-www works correctly for HTTP but fails for HTTPS due to missing SSL certificate on the www subdomain. The www subdomain needs SSL for the HTTPS redirect to work without certificate errors.

Redirect chain from protocol and www handling: separate redirects for HTTP-to-HTTPS and www-to-no-www creating two hops. Combine into a single redirect from http://www.example.com to https://example.com directly.

Inconsistent canonical tags: some pages have <link rel="canonical"> pointing to the www version while the site redirects www to no-www, or vice versa. Canonical tags and redirect configuration must be consistent.