Typing in www has fallen out of vogue with the rise in mobile web surfing, so many site owners have elected to drop it. But, is that good for SEO? And what about cookie tracking across sub-domains?
Discover if www or non is the best fit for your site and how to ensure Google knows your preference, and how not to confuse your SEO, especially with HTTPS involved.
Jargon
To help you understand the whole domain and link concept thing a little better, let’s break down the technical jargon into non geek speak.
Domains
BlogAid is a root domain name.
BlogAid.net is a root domain name with a top-level domain extension (the .net part). Other top-level extensions include .com, .org, .biz, and .info.
WWW is considered a sub-domain.
So www.blogaid.net is considered a 2nd tier domain because blogaid.net is a sub-domain of www.
When we add another sub-domain, like www.webmaster.blogaid.net it is considered a 3rd tier domain, whereas webmaster.blogaid.net is considered 2nd tier.
When a domain has no sub-domains, including www, it is called a naked domain.
Canonical Links
In WordPress, go to Settings > General.
The two URLs listed there should be the same, and they are your site’s canonical URL.
They will be either http or https and www or non.
Every new link you create will be derived from that canonical.
New links include:
- Upload media
- New page/post
- New category/tag
So, if you suddenly change the canonical in those settings, all new links will match it.
But, that does nothing to convert your existing links to the new canonical.
In other words, simply changing the canonical in Settings > General does not change every link on your site to it.
It only impacts newly created links.
The old canonical links are still in your database and they are simply redirected to the new URL path.
More on redirects in a moment.
Hidden Header Info
When a visitor requests a link to your site, a wad of hidden info is sent to their browser along with the site’s page/post info that will be displayed on their screen.
Hidden header info contains:
- The type of server the file is on (Apache, Litespeed, etc)
- Caching directives for the browser (how long to hold static content)
- The status (200 ok, 301 redirect, 404 not found, etc)
- SSL certificate
- Canonical URL
- Domain-level cookie tracking
Header Example
Let’s say your canonical is http and www.
When a visitor types in that canonical, the header info will look something like this:
It has a status of 200 ok and the rest of the hidden header info.
WWW Redirects
WordPress internally handles the www or non redirects.
So, if your canonical is www and a mobile user leaves that part off, then WordPress internally redirects to the canonical and the header looks like this:
Now you have a 301 redirect before landing on the final destination of 200 ok.
HTTPS and WWW
As previously stated, www is a sub-domain, also called a hostname, and WordPress internally handles the redirect.
HTTPS is a protocol.
It determines whether the visitor connects to your site via a secure or unsecure port on the host server.
Port 80 is unsecure and uses http.
Port 443 is encrypted and uses https.
The host server determines how incoming requests are routed to these two ports.
HTTPS and Redirects
The free way of changing your site to HTTPS involves changing the canonical to https and forcing all links to use the HTTPS port to connect.
None of the links in your database are actually converted to HTTPS.
And if you add just changing your canonical in WordPress settings to non www, you’ve suddenly got a bunch of different link types in your database too.
And that means you’ve got a huge bunch of different redirects going on.
What a mess!
Actually converting the database links to the new canonical gets rid of all that chaos.
All past and future links are truly the new canonical.
Forced Redirects
FYI, it’s a good practice to force all incoming requests to use HTTPS if your site has been converted.
You can also force www or non, but most people don’t, as that is internally handled by WordPress already.
Old Links Out in the World
No matter how you changed over to HTTPS or www or non, your previously shared links are out in the world and some manner of redirect will be involved to force them to comply with the new canonical.
Here’s an example.
Let’s say you’re a foodie blogger and your posts are evergreen.
That means you likely have thousands of http-www links shared all over the web on social media and other sites.
When you convert to https and non www, all of those previously shared links will be redirected by either the host server and/or WordPress to comply with the new canonical. And that’s what will display in the URL bar when the page loads.
Redirect Example
So, let’s say your new canonical is https and www.
When a site visitor inputs the non canonical of http and non www, your header redirect chain looks like this:
The host server forced a redirect to the encrypted https port.
And WordPress forced an internal redirect to www.
So, you have a redirect chain of 301, 301, 200.
That’s a lot of redirecting!
This is the most common redirect chain, as mobile users tend to not type in https or www.
You want to do everything you can to minimize redirect chains.
Redirects and SEO
Every time a link has to go through a redirect it can drop a little “Google juice”.
So, you want to avoid all the redirects you can.
You can’t do anything about the links you have already shared on social media in the past.
But, you can share the new canonical links from the time you make the switch and going forward.
You can also update all of your site URLs in your social media profiles.
Over time, the old links simply won’t be clicked as much because they won’t be seen.
Google Analytics and Search Console
It’s easy to change your Google Analytics property settings to your new canonical.
It won’t skip a beat in tracking, and none of your old tracking data will be lost.
Google Search Console is a different story.
You need to verify the site property for every version of your site’s URL.
So that means verifying your naked domain with:
- Http www
- Http non www
- Https www
- Https non www
Be sure to submit your XML Sitemap to the version that is the canonical.
If you plan to make a change to your canonical, ensure you have an XML sitemap submitted to the property version as it stands now.
Then recreate your XML sitemap after the change, verify that property in GSC, and submit the new XML sitemap.
Basically, Google has told us that it prefers you just give it all the info and it will sort everything out.
Search Console Data and Messages
Until Google catches up to the canonical changes made on your site, especially if you have not enforced redirects to them, Googlebots may still show links and crawls on your previous property versions.
It’s a good idea to clean all those up after you make the switch.
Google data includes:
- Inbound links
- 404 errors
- Crawl errors and warnings
Once you get everything cleaned up, you can do a Fetch as Google to initiate a new crawl.
If you forced redirects, those bots will crawl the new canonical links.
Google will eventually figure out that you have made a major link change. It could take 3-6 months for all of your property info to get square in Search Console.
No Loss of SEO on Inbound Links
Backlinks are at the very heart of SEO ranking.
If you have inbound links to your old canonical they will still count toward your naked domain ranking even after you switch to a new canonical.
Keep in mind that what Google shows you on each of the various domain version properties in Search Console is different from how Google aggregates all that data and crunches it through their ranking algorithm.
So, while it may look to you like a bunch of different sets of info, it’s all one big thing to Google.
Even juice from sub-domains and sub-directories floats back and forth to the root domain, although there is still a raging debate on which one of those floats the most back to the root domain.
Bottom line, changing your canonical does not negatively impact your SEO on inbound links.
Plus, Google is giving a bump in rankings right now for any sites that are HTTPS, so you’ll ride that perk for as long as it lasts.
If you have the time, you can ask the high quality sites giving you a backlink to update to your new canonical. That doesn’t give you a bump in ranking, but it does cut out one more redirect chain.
Why Keep WWW?
There are only two good reasons to keep the www sub-domain.
Reason 1
WWW makes adding DNS records more flexible, specifically adding records for more sub-domains or sub-directories across redundant cloud hosting.
For example, if you have an enterprise level site (think the size of Amazon) and your site’s files are distributed across cloud services then you need the DNS to have a CNAME record. You can’t do that with a naked domain (sans www).
Reason 2
If you have a huge site and you serve static content from another source to speed up page load, then you need to ensure the cookie info in the header of your site is not passed to the sub-domain where the static content is stored. That becomes a huge speed issue and defeats the whole reason you’re delivering static content from a secondary source. If you don’t use www, the only way around that issue is to purchase another domain for the static content.
Bloggers Don’t Need WWW
I think it’s plain to see that most bloggers, no matter how big, don’t have the two reasons above for keeping www in their URL.
What they do have are more mobile visitors than ever, and those visitors hate typing in any more than they have to.
If they are simply clicking on a shared link they saw in Facebook, it’s the new canonical, so no worries.
That’s why so many bloggers are dropping www now.
Share Counts
The only other thing you have to concern yourself with when changing the links for both HTTPS and WWW is your share counts, if you display them.
They will need to be recovered and there are only two share plugins that can do that.
Plus, not all social media platforms participate in either providing counts or in that recovery.
Pinterest is one of the few that does allow you to recover fairly accurate share counts, and that might not stay that way forever either.
Need Help?
Need to properly square away your site’s canonical, convert to HTTPS, or ensure your Google connections are correct?
See my Site Services page or contact me directly.
This book could save you hundreds of dollars and months of frustration. Get it free with your subscription to
Thank you for this very useful post, Ma Anna :-)
You’re most welcome Olivier!!!
This answers so many questions. Thanks!!!
Thanks, Martha! I’m glad you asked about some of this. Turned out to be a good post.
But what about cloudlfare? Holding off on using it plus railgun on the same host you use for many clients. Converted to a naked domain when we went https and now told we need need www to set the change as you mentioned above.
Still can’t figure a way around this for the pst few months and likely won’t go with a cdn because of it. Wish there was another option but haven’t come across it, you? Thanks for your great resources too!!!
David, I’ve had zero issues with using CloudFlare with any variation of the domain for any of my sites or client sites. We all have our own Cloudflare account, not through the host. Maybe that’s the issue? Contact me if you want a private consult to figure it out. Will need more details you may not want to share publicly.