www or non-www? Pick One Canonical Host and Redirect the Other

For SEO, it does not matter whether you choose www or non-www. What matters is that you pick one as your canonical host and permanently (301) redirect the other to it, on every URL, in a single hop that also moves visitors to HTTPS. Choose www if you expect to rely heavily on a CDN or want cookies isolated from subdomains; otherwise the shorter non-www version is perfectly fine.

Key takeaways

• Google treats www and non-www as separate hostnames. Without a redirect, you can end up with duplicate URLs.
• Neither version ranks better. Consistency is what counts.
• Redirect with a 301, preserve the path and query string, and go to HTTPS in the same step.
• Back the redirect up with canonical tags, sitemap URLs and internal links that all use the chosen host.
• Google Search Console no longer has a "preferred domain" setting, so the redirect does the job.

Why www and non-www are different addresses

example.com and www.example.com are separate hostnames. They can have different DNS records and, in principle, serve different content. Browsers, crawlers and analytics tools treat them as separate. Add HTTP and HTTPS, and a single page can be reachable at four addresses:

http://example.com/pricing
http://www.example.com/pricing
https://example.com/pricing
https://www.example.com/pricing

If all four return the same page with a 200 status, search engines have to guess which is the main version, links from other sites may be split across versions, and your analytics and Search Console data are fragmented. Google is generally good at choosing a canonical URL among duplicates, but you should not leave it to guess when a redirect makes the choice explicit.

www vs non-www: the real differences

There is no ranking advantage to either. The differences are technical:

For most small and medium sites, either choice works. If your site is already established on one version, keep it. Switching later means redirecting every URL and is rarely worth the effort without a technical reason.

Step 1: Check how your site behaves now

Test all four combinations of protocol and host. Each should end at the same final URL. You want:

• A single redirect from each non-canonical version to the canonical one.
• A 301 (or 308) permanent redirect, not a 302 temporary one.
• The path and query string preserved: http://www.example.com/pricing?plan=pro should go to https://example.com/pricing?plan=pro, not to the home page.

The www Redirect Checker shows whether one version redirects to the other. To see the exact status code and redirect target, the Server Status Checker reports the HTTP response for a URL. On the command line:

$ curl -sI http://www.example.com/pricing
HTTP/1.1 301 Moved Permanently
Location: https://example.com/pricing

Watch out for chains such as http://www to https://www to https://. They work, but every hop adds a round trip and another point of failure. Aim for one hop.

Step 2: Make sure DNS covers both hosts

Both names need DNS records, or visitors who type the other version will see an error instead of a redirect.

example.com.      3600  IN  A      192.0.2.10
www.example.com.  3600  IN  CNAME  example.com.

Your TLS certificate must also cover both names. A certificate for only example.com causes a browser security warning on https://www.example.com before the redirect can even happen.

Step 3: Set up the redirect

Apache (.htaccess)

To send everything to https://example.com (non-www):

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

%{REQUEST_URI} includes the path, and Apache passes the query string through automatically, so deep links survive the redirect. If your server sits behind a load balancer or proxy that handles HTTPS, the %{HTTPS} check may not work and you may need to check a forwarded header instead; your host's documentation will say which.

nginx

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate lines here
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate lines and the real site config here
}

To choose www instead, swap the hostnames. Many hosting control panels and CDNs also offer a one-click "redirect to www/non-www" setting, which is fine to use as long as the result passes the checks in Step 1.

CMS settings

Content management systems often store the site address. In WordPress, for example, the WordPress Address and Site Address settings should use the canonical host, otherwise the CMS may generate links or redirects that fight with your server rules.

Step 4: Make every other signal agree

The redirect is the strongest signal, but other places should point to the same host:

• Canonical tags: <link rel="canonical" href="https://example.com/pricing"> on every page, using the chosen host.
• XML sitemap: list only canonical URLs.
• Internal links: use the canonical host, or relative links, so visitors are not redirected on every click.
• hreflang and structured data: any absolute URLs should use the canonical host.
• External profiles: update your main social profiles and business listings where you can.

Mixed signals, such as a redirect to non-www but canonical tags pointing to www, make Google's job harder and can lead it to choose a different canonical than you intended.

Step 5: Tell Search Console and add HSTS

Google removed the "preferred domain" setting from Search Console in 2019, so there is nothing to toggle there. A Domain property covers both hosts and both protocols in one view, which makes it easy to confirm traffic has moved to the canonical version.

Once HTTPS and the redirects work correctly, consider an HSTS header so browsers go straight to HTTPS on later visits:

Strict-Transport-Security: max-age=31536000

Start with a short max-age while testing. HSTS is hard to undo quickly, so only add includeSubDomains or apply for browser preloading once every subdomain you use supports HTTPS.

If you are switching hosts on an existing site

Sometimes a switch is justified, for example when moving to a CDN that needs a CNAME. Treat it like a small site migration:

1. Crawl the site and export the current URLs so you can test them afterwards.
2. Set up the redirects, canonical tags, sitemap and CMS settings for the new host at the same time, not in stages.
3. Spot-check a sample of old URLs, including deep pages and URLs with query strings, to confirm each lands on its exact new equivalent.
4. Keep the redirects in place permanently. Old links on other sites and in bookmarks will keep arriving for years.
5. Watch Search Console coverage and traffic for the following weeks; some short-term fluctuation is normal while URLs are recrawled.

Common mistakes

• Using a 302 temporary redirect instead of a 301.
• Redirecting every URL on the other host to the home page instead of preserving the path.
• No DNS record or no certificate for the non-canonical host, so the redirect never runs.
• Server rules and CMS settings that redirect in opposite directions, causing a redirect loop.
• Canonical tags, sitemaps and internal links that still use the old host.

Quick checklist

1. Pick www or non-www; if the site is established, keep what you have.
2. Confirm DNS and the TLS certificate cover both hostnames.
3. Add a single-hop 301 from all three non-canonical variants to HTTPS on the canonical host, preserving paths.
4. Test the four variants, including a deep URL with a query string.
5. Align canonical tags, sitemap URLs, internal links and CMS settings.
6. Add HSTS once everything is stable.