A non-www domain is a domain name served directly from the root domain: without the www subdomain prefix. example.com is a non-www domain. redirect.supply is a non-www domain. Any website whose canonical address is the bare domain name, the second-level domain and TLD without any prefix, is using a non-www configuration.

The term non-www distinguishes this configuration from the traditional www subdomain convention, www.example.com: that dominated web addressing through the 1990s and 2000s. As websites moved away from the www prefix in the 2010s the need for a term describing the alternative emerged. Non-www, naked domain, and bare domain all refer to the same thing, the website accessible at example.com rather than www.example.com.

Non-www domains have become increasingly common, many modern websites serve directly from the root domain, particularly among technology companies, startups, and newer websites that never adopted the www convention. Whether to use www or non-www is a choice with technical implications but no SEO consequence, the important thing is choosing one form, configuring it consistently, and redirecting the other to it.

Non-www vs www, the technical distinction

From a DNS perspective the difference between www and non-www is straightforward, www is a subdomain while non-www is the apex domain. This distinction has meaningful technical implications.

www is a subdomain: www.example.com has a DNS record for the www label in the example.com zone. Typically this is a CNAME record pointing to hosting infrastructure or a redirect management service. CNAME records are the most flexible DNS connection mechanism, they automatically follow IP address changes at the target. Any service that provides a hostname rather than a fixed IP address can be connected via CNAME to a subdomain.

Non-www is the apex domain: example.com without any prefix is the zone apex. The apex has a fundamental DNS restriction: CNAME records are prohibited at the zone apex because NS records and SOA records must exist there. The apex must use A records pointing to IP addresses, ALIAS/ANAME records for CNAME-like behaviour, or Cloudflare’s CNAME flattening.

This technical distinction means connecting a non-www domain to modern hosting platforms, CDNs, and redirect management services, which typically provide hostnames rather than fixed IP addresses, requires additional DNS configuration compared to connecting a www subdomain. The CNAME restriction at the apex is the primary technical complication of non-www configurations.

Non-www domains and the apex CNAME restriction

The CNAME restriction at the apex is the defining technical challenge of non-www domain configuration. Understanding it and the available solutions is essential for anyone setting up redirect management or hosting for a non-www domain.

The problem: a hosting or redirect management service provides the hostname proxy.redirect.supply as the address to point a domain to. For a www subdomain this is simple, www.example.com CNAME proxy.redirect.supply. For the non-www apex example.com this CNAME configuration is prohibited by the DNS specification. The apex cannot have a CNAME.

Solution 1, A records with stable IP addresses: if the hosting or redirect management service provides stable, fixed IP addresses the apex can use A records pointing to those addresses. example.com A 104.21.30.120. The A record functions like a CNAME in practice, requests to example.com reach the service’s infrastructure. The limitation is IP address stability, if the service changes its IP addresses the A record must be manually updated.

Redirect Supply provides stable infrastructure IP addresses that can be used as A records for non-www apex domains, ensuring the connection works reliably even though CNAME cannot be used.

Solution 2, ALIAS or ANAME records: some DNS providers offer non-standard record types, ALIAS or ANAME: that provide CNAME-like behaviour at the apex. The provider resolves the target hostname to its current IP address internally and returns an A-record-style response to resolvers. The apex appears to have an A record from the outside while the provider dynamically follows the target hostname. Available on Route 53, DNSimple, NS1, and others.

Solution 3, Cloudflare CNAME flattening: Cloudflare’s nameservers automatically flatten CNAME records at the apex. A CNAME configured in the Cloudflare DNS interface for the apex is resolved to an IP address before the response leaves Cloudflare’s infrastructure. From the resolver’s perspective the response looks like an A record. Requires using Cloudflare as the DNS provider.

Solution 4, redirect apex to www: avoid the apex CNAME restriction entirely by making www canonical and redirecting the apex to it. The apex has a simple A record pointing to a redirect server that issues a permanent redirect to www.example.com. The www subdomain uses a CNAME pointing to the actual hosting or redirect management infrastructure. The apex itself never directly serves content, only redirects.

Non-www domains and SSL certificates

HTTPS support for non-www domains requires SSL certificates covering the apex domain specifically. SSL configuration for non-www domains has some specific considerations.

Certificate coverage: a certificate for www.example.com does not cover example.com: the apex. A certificate for example.com does not cover www.example.com. When both the apex and www subdomain are involved, which is virtually always the case since one should redirect to the other, the certificate must cover both. Multi-domain SAN certificates covering both example.com and www.example.com are the standard approach.

Let’s Encrypt and apex domains: Let’s Encrypt issues certificates for apex domains through the same ACME challenge process used for subdomains. DNS validation, adding a TXT record to verify domain control, works for apex domains. HTTP validation, placing a file on the web server, also works as long as the apex domain resolves to the server where validation is performed.

Dedicated redirect management platforms that automatically provision SSL handle apex domain certificates as part of the connection process, provisioning certificates that cover both the apex and the www subdomain simultaneously. This eliminates the SSL complexity from the domain owner’s perspective.

SSL and the redirect sequence: for a non-www canonical domain where www.example.com redirects to example.com the SSL certificate must cover both, the www subdomain needs SSL to establish the HTTPS connection before the redirect response can be sent, and the apex needs SSL to serve content correctly over HTTPS. An incomplete certificate that covers only one form causes certificate errors for visitors arriving at the uncovered form.

Non-www and redirect configuration

Configuring redirects correctly for non-www domains requires handling all URL variants, both the www/non-www distinction and the HTTP/HTTPS distinction, ensuring every possible way a visitor might arrive reaches the canonical non-www HTTPS destination.

The four variants: a complete non-www redirect configuration handles all four combinations:

• http://example.com — HTTP, non-www → redirect to https://example.com

• https://example.com — HTTPS, non-www → serve content

• http://www.example.com — HTTP, www → redirect to https://example.com

• https://www.example.com — HTTPS, www → redirect to https://example.com

Three of the four variants redirect to the canonical form. Only https://example.com: HTTPS, non-www, serves content directly.

www to non-www redirect: the most important redirect in a non-www configuration. www.example.com must permanently redirect to example.com. Without this redirect www visitors either hit errors, if www has no DNS record, or see the same content at a different URL, duplicate content if www is configured to serve content.

The www subdomain must have a DNS record pointing to redirect infrastructure. CNAME records are the appropriate DNS mechanism for the www subdomain, pointing it to the redirect management service’s hostname. The redirect service receives requests at www.example.com and returns a 301 redirect to https://example.com.

Combining redirects in a single hop: the most common misconfiguration with non-www domains is creating redirect chains. Handling HTTP-to-HTTPS as one redirect and www-to-non-www as a separate redirect creates two hops for visitors arriving at http://www.example.com: first to https://www.example.com then to https://example.com. Both redirects should be combined into a single hop, http://www.example.com redirects directly to https://example.com in one step.

HSTS for non-www domains: HTTP Strict Transport Security tells browsers to always use HTTPS for a domain. An HSTS header on the non-www canonical domain instructs browsers to preemptively upgrade all future requests to HTTPS, eliminating the HTTP-to-HTTPS redirect overhead for returning visitors. The includeSubDomains directive extends HSTS protection to all subdomains including www. The preload directive enables the domain for HSTS preloading, browsers include the domain in their built-in list of HTTPS-only domains.

Non-www domains in practice

Many of the most prominent websites on the internet serve from non-www domains, demonstrating that the www prefix is not required for successful, high-traffic web properties.

Technology companies have broadly adopted non-www domains, stripe.com, github.com, notion.so, linear.app, vercel.com. Consumer internet companies including facebook.com, instagram.com, twitter.com, and many others serve from the apex. The trend toward non-www is particularly strong among technology-focused companies and startups launched after the www convention began declining.

Traditional enterprises and large organisations are more likely to retain www, either because their infrastructure was established when www was standard or because their technical teams have not prioritised changing an established configuration. www.microsoft.com, www.apple.com, www.amazon.com: major enterprises often still use www as the canonical form.

Neither pattern is more correct than the other, the technology trend toward non-www reflects preference and the reduced technical friction of modern DNS solutions like Cloudflare CNAME flattening and ALIAS records, not any technical superiority of non-www over www.

Non-www and SEO

Like the www vs non-www discussion generally, the non-www choice has no inherent SEO advantage or disadvantage. Google treats both configurations equivalently when correctly set up with one redirecting to the other.

Canonical consistency: the most important SEO consideration for non-www domains is ensuring all signals consistently point to the canonical non-www form. Canonical tags on every page should reference the non-www HTTPS URL. Internal links should use the non-www form throughout. The XML sitemap should list non-www URLs exclusively. Inconsistency between the configured redirect and the canonical tags, redirecting www to non-www but then having canonical tags pointing to www, creates conflicting signals.

Google Search Console setup: both example.com and www.example.com are separate properties in Google Search Console. The non-www form should be the primary verified property where performance monitoring happens. The domain property, sc-domain:example.com: covers all variants including both www and non-www which simplifies Search Console management.

Link juice from all backlink variants: external backlinks may reference either www or non-www forms. The permanent redirect from www to non-www ensures all backlinks regardless of form contribute their equity to the canonical non-www URL. Monitoring backlinks and their form distribution is useful for understanding where equity is flowing from before the redirect.

Common non-www mistakes

Missing www DNS record: configuring the apex as canonical without adding a DNS record for the www subdomain. Visitors who type www.example.com receive DNS errors, NXDOMAIN, rather than being redirected to the apex. Even if www is not canonical it must have a DNS record pointing to redirect infrastructure.

HTTPS failing on www: the www subdomain DNS record points to redirect infrastructure but the infrastructure has no SSL certificate for www.example.com. Visitors arriving at https://www.example.com receive certificate errors before the redirect fires. The redirect infrastructure must have SSL covering www for the redirect to work cleanly.

Redirect chain from two-step handling: HTTP-to-HTTPS handled separately from www-to-non-www creating two hops. Combine into single-hop redirects from every non-canonical variant directly to https://example.com.

Canonical tags pointing to www: the website redirects www to non-www but pages include <link rel="canonical" href="https://www.example.com/page">. The redirect and canonical signals conflict, search engines receive contradictory information about which URL is canonical. Update canonical tags to reference non-www URLs consistently.

Not updating internal links after changing from www to non-www: migrating from www to non-www canonical without updating internal links. Every internal link still references www.example.com: adding unnecessary redirect hops to every internal navigation. Update all internal links to reference the canonical non-www form directly.

A record pointing to wrong IP after infrastructure change: the apex A record was configured correctly but the redirect management service changed its IP addresses. The A record still points to the old IP, apex requests fail or reach the wrong server. Monitor for IP address changes from infrastructure providers and update A records promptly.