Does www or non-www make any difference to rankings?
Not by itself. Google doesn't prefer one prefix over the other. What it does is treat www.example.com and example.com as two separate hosts, so every page on your site can exist at two addresses. When both answer, the same page competes with its own copy, and links, clicks and history get divided between them. It's one of the most common splits I find when someone hires my duplicate content SEO services.
WordPress's own code says as much. The description of its redirect_canonical function reads: "Search engines consider www.somedomain.com and somedomain.com to be two different URLs when they both go to the same location." That function sends visitors to one of them, and I'll show below why it isn't enough.
So the real question isn't which prefix is better. It's which signals tell Google your choice, and how strongly. Google lists them in its guidance on consolidating duplicate URLs. They're the same signals that sit behind hreflang and canonical tags on a multilingual site, and they're the checklist I work from.
| Signal | How Google weighs it | What I set |
|---|---|---|
| 301 redirect | A strong signal that the target should become canonical | Every URL on the losing host 301s to the same path on the chosen one |
| rel="canonical" | A strong signal for the URL it names | Each page names itself on the chosen host, never the other one |
| XML sitemap | A weak signal, but it helps | Only chosen-host URLs, nothing from the other host |
| Internal links | Linking consistently helps Google understand your preference | Menus, content and footer all use the chosen host |
The trouble starts when those four disagree. A canonical pointing at non-www on a page the server happily serves on www, with a sitemap listing www, is a site sending Google two answers. Google then picks for itself, and it doesn't always pick your version.
WWW vs non-www: what's the technical difference?
The www version is a subdomain of the bare domain, and that changes two things: cookies and DNS. MDN's guide says you need to pick one and stick with it, and that the choice is yours. These differences are why some sites still pick www on purpose.
Cookies first. MDN's Set-Cookie reference says a cookie's Domain attribute "makes the cookie available to that domain and all its subdomains". So a site on the bare domain that sets cookies for it sends them to every subdomain too, like a shop or help desk on its own subdomain.
Then DNS. The bare domain is the top of the zone and carries the domain's NS records, and RFC 1912 says "A CNAME record is not allowed to coexist with any other data." A host or CDN that asks you to point a CNAME at its hostname works on www without fuss. On the bare domain you need a workaround such as Cloudflare's CNAME flattening, which Cloudflare says "allows you to use a CNAME record at your zone apex".
| www | non-www | |
|---|---|---|
| Pros | Cookies can stay off other subdomains, and any DNS provider can point it at a CDN with a CNAME | Shorter to type, say and print, and it's what many visitors type anyway |
| Cons | Four extra characters in every address | Cookies set for the domain reach every subdomain, and a CDN needs CNAME flattening or a similar feature |
| For SEO | No advantage | No advantage |
How do I pick one for an existing site?
On a brand new site, pick whatever you'll print on a business card, unless one of the technical reasons above applies. An existing site is different, because one host usually already holds more of the signals, and switching away from it throws work away. I check four things first.
The first is what the site says it is: the Site Address under Settings, General, the address WordPress builds every link from. The second is what Google has chosen. URL Inspection in Search Console shows a user-declared canonical and a Google-selected canonical side by side, and if they disagree on the homepage, Google's telling you it doesn't believe your setting.
The third is where the links point: a backlink export split by host shows which version other sites have linked to for years. The fourth is where the clicks land, in the Performance report filtered by page, for both versions of the homepage and your top pages. Usually all four agree. When they don't, it's a real decision, and one of my own clients sits right there.
Rather have me do this? One person, whole job.
Book a call on UpworkWhat does a www vs non-www split look like in Search Console?
It looks like one page listed twice. On the Harmonized Getaways vacation rental site, the Performance report shows the non-www homepage with 12,294 impressions and the www one with 11,180. Same page, same content, two rows, and they don't rank alike.
The direction is the interesting part. The live site canonicalises to non-www, yet the www homepage holds the far better average position, 5.3 against 13.2. The non-www row still draws more impressions and more clicks, 252 to 118, so neither host is an obvious loser. When I checked the live hosts on 27 September 2026, www already 301'd to non-www, so that split is past data still waiting to consolidate. The fault still standing is http://www, which takes two hops to reach the homepage instead of one.
| Homepage URL | Impressions | Average position |
|---|---|---|
| https://harmonizedgetaways.com/ | 12,294 | 13.2 |
| https://www.harmonizedgetaways.com/ | 11,180 | 5.3 |
You'll only spot a split like this if your property can see both hosts. A Domain property covers every subdomain and both protocols, so www and non-www show up side by side. A URL-prefix property only covers the exact prefix you entered, so a site verified as https://example.com/ can have a busy www twin its owner never sees.
The Pages report adds the rest. Losing-host URLs listed under Page with redirect are what you want, and here's what Page with redirect means: Google's found the 301 and won't index that URL. Duplicate, Google chose different canonical than user is the warning, and when Google picks a different canonical it needs its own diagnosis. On a www split, the URL Google chose instead is often the same page on the other host.
How I force one version in WordPress, the server and Cloudflare
I go from the inside out, WordPress first and the edge last. Each layer catches requests the one before it can't see, and the test at the end is what proves the whole chain.
- Step 01
Set both WordPress addresses to the chosen host
WordPress Address and Site Address under Settings, General, both on https and both on the chosen host. If wp-config.php defines WP_HOME and WP_SITEURL, I change them there instead, because the file wins.
- Step 02
Don't lean on WordPress's own redirect
WordPress already sends a 301 when a page is requested on the wrong host. But redirect_canonical bails out on admin screens, searches, previews and any request that isn't a GET or HEAD, and files the server hands out directly never reach WordPress at all.
- Step 03
Add a server-side 301 for everything
On Apache that's a rewrite rule in .htaccess, and on Nginx a server block for the losing host. It keeps the path and the query string and answers in one hop. Google recommends server-side permanent redirects, such as 301 or 308, for exactly this.
- Step 04
Match it in Cloudflare if the site uses it
Cloudflare's own example is a redirect rule matching
https://www.*with the targethttps://${1}, a 301 and the query string preserved. It only matches HTTPS, so I check the http:// www address separately. And Cloudflare only sees traffic on proxied records, so a DNS-only www record walks straight past it. The rest of my Cloudflare SEO setup follows the same one-layer rule. - Step 05
Check the canonical tag in the page source
WordPress builds its permalinks, and the canonicals made from them, off the Site Address, so step one usually fixes it. I still read it in the source of the homepage, a post and a page, because a hard-coded canonical in a theme or builder template doesn't follow the setting.
- Step 06
Rewrite old internal links
Content written before the switch still carries full URLs on the old host, in posts, menus, buttons and widgets. A database search and replace moves them, so internal links don't hop through a redirect on every click.
- Step 07
Keep the sitemap on one host
The sitemap should list chosen-host URLs only. I read a handful of its entries rather than trust the plugin setting, and resubmit it in Search Console.
- Step 08
Test all four combinations
http and https, www and non-www, for the homepage and a deep URL with a query string. Each one must land on the chosen host in a single 301 hop, on a page returning 200. I check each with
curl -Irather than a browser, which may have cached an older redirect.
Never let two layers disagree. A Cloudflare rule sending www to non-www while WordPress's Site Address still says www is a redirect loop, and the site goes down for every visitor. I change WordPress first, then the server, then Cloudflare, testing after each.
What do I measure after the switch?
Every URL on the losing host changes address, so I treat a www switch as a small site move, not a settings tweak. Google's site move guide names it directly, in its note on "switching between www and non-www on the same domain", and warns that rankings can fluctuate while Google recrawls. For a medium-sized site, it says, Google can need a few weeks or more before it shows the new URLs. So I won't put a date on it.
In the Performance report I compare both hosts, page by page, against the 28 days before the switch. Impressions should leave the losing host's rows and arrive on the chosen host's rows. A page whose old row drops while its new row stays flat is the one I open first.
In the Pages report, the losing host's URLs should drift into Page with redirect, and in URL Inspection the Google-selected canonical should match the host I chose. When all three line up, Google's accepted it.
Two things I don't do. I don't use the Change of Address tool, because Google says it isn't needed for a www switch on the same domain. And I don't remove the redirects once things settle. Google's advice is to keep them for at least a year, and old links to the other host keep arriving long after that.
If Search Console shows your homepage twice, or your canonical and your server disagree about which host is real, that's host consolidation, and it's a fix I do remotely from the audit through the weeks of measuring after it.
Book a call on Upwork
