Both www and non-www answer

Ranking signals. Links pointing at one hostname do not count towards the other, so a page's authority is divided rather than combined.

Crawl budget, since a crawler discovering both sets fetches every page twice.

Analytics, where sessions crossing from one hostname to the other are recorded as two visits with a referral between them.

Cookies, which are scoped by hostname and do not automatically transfer — a session started on one can be absent on the other.

Caching, where a CDN keys by hostname and therefore stores and serves two copies of everything.

It genuinely does not matter for ranking. Both are fine and neither carries an advantage.

The www hostname allows a CNAME at that name, which is how most managed platforms prefer to be pointed at — the bare domain cannot carry one alongside its other records.

The bare domain is shorter and reads better, which is a real consideration and the reason most consumer sites choose it.

Cookie scope differs: a cookie set on the bare domain is sent to every subdomain, while one set on the www hostname is not by default.

Whichever is chosen, the decision is worth writing down, because the cost is in changing it later rather than in the choice.

Trailing slashes: a page answering at both the version with and without a trailing slash is two URLs for one page.

Letter case: a path answering at both an upper-case and a lower-case spelling, which happens on case-insensitive servers.

Index filenames: a directory answering both at its path and at an explicit index file name.

Query parameters that change nothing, which multiply the count further — campaign tags being the common case.

Each of these divides the same signals for the same reason, and each is resolved the same way: one canonical form, a permanent redirect for the rest.

Choose the canonical hostname and redirect the other with a 301, preserving path and query string.

Do it at the edge or the web server rather than in the application, so it applies before any routing.

Update internal links to the canonical form, since every redirected request is a wasted round trip.

Update canonical tags, the sitemap and any hreflang annotations to the canonical hostname, so all of them agree.

Update the property in any search console tooling and in analytics, or the historical data will appear to end.

A canonical tag is a hint that search engines usually honour and sometimes do not.

It does nothing for visitors, who stay on whichever hostname they arrived at, with whichever cookies that hostname holds.

It does nothing for a CDN, which still caches two copies.

It does nothing for analytics, which still records two hostnames.

So a canonical tag is a useful second layer and a poor substitute for the redirect.

`curl -I https://example.com` and `curl -I https://www.example.com` — one should redirect to the other.

Test a deep path on both, since a rule that redirects the home page and not the rest is common.

Check the HTTP versions of both hostnames too, which is four combinations in total and frequently only two are configured.

Try a path with a trailing slash and without, and with mixed case, to see whether the same problem exists in those shapes.

Confirm the certificate covers both hostnames, since the redirect from one to the other happens after the handshake.

`transport.canonical_host` reports whether the www and non-www variants resolve to one canonical form, which is this problem directly.

`structure.url_consistency` compares scheme, host variant, trailing slash, case and parameters across the URLs really fetched.

`seo.canonical` reports the canonical tags, which is the second layer rather than the fix.

`structure.duplicate_content` reports pages whose normalised text matches, which is the downstream consequence.

`transport.certificate_coverage` reports whether the certificate covers both hostnames, since a redirect from an uncovered name fails before it runs.