www or non-www? Check your domain
It doesn't matter which one you pick — only that one redirects to the other. If both answer, search engines see two identical sites and split your ranking signals between them.
Free, no signup. Usually answers in under a second.
The short version
Pick one. Redirect the other to it. That's the whole task.
There is no SEO advantage to either. Not to www, not to the bare domain. Anyone telling you otherwise is selling something. The only mistake is picking neither and leaving both live, which is what a surprising number of otherwise well-run sites do.
If you want a recommendation: use the bare domain
Redirect www.example.com to example.com. Not because it ranks better — it doesn't — but because it puts the redirect on the host that is easy to point somewhere.
www is an ordinary subdomain, so it can be sent anywhere with a plain CNAME record. Every DNS provider on earth supports that, and it takes one record.
The apex — example.com with nothing in front of it — is the awkward one. The DNS specification forbids CNAME records there, so providers each invented their own workaround: ALIAS at one, ANAME at another, CNAME flattening at a third, a bare A record you have to maintain by hand at a fourth. Choosing the bare domain as your canonical means you never have to care which camp your provider is in, because the apex just keeps serving your site as it already does.
Same SEO outcome either way. Far less that can go wrong.
A CNAME is not a redirect
This is the one that catches people, and it is worth being blunt about: pointing www at your apex with a CNAME does not redirect anything.
A CNAME is an address. It says “www lives at the same place as the apex” — so www starts serving your site. It does not send the visitor anywhere. The browser URL stays www.example.com, both hostnames return 200, and you have built exactly the duplicate this page is about. This tool will flag it, and it will be right to.
DNS cannot redirect. There is no record type that does it. Redirecting is an HTTP behaviour — something has to receive the request on www and answer with a 301 and a Location header pointing at the apex. DNS only decides which machine receives the request in the first place.
So “I pointed www at my site” and “I redirect www to my site” are different things, and only the second one solves this. What you CNAME www at has to be something that returns a redirect.
Why leaving both live costs you
To a search engine, example.com and www.example.com are two different addresses. If both serve your site and neither points at the other, you haven't built one site — you've built two identical ones.
The cost is quiet and cumulative. Every inbound link picks one version or the other, so the authority you earn is divided rather than pooled. Both copies get crawled, spending your crawl budget twice on the same content. And search engines have to guess which version to rank, which puts the choice out of your hands and lets it change over time.
Nothing appears broken while this happens. Both addresses load fine. That is exactly why it survives for years on sites that are otherwise carefully maintained — there is no error to notice.
What this tool checks
It requests your domain and its counterpart — the www version if you gave the bare domain, or the bare domain if you gave www — and compares what each one does:
- One redirects to the other. Correct, in either direction. Nothing to fix.
- Both serve content, with no canonical tag. Genuine duplicate content. This is the case worth fixing.
- Both serve content, but agree on a canonical. We read the
rel="canonical"tag from both pages and compare them. If they point at the same URL, search engines consolidate the two, and we say so rather than calling it a problem. - The counterpart doesn't resolve or errors. No duplicate exists, so nothing is splitting your signals.
Why we read the canonical tag
Because skipping it produces false alarms. Running this check across a sample of local business sites, six served pages on both hosts — but three of those declared a consistent canonical URL on both, which search engines honour. Reporting all six as broken would have been wrong about half of them.
A canonical is still weaker than a redirect. Google treats it as a strong hint rather than an instruction, and both copies keep getting crawled either way. So we report it honestly: you're not in trouble, and a 301 would be better.
Fixing it without touching a server
The redirect itself is one rule. The awkward part has never been the rule — it's where to put it. On a traditional host that means .htaccess, an nginx block, or a platform-specific redirects file, and it means a deploy every time you touch it.
RedirectIQ hosts it instead. Point your www CNAME at us rather than at your apex — that is the distinction from the section above — and we answer those requests with a real path-preserving 301 to your bare domain. Live globally in seconds, nothing to deploy, no server config, and the apex keeps serving your site exactly as it does today. That is the whole change.
Custom domains are $1/mo, or you can try it free on a subdomain we host first.
Common questions
Should I use www or non-www?
It genuinely does not matter which one you pick. Neither is better for SEO, neither is faster, and Google has said so for years. What matters is that you pick one and redirect the other to it. A site that answers on both without redirecting has a real problem; which version you chose is not it.
Which one do you recommend?
The bare domain (example.com), for a purely practical reason: it makes www the host that does the redirecting, and www is a subdomain, so it can be pointed anywhere with an ordinary CNAME record that every DNS provider supports. The reverse means putting a redirect on the apex, where the DNS spec forbids CNAME records and providers each invent their own workaround — ALIAS, ANAME, CNAME flattening, or nothing at all. Same SEO outcome, far less that can go wrong.
Can I just CNAME www to my apex domain?
No — and this is the single most common way sites end up with duplicate content while believing they fixed it. A CNAME is an address, not an instruction. Pointing www.example.com at example.com makes www serve the same site; it does not send anyone anywhere. The browser URL stays www.example.com, both hostnames return 200, and search engines see two identical sites. DNS has no concept of a redirect at all — only HTTP does, via a 301 status code. Something has to actually answer the request on www and return that 301. This tool will flag a CNAME-only setup as duplicate content, correctly.
Is a canonical tag enough, or do I need a redirect?
A canonical tag usually works, and this tool reports when it finds one rather than calling your site broken. But it is a hint rather than a directive — Google can and sometimes does ignore it — while a 301 is unambiguous. A redirect also stops both copies being crawled, which a canonical does not. If you already have consistent canonicals you are not in trouble; a 301 is simply stronger.
My homepage redirects correctly. Am I fine?
Not necessarily, and this is the most common version of the problem. Plenty of sites canonicalise the homepage and leave deep pages answering on both hosts, which is where the actual content and links are. Check a product or article URL, not just the root.
Does the redirect need to preserve the path?
Yes, and this is the detail most often got wrong. A request for www.example.com/products/blue-widget should land on example.com/products/blue-widget, not on the homepage. Redirecting everything to the root throws away exactly the link equity you are trying to consolidate, and it is worse for visitors, who wanted a specific page.
What about http vs https?
Same principle, separate problem — https://example.com and http://example.com are also distinct URLs to a search engine. Most hosts handle the https upgrade automatically now, but the redirect should land in a single hop rather than chaining http to https to www, since each extra hop costs latency.