WWW vs Non-WWW: Choose One Canonical Host and Redirect the Other

Most websites can be reached at two addresses that differ only by a prefix: https://www.example.com/ and https://example.com/. Add the old http:// versions and a single page can answer on four different URLs. If your server serves the same page on all four, you have created duplicates without meaning to.

The www vs non-www question is therefore not about which is better. It is about picking one and making every other variant send people and crawlers to it. This guide is for site owners and developers who want a single canonical host. By the end you will have chosen a host, set up a permanent redirect from the other, matched your canonical tags, sitemap and Search Console settings to the choice, and tested all four variants.

Google does not state a preference between the two. Its canonicalization documentation only says to pick one URL variant as the canonical and use redirects to send traffic from the others to it. A consistent choice makes your signals clear. It does not by itself raise rankings.

Before you begin

You will need:

Access to wherever redirects are configured: the web server, the hosting panel, a CDN or the CMS. Find out which layer your site uses, because setting the rule in two places can create loops.
Access to DNS, to confirm both host names point at your site.
A valid TLS certificate that covers both example.com and www.example.com. If a visitor reaches the host that the certificate does not cover, the browser shows a warning before any redirect can happen.
A Search Console property for the site. A Domain property covers the root domain plus all subdomains and protocols, and it needs DNS verification. A URL-prefix property covers only URLs that begin with the exact prefix, including the protocol. See Set Up Google Search Console.
Thirty to ninety minutes, plus a testing pass.

Risk is moderate. A mistaken rule can send every page into a loop or to the wrong address. Copy your current configuration first, test on a staging copy where possible, and have a way to undo the change quickly.

Step-by-step instructions

Step 1: Pick the host

Both choices work. Consider these practical points.

Existing links and brand. If most of your links, ads and printed material already use one form, choosing it means fewer old addresses to redirect.
Technical flexibility. A bare domain is shorter to type. Check what your DNS provider and hosting platform support for the root domain before you decide.
Consistency over time. Changing later means redirecting everything again, so choose the one you can keep.

Write the decision down in the form https://www.example.com or https://example.com. This is the canonical host, and it always uses https. If your site is still on HTTP, read HTTP to HTTPS Migration first or alongside this guide.

What success looks like: a single written decision that includes the protocol and the host.

Step 2: Map the variants

List the four combinations and note what each currently does. Request each with a tool such as curl -I:

curl -sI http://example.com/ | head -n 5
curl -sI http://www.example.com/ | head -n 5
curl -sI https://example.com/ | head -n 5
curl -sI https://www.example.com/ | head -n 5

Record the status code and the Location header for each. A healthy end state has three variants answering with a permanent redirect straight to the canonical one, and one answering 200.

What success looks like: a four-row table of status codes and targets, so you know the starting point.

Step 3: Redirect the non-canonical hosts with a permanent redirect

A permanent redirect, status 301 or 308, tells browsers and search engines that the address has moved for good. Google treats a permanent redirect as a signal that the target should be canonical, and recommends server-side redirects as the form most likely to be interpreted correctly. Use a server-side rule and keep the path and query string.

The redirect should reach the canonical URL in one hop. A visitor to http://example.com/page should go straight to https://www.example.com/page, not first to https://example.com/page and then onward. Chains slow requests and add failure points; see Redirect Chains and Loops.

Here are examples that send everything to https://www.example.com. Adapt the host names to yours.

Nginx, with one server block per job:

# Plain HTTP, either host: one hop to the canonical address.
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://www.example.com$request_uri;
}

# HTTPS on the bare domain: one hop to the canonical address.
server {
  listen 443 ssl;
  server_name example.com;
  # ssl_certificate directives omitted
  return 301 https://www.example.com$request_uri;
}

# The canonical site.
server {
  listen 443 ssl;
  server_name www.example.com;
  # ssl_certificate directives and site configuration omitted
}

For the bare-domain version, swap the host names.

Apache (.htaccess with mod_rewrite):

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

On IIS, the URL Rewrite module can express the same rule, and MDN notes IIS also has an httpRedirect element. In ASP.NET Core, UseHttpsRedirection handles the scheme and a rewrite rule handles the host. On a managed platform such as a CMS or CDN, look for a primary domain or redirect setting and use that and not custom code.

If you also use HSTS, add it only after the redirects work, and read HSTS Setup Guide first because a mistake is cached by browsers.

What success looks like: requesting any non-canonical variant returns a single 301 with the exact canonical address in Location.

Step 4: Align canonical tags, internal links and the sitemap

Redirects are one signal. Make the others agree.

Canonical tags. Each page should carry a rel="canonical" link with an absolute URL on the canonical host. Google advises absolute paths, not relative ones, in the canonical element.
Internal links. Link to the canonical host. Links to the other host still work through the redirect, but each costs an extra request.
Sitemap. List only canonical URLs, written as absolute addresses on the chosen host. Google says that including URLs in a sitemap is a weak canonical signal, so it must not contradict your stronger signals.
Other places. Update robots.txt sitemap lines, hreflang annotations, social profiles, email signatures and ad destinations.

Do not specify different canonical URLs across methods. A sitemap host that differs from the rel="canonical" host sends mixed signals. See Fix Duplicate URLs and Incorrect Canonical Tags.

What success looks like: page source, sitemap and navigation all show the same host.

Step 5: Check the TLS certificate covers both hosts

A redirect only works if the browser can first complete a secure connection to the host the visitor typed. If the certificate covers only www.example.com, a request to https://example.com/ ends in a certificate error and never reaches your redirect. Use a certificate that lists both names, or one for the apex with www added. One certificate can cover several names. Confirm by opening both HTTPS variants in a browser and checking that neither shows a warning. Google also warns that a certificate that does not match your host name pushes it toward HTTP as the canonical, so mismatches are worth fixing.

What success looks like: both HTTPS hosts load without a certificate warning, then redirect as designed.

Step 6: Tell Search Console

If you use a Domain property, it already includes every host and protocol, so you do not need to add anything. If you use URL-prefix properties, add and verify all variants: the canonical https host and the other three. Submit the sitemap under the canonical property. After the change, watch the Page indexing report for unexpected errors on the canonical host. Redirected variants dropping out of the index over time is expected.

Do not use the Change of Address tool for this. Google states it is for moves between domains or subdomains, and not for www to non-www on the same domain; use canonical tags or redirects instead.

What success looks like: the canonical property shows your sitemap and no new fetch errors.

Step 7: Retest everything

Repeat the four curl requests from Step 2. Then test deeper paths, URLs with query strings, a URL with a trailing slash and a missing page. Check the redirect keeps the path and query. Request a page that should return 404 on the non-canonical host and confirm it redirects first and then returns 404 on the canonical host. Spot-check with the Search Console URL Inspection tool on the canonical URL.

What success looks like: every variant ends in exactly one canonical address, with no chain and no loop.

Final verification checklist

The chosen host is written down with its protocol.
http://example.com, http://www.example.com and the non-chosen HTTPS host each return one permanent redirect to the canonical URL.
The canonical URL returns 200.
The redirect keeps the full path and query string.
Canonical tags use absolute URLs on the chosen host.
The sitemap lists only canonical-host URLs.
Internal links, hreflang and robots.txt sitemap lines use the chosen host.
The TLS certificate covers both hosts, and neither shows a warning.
Search Console is set up for the canonical host.

Common mistakes to avoid

Serving the same content on both hosts. Without a redirect, you have duplicate pages. Redirect one host to the other.
A temporary redirect for a permanent choice. A 302 is a temporary signal. Use 301 or 308.
Redirect chains. http://example.com to https://example.com to https://www.example.com is two hops. Send each variant straight to the final URL.
Redirecting everything to the home page. Keep the path so each URL lands on its own page.
Rules in two layers. A CDN rule and a server rule that disagree can loop. Set the rule in one place.
A certificate for only one host. Visitors to the other host get a browser warning before any redirect.
A sitemap on the wrong host. Sitemap URLs should match the canonical host.
Using the Change of Address tool. It is not for www changes on one domain.

Frequently asked questions

Is www or non-www better for SEO?

Google's documentation does not name one as better. Choose one, redirect the other and keep your signals consistent.

Do I need both hosts in DNS?

Yes. Both names must resolve and reach a server that can answer, because the redirect has to be served from somewhere. The exact records depend on your DNS provider, so follow their instructions for the root domain.

Should I use 301 or 308?

Either is permanent. MDN explains that 301 may change a POST to a GET, while 308 keeps the method. For redirecting page views, both behave the same for visitors, and 301 is widely used. For forms or APIs on the old host, 308 is safer.

How long should the redirect stay?

Google's site move guidance says to keep redirects for at least a year and to consider keeping them indefinitely, because old links keep arriving, while noting that redirects do add a little delay for users. Retiring them early risks breaking those links.

Will my rankings change?

A clean consolidation removes confusion, but Google does not promise any specific change. After you switch, expect Google to need time to recrawl and reprocess the URLs.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.