WWW vs. Non-WWW

Whether to serve your site from www.example.com or example.com — why it's a canonicalization choice and not a ranking factor, what replaced GSC's Preferred Domain setting, and the DNS and certificate mechanics that actually decide it.

First published: Jul 3, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #2 in URL Structure#14 in Website Structure#153 in Technical SEO#207 on the site
AIAuthored byAI v2
1 evidence signal on this page

www is a subdomain; non-www is the bare/apex/root domain. Google has said since 2005 there's no ranking difference — it's a canonicalization and consistency choice. The old GSC 'Preferred domain' setting was removed in June 2019; the replacement is consistent signals (rel=canonical + sitemap + a 301 from the version you didn't pick). The real reason sites default to www is DNS: a CNAME can't sit at the apex, so bare domains need A/ALIAS/ANAME records. Whatever you redirect from still needs a valid TLS cert. Pick one, 301 the other, keep everything consistent.

TL;DR — www is a subdomain; non-www is the apex/bare/root domain. Google has said there’s no ranking difference since 2005, reaffirmed by Mueller in March 2024 (“when the canonical URLHow search engines pick one canonical URL among duplicates and consolidate signals onto it. switches, it just switches”). GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Preferred Domain setting was removed June 18, 2019 — the replacement isn’t a toggle but a bundle of agreeing signals: rel=canonical, sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. inclusion of only the chosen version, and a permanent redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. from the other. Canonical signals can disagree, so consistency across all of them matters more than any single setting ever did. The real reason sites default to www is DNS — a CNAME can’t sit at the zone apex, so bare domains need A/AAAA or ALIAS/ANAME/CNAME-flattening. Watch the TLS/HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. trap on the version you redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. from, remember host-only cookies don’t cross hostnames unless you set Domain to the apex, and drop the obsolete cookie-free-domain argument.

Evidence for this claim The www and non-www hostnames are distinct URLs; redirects and canonical signals can consolidate them to a preferred version. Scope: Current Google duplicate URL consolidation guidance. Confidence: high · Verified: Google Search Central: Canonicalization methods Evidence for this claim Changing a site's hostname is a URL-changing site move that requires redirects, updated internal signals, and monitoring rather than a simple ranking toggle. Scope: Current Google site-move guidance. Confidence: high · Verified: Google Search Central: Site moves with URL changes

www is a subdomain; non-www is the apex

Start with the definitional point, because everything downstream flows from it: www is a subdomain, structurally identical to blog. or shop.. example.com is the apex (also “bare” or “root”) domain — the zone apex, where the domain’s SOA and NS records live. That distinction sounds pedantic until you get to DNS, where it’s the whole story.

Because www is a subdomain, it’s tempting to reach for everything Google has said about subdomains to answer the ranking question — but that’s the wrong evidence for the job. Mueller’s often-cited line that Google treats subdomains and subdirectories “the same” algorithmically answers a different question: where to organize genuinely different content, like a blog on blog.example.com versus /blog/. www versus non-www isn’t that kind of choice — it’s identical content reachable at two hostnames, which is a canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. question, not an information-architecture one. The direct, www-specific evidence for “no ranking difference” is next.

Does www vs non-www affect rankings? No.

This is the question everyone actually wants answered, and the answer has been stable longer than almost anything in SEO. Google’s original 2005 post on the topic already framed it as a duplicate-URL/consolidation issue, not a ranking one. Nearly twenty years later, in March 2024, John Mueller answered a site owner whose Cloudflare migration had silently flipped their canonicals from www to non-www: “This won’t cause problems with search visibility / rankings / indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.”

The one caveat he adds is the load-bearing distinction: “The only time it would cause bigger changes is if you switch canonicals to a different domain… with a www/non-www switch it’s all within the same domain and you should be fine.” That’s why this is low-drama: www and non-www are the same registered domain. You’re not changing domains, you’re picking a hostname.

So treat “does it affect rankings” as already settled — no — and spend your effort on the parts that actually take work: the DNS setup and the redirect.

Be precise about what consistency buys you, too: picking one hostname and aligning your signals removes duplication ambiguity for crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.. It doesn’t guarantee rankings, traffic, or that an AI OverviewAI Overviews are the AI-generated summary box Google shows above or within its regular search results, written by Gemini models from pages retrieved out of Google's normal Search index. It's a Search feature, not a separate platform or index. or chatbot cites you — nothing about canonicalizing correctly promises an outcome, it just gives search engines and AI answer systems one clear address to point at instead of two.

The history: GSC’s Preferred Domain setting

For years, Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. had a Preferred domain setting: you told Google whether to show your site as www or non-www, and it obliged. That’s the setting a lot of older tutorials still tell you to flip. It’s gone.

Google announced its removal in the June 18, 2019 post Bye Bye Preferred Domain setting: “As we progress with the migration to the new Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. experience, we will be saying farewell to one of our settings: preferred domain.” And critically, it stopped honoring old configurations: “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” So even if you set it years ago, it’s doing nothing now.

What replaced it isn’t a new toggle — it’s a combination of signals you have to keep in agreement. Google spelled out the options in that same post: “Use rel=“canonical” link tag on HTML pages / Use rel=“canonical” HTTP header / Use a sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. / Use 301 redirectsA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. for retired URLs.” In practice that means:

  1. A 301 redirect from the version you didn’t pick to the one you did.
  2. rel=canonical tags pointing at your chosen version.
  3. A sitemap that lists only the chosen version — Google’s 2005 guidance already warned not to submit both: having both listed “won’t affect the indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. of your site as long as you have submitted a Sitemap for only one version.”

Why “hint, not rule” means consistency wins

Here’s the part that makes the old single-setting mindset dangerous. Google’s canonicalization docs are explicit that all of these are suggestions: “indicating a canonical preference is a hint, not a rule.” Google weighs several factors — HTTP vs HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', redirects, sitemap inclusion, and rel=canonical annotations — and it can still pick the version you didn’t want if your other signals (backlinks, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them.) lean the other way.

That’s exactly why consistency across every signal matters more than any one setting ever did. A canonical tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. pointing at non-www while half your internal links and your sitemap point at www is a mixed message. Pick one and make all of it agree — this is the same “consistency beats optimization” principle that runs through the URL-structure and canonicalization work in this cluster; www vs non-www is just one of the roughly 40 canonicalization signals catalogued there.

So why do so many sites default to www? DNS.

This is the question almost every other article skips, and it’s the actual answer: DNS, not SEO, not branding.

A CNAME record is the easy button for pointing a hostname at a CDN or host: you CNAME www.example.com to your provider’s hostname, and it just works — and keeps working if the provider changes IPs. But the DNS spec won’t let a CNAME live at the zone apex. The apex must carry SOA and NS records, and a CNAME has to be the only record at its node — those two rules conflict, so a bare CNAME at example.com is illegal per the spec (RFC 1912 / 2181), and most DNS providers reject it.

To get the same “point at my CDN” behavior on the bare domain, you need one of:

  • an A/AAAA record (requires a static IP, which many CDN/host setups don’t hand you), or
  • a provider-specific ALIAS / ANAME record, or Cloudflare’s CNAME flattening — all of which fake a CNAME at the apex by resolving it server-side. Not every DNS provider supports these.

That friction is very plausibly the actual reason so many platforms default to www: it’s the hostname that can always take a simple CNAME. It’s a hosting/DNS decision dressed up as an SEO one.

Cookies are scoped to the hostname you choose

Hostname choice has a second, easy-to-miss consequence: cookie scope. A cookie set without a Domain attribute is a host-only cookie — it’s sent back only to the exact host that set it. Set a session cookie on www.example.com with no Domain attribute, and it never reaches example.com (or any other subdomain), and vice versa.

If you want a cookie shared across the apex and its subdomains, set Domain to the apex explicitly — e.g. Domain=example.com. Per RFC 6265, a cookie’s Domain value has to match the current host or a parent of it, so you can set Domain=example.com from a page served on www.example.com, and the cookie then applies to example.com and every subdomain — but you can’t set Domain for an unrelated domain.

This matters most during a migration. If your session or preference cookies are host-only on the version you’re retiring, that state doesn’t carry across the 301 to the new hostname — visitors can get logged out or lose a saved preference on their first visit after the switch. Set Domain to the apex ahead of the migration if you need continuity across both hostnames while the redirect is live, or budget for a one-time re-login on switch day.

You’ll still see advice to use a separate cookieless domain (often the bare domain, or a dedicated assets subdomain) for static files. That was a real HTTP/1.1-era optimization: every request to a cookie-carrying domain shipped the cookie’s bytes along with it, even for images and CSS, so serving static assets from a cookieless host saved overhead. GTmetrix and PageSpeed used to flag it.

It’s largely dead now. HTTP/2’s HPACK header compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits. plus the near-universal use of CDNs for static assets erase most of the benefit, and splitting assets onto a separate host now costs you an extra connection setup. Don’t pick www vs non-www — or spin up an assets subdomain — for this reason in 2026.

The HSTS and certificate trap

Here’s the practical gotcha that bites people mid-switch, and it’s genuinely underserved elsewhere. When you redirect one hostname to the other, the hostname you redirect from still needs its own valid TLS certificate. A 301 from https://www.example.com to https://example.com only fires after the browser completes a TLS handshake with www.example.com — so if www has no valid cert (or a cert that doesn’t cover it), the visitor gets a full-page security warning before your redirect ever runs. Cover both hostnames, with either separate certs or one SAN/wildcard cert.

HSTS makes this sharper. An HSTS policy is host-specific — a policy set on example.com does not automatically protect www.example.com, and vice versa. includeSubDomains only propagates one direction (a parent’s policy can cover its subdomains; a subdomain’s policy never covers the parent). So if you’re on the HSTS preload list or forcing HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', make sure the cert-and-HSTS story is coherent on both hostnames, or the forced-HTTPS step will surface the missing-cert warning before the redirect.

Bing has no Preferred Domain equivalent

Bing never had a preferred-domain toggle. Practically, Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. treats www, non-www, and each HTTP/HTTPS combination as separate properties to verify and report on — so even after you’ve picked a canonical and redirected the rest, you’ll manage the variants as distinct properties there. The consolidation mechanism is the same as Google’s: set the server-side 301, keep canonicals and sitemap URLs consistent with your choice.

How to actually pick one and make it stick

  1. Choose based on DNS/hosting reality, not SEO. If your host/CDN needs a CNAME and your DNS provider doesn’t do ALIAS/flattening, www is the path of least resistance. If your DNS supports apex flattening and you prefer the cleaner bare domain, go non-www. Brand preference is a fine tiebreaker — it’s a real tie.
  2. 301-redirect the other version — a permanent 301, not a 302. (A 302 signals “temporary” and doesn’t consolidate the way you want.)
  3. Make canonical tags, sitemap, and internal links all agree on the winner.
  4. Check whether login/preference cookies are host-only. If you need sessions or saved preferences to survive the switch, set Domain to the apex before you flip the redirect — otherwise budget for visitors getting logged out once.
  5. Ensure both hostnames have valid certs so the redirect never trips a warning.
  6. Add/verify the properties in Google Search Console (Domain properties cover all variants) and Bing Webmaster Tools (verify the variants separately).
TIP Check every host and protocol variant reaches one final URL

Run the checks only after both hostnames have valid TLS. The redirect trace verifies observable hops; canonicals, sitemaps, internal links, and Search Console still need to agree with the same hostname.

Trace the hostname variants with my free Redirect Checker Free

  1. Test HTTP and HTTPS on both www and non-www for a representative path.
  2. Confirm all non-preferred variants reach the selected HTTPS hostname in one hop.
  3. Repeat on a few deep paths and preserve query strings only where the destination needs them.

Then leave it alone. Like changing URLs generally, re-litigating www vs non-www on a working site is effort spent for no ranking gain.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.