If your site is reachable at both www.yoursite.com and yoursite.com without one version redirecting to the other, search engines can index both as separate sites showing identical content, splitting your ranking signal in two rather than consolidating it behind a single, authoritative version.
Check whether both www and non-www versions load without redirecting
Type your domain into a browser both with and without “www.” in front. If both load your site directly, with no redirect from one to the other, that confirms the issue — a correctly configured site should send one version to the other automatically.
www / non-www canonicalization
www and non-www both loading independently, redirected to one preferred version.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Both www and non-www versions of your domain load without redirecting to a single, preferred one | This fix covers it |
| The issue is trailing slash inconsistency, not www versus non-www | Trailing slash inconsistency fix |
| You want a broader duplicate content and canonical strategy, not just this specific case | Duplicate content & canonical strategy implementation |
| Your SSL certificate doesn’t cover one of the two versions correctly | Worth checking SSL/TLS configuration grade improvement alongside this |
What you are seeing
- Both www and non-www versions of your domain loading the same content without redirecting
- Search Console potentially showing both as separately verified or indexed properties
- Inconsistent use of www or non-www in internal links or marketing materials
- SSL certificate coverage possibly not matching consistently across both versions
Common causes
- DNS configured to resolve both versions without a corresponding redirect rule in place
- A migration or hosting change that removed a previously working canonicalization rule
- The site never having had this explicitly configured since launch
- A CDN or caching layer serving both versions independently without enforcing one
- An SSL certificate originally issued for only one version, later expanded to cover both without anyone revisiting the redirect rule
What we do
- Confirm your preferred canonical version (with or without www)
- Implement a server or DNS-level redirect enforcing that single, consistent version
- Update internal links and references to use the preferred version consistently
- Verify the redirect works correctly across both entry points
- Confirm SSL certificate coverage is correct for the preferred version
- Check Search Console for any resulting property configuration needed
What is included
- A single, enforced canonical version between www and non-www
- Verified, tested redirect behaviour
- Internal links updated to the preferred version
- A written note on the configuration
Not included
- Trailing slash inconsistency, a separate, related fix
- SSL certificate issues beyond confirming coverage for the preferred version, a separate fix if a deeper problem exists
- A broader canonical strategy across other duplicate content types
- Ongoing monitoring as DNS or hosting configuration changes
Questions about this fix
Which version should I choose, www or non-www?
Neither is inherently better — what matters is picking one and consistently enforcing it; if you already have an established preference or existing backlinks favouring one, that's usually the sensible choice.
How is this different from a general canonical tag issue?
This is specifically about DNS and redirect-level handling of the two domain variants, which is a more fundamental, structural fix than a page-by-page canonical tag correction, though the underlying goal of consolidating signal is the same.
Will switching my preferred version this late cause any disruption?
If you're switching an established preference (not just fixing a lack of any redirect), there can be a brief adjustment period as search engines recognise the change, though a properly implemented redirect minimises this.
Does this affect my email or other services tied to the domain?
Generally no — this specifically addresses web traffic redirection, and shouldn't affect email or other services unless they're specifically configured to depend on one version's exact URL.
How would I know if my SSL certificate covers both versions correctly?
We check this as part of the fix, since a mismatch (a certificate valid for one version but not the other) can produce security warnings for visitors landing on the non-covered version before the redirect takes effect.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.