www vs non-www: pick one and redirect

Symptoms

• Multiple versions of the same pages appear in results: https://example.com/page and https://www.example.com/page.
• The search console reports the site under both hosts, splitting page and link data.
• The brand shows as two separate "sites", and internal links point to a mixture of the two hosts.

A shortcut for what is happening:

Why this happens

The leading www is a regular third-level host label, not part of the domain name. www.example.com and example.com are separate hosts that can answer independently. If both respond with the same content, search engines see two copies of every page, which splits signals and can be labelled a duplicate content set. The fix is host choice plus a redirect of one host onto the other. See duplicate content and canonical conflicts.

Choosing a host

There is no SEO winner between www and non-www; search engines treat them as equivalent once one redirects to the other. Pick whichever is easier to maintain.

• Cookies: a bare domain sets cookies for every subdomain, which can matter if you run third-party subdomains that should not receive them; www scopes cookies to its own host.
• CDN and reverse proxies: some platforms make it simpler to manage TLS and host rules for one host, so pick the one your edge config favours.
• Brand text: consistency with printed URLs and marketing matters, but it is cosmetic. Either host is fine if it redirects reliably.

Decide once, write it down, and make every internal link use the chosen host so the redirect is not the path you rely on everywhere.

How to fix (ordered)

1. Pick the preferred host, then move all internal site links and the sitemap to that host, so the chosen form is the canonical URL.
2. Add a 301 from the non-preferred host to the preferred host at the server or CDN layer, covering the whole host, not page by page.
3. Ensure HTTP and HTTPS both resolve: redirect http:// to https:// on the same host choice, and confirm the https form of the non-preferred host also redirects to the preferred https URL. See HTTP to HTTPS redirect.
4. Make the redirect authoritative and keep the canonical on the chosen host; the search engine then consolidates properties and link data onto the surviving host, with no legacy preferred-domain setting needed.
5. Make sure the canonical on every page uses the chosen host, so no page references the retired host. See canonical tags explained.
6. Verify with a fetch that shows headers: the non-preferred host returns 301, its Location points at the chosen host, and that host returns 200.

Edge cases

• HTTPS certificate coverage: use a certificate that covers both hosts, or the redirect itself may throw a certificate warning on the non-preferred host.
• CDN and proxy rules: implement the host redirect at the edge that actually terminates requests, not only in the origin, or requests that never reach origin stay unredirected.
• Cookie scope: if you drop www, confirm third-party subdomains are not receiving bare-domain cookies they do not need.
• Old bookmarks and links to the retired host still work, because that host now resolves through the redirect; keep the redirect in place long term, do not remove it.

Prevention

• Decide the host once and record it in the deploy config.
• Add the redirect at the edge so it survives origin restarts.
• Keep the chosen host in canonicals and internal links so the redirect is a safety net, not the only path.

The redirect mechanics behind a healthy host move are detailed in HTTP 301 redirects that preserve rankings.