www vs non-www: does it still matter?
No, it barely matters which one you choose — and yes, you still have to choose one. That is what every result on page one for this question says, and it is correct. None of them counts how many sites actually still have two live copies, so we did.
In a random sample of 300 hosts drawn from the Tranco top 10,000 and probed on 15 September 2026, 21 still served the site on both spellings — 7.0% of the sample, 9.1% of the 232 origins that answered at all, 12.3% of the 171 whose other spelling returned a 2xx. Three different denominators, three different numbers, and they are not interchangeable.
Most of the web has already settled it: 150 of 232 reachable origins — 64.7% — redirected one spelling onto the other. The advice is not wrong. It is just aimed at a minority now, and nobody had said how small a minority.
Nine pages agree with each other. None of them counted.
Search this question and you get nine results that say the same three things: search engines have handled it for years, it is a duplicate-content problem rather than a ranking-factor problem, pick one spelling and redirect the other. That advice is sound and this page does not argue with it.
What is missing from all nine is the number that decides whether you need to act. "Sites that get this wrong split their signals" is a mechanism, not a measurement. It tells you what happens to a site in that state; it does not tell you whether yours is likely to be one, or whether the problem is still a live one in September 2026 at all. So we measured the incidence instead of restating the mechanism.
What we measured, and on how many hosts
Start with the size, because it governs everything below: 300 hosts. A random sample of the Tranco top 10,000, drawn with a recorded seed, two requests per host, no page crawl. This is a sample, not a survey — it is small enough that a reader should treat every share here as an indication rather than a census, and every figure on this page is published with the denominator it came from.
For each host the probe does two things in order, and the order is the whole measurement:
- Fetch the host and follow redirects to find the site's final origin. Whichever spelling the site actually settled on, that is now the canonical host.
- Fetch the opposite spelling of that origin and see where it lands.
This replicates the check Docket ships rather than approximating it. The audit engine runs the same logic against your own site, and it deliberately does not ask the naive question "do both spellings return 200?", because that question produces false findings on real servers.
Four outcomes, and only one of them is a defect
| What the other spelling did | Hosts | Is it a problem? |
|---|---|---|
| Did not resolve at all | 14 | No. There is no second hostname, so there is nothing to canonicalise. |
| Answered, but not with the site — 404, 403 or another non-2xx | 47 | No. A 404 on the other spelling is the correct configuration, and a 403 is usually a bot block. Neither is a second copy of anything. |
| Answered 2xx and landed back on the canonical host | 150 | No. This is the resolved state the advice asks for. |
| Answered 2xx and did not land back on the canonical host | 21 | Yes. Two hostnames are serving the site. |
| Reachable origins | 232 |
The second row is the one that separates a real check from a naive one, and Docket learned it the expensive way. An independent-bookshop marketplace answers 403 to everything automated. Both spellings returned 403, neither redirected to the other, and the tool reported a duplicate-content finding at high severity. There was no duplicate. There were two bot-block pages. A search engine sees no second copy of that site, because there is no second copy — there is a door that is shut on both names.
So a non-2xx on the other spelling is scored as fine here, not as a failure and not as a pass we are quietly proud of. Those 47 hosts are still counted among the 232 reachable ones; they are simply outside the 171-host denominator, because you cannot serve a second copy of a page you did not serve.
The first run was wrong by a factor of 7.0, and the reason is the useful part
The first version of this probe reported 49.3% of sites serving both spellings — roughly half the web, which should have been unbelievable on its face. The shipped figure is 7.0% of the sample. One missing fetch, 7.0 times the answer.
The bug: it compared the www spelling against the apex it started from
instead of resolving the site's final origin first. Consider a site correctly canonicalised on
www. The probe requested the apex, got redirected to www, then requested
www, got a 200, observed that this 200 was not the apex it had started at — and scored a
perfectly configured site as a duplicate. Every site that chose www failed. That is a
large fraction of the web, which is exactly why the wrong number looked like half of it.
This is written out at length because it is the mistake a reader running their own check will make. The instinctive test is "curl both, compare". The instinctive test is wrong, and it is wrong in the direction that manufactures work for you. Resolve the final origin first. Everything after that is easy.
What this measurement does not say
The limits below are not formalities, and a reader who skips them will over-read every figure above:
- 68 of the 300 sampled origins — 22.7% — never answered an identified bot at all. They are excluded: not counted as pass, not counted as fail. That is a real hole in the denominator, and if hosts that refuse identified bots differ systematically from hosts that do not, every share above is drawn from a population that is not quite the web. For scale, a separate robots.txt survey of the whole Tranco top 10,000 in August 2026 found 2,332 of 10,000 hosts — 23.3% — unreachable to the same kind of identified request. Same list, different month, a different request, and the same rough fifth. That suggests the unreachable share is a property of asking as a named bot rather than an accident of a 300-host draw; it does not make those hosts' configuration knowable.
- The list is not the web either. The Tranco top 10,000 is a rank-aggregated list of busy hostnames, and it contains CDN and infrastructure hostnames that are not websites at all. A hostname with no site on it can still redirect, or not, and it is counted here the same as a publisher.
- We did not measure consequences. Nothing here says a site serving both spellings lost rankings, traffic or anything else. It says two hostnames both serve the site. The harm is a well-described mechanism, not something this probe observed, and we are not going to dress a hostname count up as a traffic study.
- This is one request pair per host, at one moment. A site can behave differently by geography, by CDN node, or on a different day. A host that redirected cleanly for us may not for a visitor routed through another edge.
- We did not record which spelling sites choose. The probe stored whether
a redirect happened, never which way round it resolved, so this page cannot tell you whether the web
prefers
wwwor the bare apex. That is a different measurement and we have not taken it. Anyone quoting a split in that direction is not quoting us.
The whole dataset behind this page — every count, the sampling frame, the method, and the note explaining the first run's error — is published as www-canonical-2026-09.json. Host names are not in it: publishing a named site's misconfiguration to sell a tool is not a trade this project makes.
Run the same two requests on your own site
You need a terminal and about thirty seconds. Resolve the final origin first — that is the step the broken run skipped:
curl -sS -L -D - -o /dev/null https://example.com/ \
| grep -iE '^(HTTP/|location:)'That prints the status line and Location header of every hop and throws the bodies
away. Read the hostname off the last hop: that is your canonical origin, whichever spelling it turned
out to be. Now ask the opposite spelling where it lands, using the same command:
curl -sS -L -D - -o /dev/null https://www.example.com/ \
| grep -iE '^(HTTP/|location:)'Match the result against the table above. If the last hop is a 2xx on your canonical origin, you are done. If the last hop is a 2xx on any other hostname — including the case where it lands on some third hostname entirely — you have two copies. If the other spelling 404s, does not resolve, or answers 403, you have nothing to fix.
Use a real GET rather than curl -I. A HEAD request is a different request, and servers
and CDNs are entitled to answer it differently from the GET a search engine will actually send.
Do it with a path attached as well, not just the homepage. A redirect that sends every URL to the homepage of the other spelling is a different and worse bug than no redirect at all, and a homepage-only test cannot see it.
If you are in the minority, the fix is one rule
A site-wide 301 from the spelling you are not keeping to the one you are, preserving the path and query string. Not a 302, which asks search engines to keep both in play. Not a homepage redirect, which throws away every deep link pointing at the losing spelling. One rule, at the server or CDN, applied to everything.
Which spelling you keep does not matter for search. It matters for cookies, for certificate coverage and for what your existing links already say, so the honest tiebreak is "whichever one most of your inbound links and your existing configuration already point at". Then make everything else agree with it: internal links, sitemap entries, canonical tags and the address in your analytics.
Two adjacent jobs are worth doing in the same sitting. Your TLS certificate has to cover both names even after you pick one, because the losing spelling still has to complete a handshake before it can serve your redirect — that is covered in redirecting HTTP to HTTPS. And if your pages already carry canonical tags, they now need to name the spelling you kept; conflicting canonical tags is the failure mode where half your templates were updated and half were not.
Where this sits next to canonical tags
It is tempting to reach for rel="canonical" here, and that is the wrong tool.
Canonical tags deliberately leaves apex-versus-www alone: it is a
server configuration, not a markup mistake, and a tag asking politely for one hostname while the server
happily serves both is a weaker instruction than a redirect that makes the second hostname stop
existing. Fix it at the server. The tag is for the duplicates a server cannot resolve.
Docket checks this on every audit as part of the crawl setup rather than as a page-level rule — the full list of what it looks at is in what Docket checks, and what an SEO audit is covers where a hostname check sits among the rest. The August 2026 survey quoted above for the unreachable share is published in full in the AI directives index.
Common questions
Does www vs non-www still matter for SEO?
Only if you have not picked one, and most sites have. In a random sample of 300 hosts from the Tranco top 10,000 probed on 15 September 2026, 150 of the 232 origins that answered — 64.7% — already redirected one spelling onto the other. Just 21 served the site on both spellings: 7.0% of the sample, 9.1% of reachable origins, 12.3% of the 171 whose other spelling returned a 2xx. It is a real defect and it is an uncommon one.
How do I check whether my own site serves both?
Two requests, in this order. First fetch your site and follow redirects to find its final origin — that is your canonical hostname, whichever spelling it turned out to be. Then fetch the opposite spelling of that origin and see where it lands. A 2xx that ends up back on your canonical host is fine. A 2xx that ends up anywhere else, including a third hostname, means two copies. Skipping the first fetch is the mistake that made our own first run report 49.3% instead of 7.0%.
My other spelling returns a 403 or a 404. Is that a problem?
No, and treating it as one is a common false positive. A 404 on the spelling you are not using is the correct configuration, and a 403 is usually a bot block rather than a page. Two bot-block responses are not duplicate content. Docket learned this from an independent-bookshop marketplace that answers 403 to everything automated: both spellings returned 403 and the tool wrongly reported a duplicate. In the sample, 47 of 232 reachable origins answered non-2xx on the other spelling and are scored as fine.
Should I use a canonical tag or a redirect?
A redirect. A site-wide 301 from the spelling you are dropping to the one you are keeping, preserving the path and query string — not a 302, and not a redirect that sends everything to the homepage. A canonical tag asks politely for one hostname while your server carries on serving both; a 301 makes the second hostname stop serving. Docket's canonical checks deliberately leave apex-versus-www alone for that reason: it is a server configuration rather than a markup mistake.
Do more sites use www or the bare apex?
We do not know, and this page will not guess. The probe recorded whether a redirect happened, not which direction it resolved, so the 150 redirecting origins out of 232 reachable ones are not split by spelling anywhere in the data. It is a measurement we have not taken. Separately, 68 of the 300 sampled hosts — 22.7% — never answered an identified bot at all and are excluded from every figure here, which is a real limit on all of them.