Type your domain into a browser with www in front. Now type it without. Both probably show your website. The question almost nobody asks is: which one is the real address, and does your site agree with itself about the answer?
This sounds like trivia. It is actually one of the small foundational decisions that, done sloppily, leaks search signal and creates confusing bugs for years. The good news is that the fix is one decision and one redirect.
What "canonical domain" means
To you, www.yourbusiness.com and yourbusiness.com are obviously the same site. To browsers, search engines, and certificates, they are two different hostnames that happen to be related.
Your canonical domain is the one you designate as official. Every other variant, the www version if you chose bare, the bare version if you chose www, should permanently redirect to it. One address is home; the others are signs pointing home.
When that is true, every link, bookmark, search listing, and shared URL eventually converges on a single consistent address. When it is not true, your one site lives at two addresses, and the costs start small and compound.
What it costs to have both
Split search signals. If both versions serve the page directly instead of one redirecting to the other, search engines see two URLs with identical content. Modern search engines are reasonably good at figuring out duplication and consolidating, but you are making them guess, and links to your site divide across both versions instead of pooling on one. Some people link to the www URL, some to the bare one, and the authority that should accumulate in one place accumulates in two halves.
Inconsistent analytics. Depending on configuration, traffic to the two hostnames can be reported in confusing ways, and referral or cookie behavior can differ across them. Sessions that cross from one hostname to the other can break in subtle ways that are miserable to debug precisely because both addresses look the same to a human reading the logs.
Certificate surprises. Your HTTPS certificate must cover every hostname that serves traffic. Plenty of real-world outages take the form of "the site works fine at www but shows a security error without it," because a certificate was issued for one and not the other. If both names answer, both names need coverage, which is one more reason to have one of them simply redirect.
So which should you pick?
Here is the honest answer: for search purposes, it does not matter which one you choose. Search engines have said this plainly for years. What matters is choosing one, redirecting the other, and being consistent everywhere.
There are practical considerations that can tip the choice:
- Technical flexibility favors www. The bare domain (the apex) has DNS limitations: it traditionally cannot use a CNAME record, which is the mechanism many hosting platforms and CDNs prefer for pointing at their infrastructure. Providers offer workarounds, but the www subdomain just works everywhere. This is why many platforms recommend www as canonical.
- Brand simplicity favors bare. Shorter, cleaner on a business card, and what most people type. Many modern hosts handle apex domains fine through their own DNS.
- History usually decides for you. If your site has been live for years on one version, that version has the links, the bookmarks, and the search history. Keep it. Switching canonical versions on an established site is a migration with real risk and almost no upside.
Whichever you choose, the implementation rule is the same: the non-canonical version returns a permanent redirect to the canonical one, every internal link and sitemap entry uses the canonical form, and your profiles, ads, and email signatures all reference one address.
How to check your own setup in two minutes
You do not need tools, just a browser and attention:
- Visit all four combinations: http with www, http without, https with www, https without.
- Each of the three non-canonical versions should land on the canonical https version, with the address bar showing the final form.
- Watch for the version that loads the site directly without changing the address bar. That is the duplicate identity, not a redirect, and it is the configuration leak.
- Check a deep page too, not just the homepage. Some configurations redirect the root but mishandle paths, sending every old deep link to the homepage instead of the matching page.
If anything fails, the fix usually lives in your hosting dashboard or DNS provider, and most platforms make it a checkbox or a single redirect rule.
Why this drifts after you fix it
Here is the part that earns this topic a place in ongoing monitoring rather than a one-time checklist: canonical setups drift.
The redirect is not a law of nature. It is a configuration rule living in a specific layer, your host, your CDN, or your DNS provider. Platform migrations, CDN changes, new certificate setups, and well-meaning settings changes can all silently drop or alter it. The classic failure looks like this: the site moves to a new host, the new configuration serves both hostnames directly, and nobody notices because both versions look fine in a browser. The duplicate-identity problem is back, and it announces itself to no one.
This is exactly the category of quiet, configuration-level failure that continuous checking is built for, and it is what we watch for as part of the monitoring described on our start here page. To be clear about scope: monitoring a redirect rule is a narrow, specific check, not a full technical audit of your site. But narrow checks on foundational rules are disproportionately valuable, because foundational rules fail silently and stay failed.
Choose one address. Redirect the rest. Verify it with your own browser today, and have something verify it on the days you are not looking.