www or No www? Pick One, Redirect the Rest

Every site can be reached at up to four addresses before anyone touches a setting:

http://example.com
http://www.example.com
https://example.com
https://www.example.com

To a person these are one website. To a search engine they are four, and if all four return content you have published your entire site four times over.

The fix is to pick one and permanently redirect the other three to it. Which one you pick matters much less than people think.

The choice

www is a subdomain, which brings two mildly useful technical properties. You can point it at a CDN with a CNAME record, which the bare apex domain cannot always do cleanly. And cookies set on www.example.com are not automatically sent to every other subdomain, which matters if you run static.example.com or api.example.com and would rather not attach cookies to every asset request.

No www is shorter and looks cleaner in print and in a browser bar. Modern DNS providers largely solve the apex CNAME problem with flattening or ALIAS records, so the technical argument against it has mostly evaporated.

There is no SEO difference. Google has said so repeatedly. Pick whichever you prefer, and then be consistent about it forever, because changing later means redirecting every URL on the site and waiting for the index to catch up.

The one thing that is not optional is HTTPS. That part is settled.

What has to be consistent

Choosing is the easy half. The work is making every part of the site agree.

• Redirects. The three variants must return a permanent redirect to the one you chose. 301 or 308, never 302 or 307.
• Canonical tags. Every page’s <link rel="canonical"> must use the chosen host.
• Sitemap. Every <loc> entry must use the chosen host, and the sitemap should list only the canonical version of each page.
• robots.txt. The Sitemap: line should point at the canonical host.
• Internal links. Use root-relative paths like /blog/ rather than absolute URLs, and the problem cannot arise.
• Structured data. Any URLs inside your JSON-LD, including breadcrumbs and organisation markup.
• Open Graph tags. og:url should match the canonical.

The quickest way to audit this is to search your built output for your domain and check that every occurrence uses the same host. If you find even a handful of the wrong variant, that is where mixed signals come from.

Why Search Console reports the others as redirects

This is where people get alarmed unnecessarily.

Open Search Console, look at Page indexing, and you will very likely find a category called Page with redirect containing your other three host variants. It looks like a problem because it sits in a report alongside genuine errors.

It is not a problem. It is the report telling you the redirects exist and are working.

Google knows about those URLs because they are the obvious variants of your domain, or because someone linked to one, or because they were crawled before you configured anything. When Google fetches them and receives a permanent redirect, it records exactly that: this URL redirects, so it is not indexed in its own right, and the destination is.

That is the intended outcome. If those URLs were not in that report, it would mean either that Google had never tried them, or worse, that they were returning content.

The categories in Page indexing worth actually worrying about are different ones: Server error, Not found (404) for pages that should exist, Excluded by ‘noindex’ tag on pages you want indexed, and Duplicate without user-selected canonical. Those describe things going wrong. “Page with redirect” for host variants describes a correctly configured site.

Permanent, not temporary

The status code matters more than most other details here.

301 Moved Permanently and 308 Permanent Redirect both tell search engines the move is permanent, so ranking signals should transfer to the destination and the old URL should drop out of the index. The difference between them is only that 308 preserves the HTTP method, which is irrelevant for ordinary page requests.

302 Found and 307 Temporary Redirect say the original URL is still the real one and will be back. Search engines then keep the original in the index and may not consolidate signals onto the destination.

Many hosting platforms issue 308 by default for host redirects, which is correct. Check yours rather than assuming.

Checking it yourself

From a terminal, follow each variant and watch the chain:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/

Run it for all four variants. You want each of the three non-canonical ones to end at your chosen URL with a permanent status, and the canonical one to return 200 with no redirects at all.

One detail that surprises people: http://example.com often takes two hops rather than one, first upgrading to HTTPS and then moving to the canonical host. That is normal on most platforms, because the HTTPS upgrade happens at the edge before any of your own rules run. Two hops is well within what search engines follow, and it is usually not worth trying to eliminate.

Do not chain redirects unnecessarily

Elsewhere on the site, redirect chains are worth avoiding.

If you move a page twice, update the first redirect to point straight at the final destination rather than leaving /old to /newer to /newest. Each hop adds latency for users, and long chains eventually get abandoned by crawlers.

The same applies to trailing slashes. Decide whether your URLs end in a slash, be consistent, and make sure the wrong form redirects in one hop rather than bouncing between forms.

The short version

Pick www or don’t. Force HTTPS. Permanently redirect the other three variants. Make your canonicals, sitemap, robots.txt and internal links all use the same host.

Then, when Search Console reports those variants under “Page with redirect”, recognise it as confirmation rather than a fault, and go and look at the categories that describe actual problems instead.