WWW vs Non-WWW: How to Choose and Configure Your Domain
Every website accessible at both www.example.com and example.com without a redirect has a duplicate content problem. Search engines see these as two separate URLs, potentially splitting your link equity and confusing crawlers about which version is canonical. This guide covers how to choose your preferred version, configure a permanent 301 redirect, align your sitemap and canonical tags, and verify everything is working correctly.
The WWW vs Non-WWW Problem
On the web, www.example.com and example.com are technically distinct hostnames. Unless your server explicitly redirects one to the other, search engines treat them as two separate websites. This means any backlinks pointing to your www version and any pointing to your non-www version are counted separately, splitting the link equity that should be consolidating on a single canonical domain. Over time, this dilution can meaningfully suppress your rankings for competitive keywords.
The duplicate content risk compounds the link equity problem. If Googlebot can crawl both versions of your homepage — and every other page on your site — you are effectively presenting two copies of your entire website. While Google is usually good at identifying the canonical version in these situations, it wastes crawl budget, can create unpredictable behaviour in how pages are indexed, and creates ambiguity in how link signals are attributed. None of this is catastrophic on its own, but it is entirely avoidable with a simple server-level redirect.
Beyond search engines, the inconsistency creates real-world problems: analytics tools may split your traffic data across two hostnames, external links shared by users will vary in form, and browser history, cookies, and session data may behave unexpectedly across the two versions. Standardising on a single domain version is a foundational hygiene task that every website should complete before worrying about more advanced SEO.
Which Should You Choose: WWW or Non-WWW?
From a pure SEO standpoint, neither version is better than the other. Google has explicitly stated that the choice between www and non-www is a matter of preference, not ranking. What matters is consistency — pick one and commit to it everywhere: your server configuration, your canonical tags, your sitemap, your Google Search Console property, your internal links, and any external links you control. Switching from www to non-www (or vice versa) after your site is established is possible, but it requires careful planning to avoid temporary ranking disruption during the transition.
That said, there are practical considerations that tip the scales in some situations. The www subdomain offers a technical advantage for large-scale deployments: DNS CNAME records can only be set on subdomains, not on the root domain (the "naked" or "apex" domain). This means that if you need to point your domain to a CDN or load balancer using a CNAME record, www is more flexible. For most small to medium sites on modern hosting platforms, this distinction is invisible because the host handles DNS management automatically.
For new sites, the trend has moved toward non-www — it is shorter, cleaner, and that is how most users type domain names when they omit the protocol. For established sites with significant backlink profiles already pointing to one version, the simplest choice is to stick with whichever version already has the most links. Switching creates a redirect chain that passes the vast majority of link equity, but there is always some marginal loss during a large-scale domain version change.
How Google Treats Both Versions Without a Redirect
When no redirect exists and both versions of a site are accessible, Googlebot will typically crawl both. If your sitemap specifies one version and your pages self-reference the other in their canonical tags, Google receives contradictory signals and must make a judgment call about which version to index and rank. In most cases, Google makes the right call — but "most cases" is not good enough when your SEO depends on reliable signal consolidation.
The practical outcome of an unresolved www/non-www conflict is often that Google indexes the version it encountered first or the version that has more inbound links — which may not be the version you intend to be canonical. You may notice in Google Search Console that both versions appear under Coverage, that some URLs are listed under "Alternate page with proper canonical tag" errors, or that impressions and clicks are split across two separate domain entries if you have both properties set up separately.
Google also crawls both versions separately, which means your crawl budget — the number of pages Googlebot will crawl per day — is effectively halved. For small sites with few pages, this is irrelevant. For large e-commerce or publishing sites with hundreds of thousands of URLs, wasting crawl budget on duplicate www and non-www versions of every page can directly delay indexation of new and updated content.
Setting Up a 301 Redirect with .htaccess (Apache)
If your site runs on Apache, the .htaccess file in your web root controls redirect behaviour via mod_rewrite. The following configuration redirects all www requests to the non-www version with a permanent 301 redirect. Replace example.com with your actual domain name.
Redirect www to non-www (Apache .htaccess):
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]If you prefer www as your canonical version, reverse the redirect:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]The RewriteCond directive checks the incoming hostname, and the RewriteRule captures the full path and appends it to the canonical domain. The [R=301,L] flags tell Apache this is a permanent redirect and that no further rules should be processed. Make sure mod_rewrite is enabled on your server — on most shared hosts it is on by default, but on self-managed servers you may need to enable it with a2enmod rewrite.
Setting Up a 301 Redirect in Nginx
Nginx handles redirects at the server block level rather than through a per-directory config file. The correct approach is to create a dedicated server block that matches the unwanted version of your domain and issues a 301 redirect to the canonical version. Avoid using rewrite rules in Nginx for this — the return 301 directive is simpler, faster, and less error-prone.
Redirect www to non-www (Nginx):
server {
listen 80;
listen 443 ssl;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
# ... rest of your config
}Or to redirect non-www to www:
server {
listen 80;
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
# ... rest of your config
}After editing your Nginx configuration, test the syntax with nginx -t before reloading. A syntax error in an Nginx config can take your entire site down, so the test step is non-negotiable. Once the test passes, reload Nginx with systemctl reload nginx or nginx -s reload. If you use a control panel like Plesk or cPanel on top of Nginx, check whether the panel manages server blocks directly — editing the config file manually may cause conflicts with the panel's auto-generated configuration.
Setting Preferred Domain in Google Search Console
Google Search Console offers two property types: Domain properties and URL-prefix properties. A Domain property (e.g., example.com) covers all subdomains and both HTTP and HTTPS variants automatically — this is the recommended setup because it gives you a unified view of all traffic to your domain regardless of how users or crawlers access it. A URL-prefix property (e.g., https://www.example.com/) covers only the exact URL prefix specified, including any pages under that prefix.
If you set up individual URL-prefix properties for both your www and non-www versions, you will see split data — impressions, clicks, and coverage information will be distributed across two properties rather than consolidated. This makes it harder to diagnose issues and accurately measure your site's performance. The cleanest setup is a single Domain property that captures everything. To add one, go to Search Console, click "Add property," select "Domain," enter your root domain without any protocol or subdomain prefix, and verify via DNS TXT record.
Note that the older "Set as preferred domain" feature in Google Search Console was removed in 2019. Today, Google infers your preferred domain from your redirect configuration, canonical tags, and sitemap URLs rather than from an explicit GSC preference setting. This means your server-level redirect and your on-page canonicals are the authoritative signals — getting them right is more important than any GSC setting.
Canonical Tags and WWW Preference
Every page on your site should include a self-referencing canonical tag that uses your preferred domain version. If your canonical version is non-www, every page's canonical tag must use https://example.com/page-slug. If your canonical version is www, every page must use https://www.example.com/page-slug. Mixed canonicals — where some pages reference the www version and others reference the non-www version — create exactly the kind of ambiguity that the redirect was supposed to eliminate.
Canonical tags are especially important during the transition period after you have implemented a redirect but before Google has fully re-indexed your preferred version. During this window, pages may still appear in the index under the old version, and the canonical tag is the signal Google uses to understand where those pages should ultimately be indexed. A consistent, correctly specified canonical accelerates the consolidation process and reduces the window during which you might see duplicate content warnings in GSC.
Most CMS platforms — WordPress, Shopify, Webflow, and others — generate canonical tags automatically based on a site URL setting. Verify that this setting uses exactly the right protocol and subdomain preference (or lack thereof). In WordPress, this is the "Site Address (URL)" field in Settings. In Shopify, the canonical is derived from your primary domain setting. After updating, audit a sample of pages using your browser's view-source or an SEO browser extension to confirm the canonical href attribute matches your intended canonical domain version.
Sitemap URLs and WWW Consistency
Your XML sitemap must list every URL using your preferred domain version — the same version used in your canonical tags and the destination of your redirect. If your canonical is non-www but your sitemap contains www URLs, Google receives a contradictory signal: the sitemap says these URLs live on www, but the canonical tag says they live on the root domain. This inconsistency forces Google to resolve the conflict rather than simply following your stated preferences, which can slow down indexation and increase crawl waste.
Sitemap URL consistency is particularly easy to get wrong after a domain migration or when switching between CMS platforms that generate sitemaps differently. After any change to your preferred domain version, regenerate your sitemap and do a full text search for the wrong version of your domain. The find-and-replace should be zero-match: every single URL in your sitemap should start with exactly the same hostname, matching your canonical preference down to the last character.
Also check that the sitemap itself is submitted to Google Search Console under the correct property. If you have a Domain property in GSC, submit the sitemap URL from the canonical version: https://example.com/sitemap.xml. Google will crawl the www version via the redirect automatically, but submitting the canonical version directly reinforces the signal and makes sitemap processing more predictable.
Checking Your Configuration Is Working
The most direct way to verify your redirect is working is with a curl command that checks the response headers without following the redirect. This confirms both the status code (should be 301) and the Location header (should point to your canonical domain). Test both HTTP and HTTPS variants of the non-canonical version to catch all cases.
# Check that www redirects to non-www curl -I https://www.example.com # Expected response includes: # HTTP/2 301 # location: https://example.com/
Browser-based redirect checkers will show you the full redirect chain for any URL, making it easy to confirm there is exactly one hop from the non-canonical version to the canonical version. Redirect chains with two or more hops — for example, http://www redirecting to https://www redirecting to https://non-www — pass PageRank through two intermediaries, which is slightly less efficient and adds latency for users. Collapse these to a single redirect where possible.
In Google Search Console, check the Coverage report under Indexing after your redirect has been live for a few weeks. You should see the non-canonical version URLs disappearing from the "Crawled — currently not indexed" or "Excluded" sections as Google re-processes them via the redirect. You can also use the URL Inspection tool to fetch any URL and see which canonical Google has determined — it should match your self-referencing canonical tag, not the redirected version.
Common Mistakes
The most common mistake is implementing the server-level redirect correctly but leaving canonical tags and sitemap URLs on the wrong domain version. This creates a partially resolved conflict: Google follows the redirect to the canonical domain, but then finds a canonical tag that points back to the non-canonical version — or finds sitemap entries with www URLs when the redirect is pointing everything to non-www. The canonical tag, in particular, is a strong signal that Google generally honours even when it conflicts with the redirect destination.
A second frequent error is setting up Google Search Console with the wrong version as your primary property. If you add your site as a URL-prefix property for https://www.example.com/ but your canonical version is non-www, your GSC data will be incomplete and the sitemap you submit will reference the wrong domain. Always match your GSC property to your canonical version, or use a Domain property that captures everything automatically.
Finally, watch out for redirect loops and chains. If a misconfigured .htaccess or Nginx server block causes both the www and non-www versions to redirect to each other, browsers will display a "too many redirects" error and your site will be inaccessible. Always test in a staging environment before deploying redirect changes to production, and use curl rather than your browser to debug redirect chains — browsers cache redirects aggressively, which can mask problems during manual testing.