www vs non-www: pick one hostname, then make five places agree

www vs non-www is a decision about which hostname is your site, and it has to be made once and then enforced in five places. Google has never published anything saying either form ranks better, and neither has anyone else with data. What is documented is narrower and more useful: the two hostnames are separate scopes for robots.txt, separate properties in Search Console, and duplicate URLs until a redirect tells Google which one you meant.

Before you start

You need DNS access and the ability to configure a redirect at your host or CDN. This chapter is about picking one hostname for a single site. The neighbouring decision — whether a section of content belongs on its own subdomain or in a folder — is a different question with different tradeoffs, worked through in subdomain vs subfolder. If you already have a working redirect and only want to check it, skip to the deliverable.

Why two hostnames are two sites until you say otherwise

A crawler resolves a hostname. It does not know that example.com and www.example.com belong to the same company, and nothing in the protocol tells it. Three documented consequences follow, and only the third is about ranking at all.

The first is robots.txt, and it is the sharpest. Google states that "the rules listed in the robots.txt file apply only to the host, protocol, and port number where the robots.txt file is hosted", and gives the exact case in its own table: a robots.txt at https://www.example.com/robots.txt is valid for https://www.example.com/ and not valid for https://example.com/ (robots.txt specifications, Google Search Central, read 2026-09-07). Serve your rules on one hostname and the other hostname has no rules.

The second is Search Console. A URL-prefix property "includes only URLs with the specified prefix, including the protocol (http/https)", while a Domain property "includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp)" (Search Console property types, read 2026-09-07). A URL-prefix property on the www form will not report on the apex form. If your data looks thin, check which hostname the property covers before concluding anything about the site.

The third is canonicalization. Google defines a canonical URL as "the URL of a page that Google chose as the most representative from a set of duplicate pages", and lists what feeds that choice: "whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations" (Canonicalization, read 2026-09-07). Two hostnames serving identical pages is a set of duplicates, and Google will pick one whether or not you expressed a preference.

Picking a hostname is not an SEO decision. Failing to enforce the pick is.

How to decide www vs non-www

The choice itself is low-stakes and mostly operational. Run down this table, take the first row that applies to you, and stop.

Check the DNS row before you commit, because it can decide the question for you. Some providers will not let an apex domain point at a hostname the way a subdomain can, and offer a provider-specific alias record instead. Confirm what yours supports rather than assuming.

Do it: enforce the pick in five places

Five steps. Each has a finish line you can verify the same day, and step two is the one that carries the signal.

1. Write down the winner as a full origin, protocol included — https://www.example.com or https://example.com. Finish line: one string, written down, that every later step compares against.
2. Redirect the loser to the winner with a permanent redirect, preserving the path. Not just the homepage: /pricing on the loser must land on /pricing on the winner. Finish line: a request to the loser's homepage and to one deep path both return a redirect to the matching path.
3. Make every page's rel="canonical" use the winner's hostname. Finish line: fetch three pages and confirm the canonical hostname matches the string from step one.
4. Point the sitemap, and every URL inside it, at the winner. Finish line: no address in the sitemap uses the losing hostname.
5. Add the winner in Search Console — a Domain property if you can verify by DNS, since it covers both hostnames at once. Finish line: the property reports data for the hostname you picked.

Internal links deserve a mention here even though they are not a separate step. Absolute internal links written with the losing hostname send every reader and every crawler through a redirect they did not need. Relative links, or absolute links using the winner, avoid it.

Deliverable: the four-line check and the consistency table

Run this against your own domain. It tests the redirect in both directions and prints the canonical, which is the pair of facts that decides whether the pick is enforced.

# Replace example.com with your domain.
D=example.com

# 1. Which way does each hostname resolve? Look for one 301 and one 200.
curl -sI  "https://$D/"      | head -n 1
curl -sI  "https://www.$D/"  | head -n 1

# 2. Does a deep path keep its path across the redirect?
curl -sI  "https://www.$D/pricing" | grep -i '^location:'

# 3. What hostname does the page claim as canonical?
curl -sL  "https://$D/" | grep -o '<link[^>]*rel="canonical"[^>]*>'

Then confirm the same hostname appears in all six places below. A mismatch in any one row is the whole bug — there is no partial credit, because each row is read by something different.

Two of those rows are stronger than the others, and Google says so directly. A redirect is "a strong signal that the target of the redirect should become canonical", and a rel="canonical" annotation is "a strong signal that the specified URL should become canonical", while sitemap inclusion is only "a weak signal" (Consolidate duplicate URLs, read 2026-09-07). The same page adds that "these methods can stack and thus become more effective when combined", which is the reason to do all six rows rather than the strongest one alone.

Three ways this goes wrong

The first is a redirect that drops the path. A rule that sends every request on the losing hostname to the winner's homepage looks like it works, because the homepage test passes. Every deep link ever published then lands on the homepage instead of the page it named. Test one deep path, not the root.

The second is a redirect chain. The losing hostname goes to HTTP on the winner, which then goes to HTTPS, so a single request becomes three. Each hop is a fetch. Configure the rule so that hostname and protocol are fixed in one hop, then confirm by watching the redirect chain rather than the final status code.

The third is a canonical tag that disagrees with the redirect. The redirect points at the www form while the tag names the apex, and the two strongest signals in the list are pulling against each other. Google is explicit that "indicating a canonical preference is a hint, not a rule" — it decides, and when your own signals conflict it may not decide the way you assumed.

Where this stops

Three limits, and the first one matters most because the internet is full of confident claims about it.

1. No Google documentation says either hostname form ranks better, and we have not run a test that isolates the variable. It is not testable on a live site — you would need two identical sites differing only in hostname. Anyone quoting you a ranking benefit for www or for the apex is not citing anything.
2. This chapter covers hostname consolidation, not protocol. Serving both HTTP and HTTPS creates the same duplication a layer down, and Google lists the protocol among canonicalization factors. Fix HTTPS first if it is not already forced.
3. Consolidating does not merge history. The losing hostname's indexed pages are re-processed over time, and the report to watch for that is a different tool with a different job.

One thing worth confirming before any of this: that a crawler can reach the winning hostname at all. A redirect to a hostname that a firewall or CDN rule refuses is a worse outcome than the duplication you started with, which is what the AI crawler access check is for. Once the hostname is settled, the per-URL version of the same question — which of several addresses for one page should win — is how to use canonical tags. And the property you create in step five is set up in Search Console verification.

Common questions

Is www or non-www better for SEO?

Neither, as far as any published Google documentation goes. The difference that is documented is scope: separate robots.txt scopes, separate Search Console URL-prefix properties, and duplicate URLs until a redirect resolves them. Pick on operational grounds and enforce the pick.

Do www and non-www count as separate websites?

For robots.txt, yes, explicitly — rules apply only to the host where the file is served, and Google's own example marks a www robots.txt as not valid for the apex. For Search Console URL-prefix properties, also yes. For indexing they are duplicates that Google will consolidate onto one canonical, which it chooses if you do not tell it.

Which redirect should I use for www to non-www?

A permanent one, preserving the path, in a single hop. Google describes a redirect as a strong signal that the target should become canonical, so this is the piece of the setup that does most of the work.

Will changing from www to non-www hurt my rankings?

We cannot tell you a number, and neither can anyone else without a controlled test that is not possible on a live site. What we can say is that changing hostnames is a migration with real work in it and no documented upside, so if a redirect already works in one direction, the safer answer is to leave it.

Do I need both hostnames in Search Console?

Not if you use a Domain property, which by Google's definition includes all subdomains and multiple protocols. With URL-prefix properties you would need one per hostname and protocol, since such a property includes only URLs with that exact prefix.