EnglishOne Domain, Four Entry Points: Which Address a Site Really Answers From
Contents
A domain is one thing to its owner and four things to the network. With www and without, encrypted and not, each combination is a separate address that a server may answer, refuse or forward. Nothing forces them to agree.
Whether they do decides how search engines count the site, how many round trips a visitor pays before content appears, and whether a certificate covers what people actually type.
Four addresses, one site
To a browser, http://example.com and https://www.example.com have nothing in common beyond a shared owner. Different scheme, different host name, different origin. Cookies set on one are not sent to the other, and content served under both is content served twice.
Search engines resolve this by picking a canonical address, but the picking is a guess when the site does not say. A site that answers under all four addresses with the same pages splits its inbound links across them: some point at the bare domain, some at www, and neither version accumulates the full signal.
The fix is not to pick the right one. It is to pick any one and make the other three lead there.
What converging means
Converging means every entry point ends at the same final address, and ends there permanently. Three details decide whether it works.
The scheme comes first: the unencrypted entry points must forward to https, and with a 301 rather than a 302, so that browsers and search engines treat the encrypted version as the address.
The host form comes second: whichever of www and the bare domain is chosen, the other forwards to it. Choosing is a matter of taste with one technical consequence, namely that cookies set on a bare domain are sent to every subdomain, while cookies on a www host are not.
And the certificate has to carry both names. A redirect from a host the certificate does not cover fails before the redirect is ever read: the handshake breaks first, and the visitor gets a warning page rather than a forward.
Forty-eight entry points, measured
Twelve well-known domains were followed on 2 September 2026, each through all four entry points, hop by hop, without letting any client merge the steps.
Nine of the twelve converged: all four entry points ended at one address. Six of those chose the www form, three the bare domain. That split is worth remembering the next time somebody claims one of the two is standard.
Counted from the unencrypted bare domain – what people type when they type nothing – one domain answered immediately, seven took one hop, and four took two. Two hops is the honest cost of doing this correctly with separate rules: one for the scheme, one for the host form. Collapsing them into a single rule that fixes both at once is possible and saves a round trip.
One domain also changed the path on the way, ending on a subdirectory rather than the front page. That is a deliberate choice, and it is worth knowing that a redirect tracer counts it as a hop like any other.
The three that did not converge
Two of the twelve answered under both host forms. The bare domain served content, and so did the www version, each staying where it was. Both are large, competent projects, which makes the point better than a small example could: this is not a beginner error but a configuration nobody revisited.
The cost is quiet. Both versions work, nobody reports a fault, and the split only shows up as two entries in a search engine index or as a link profile divided between two hosts.
The third case was sharper: one domain answered on http and stayed there. No forward to https at all, in either host form. Every visitor who does not type the scheme gets the unencrypted version, and every browser that has never seen the site has no reason to try the encrypted one first.
The hop that HSTS removes
Once the chain is correct, the first hop is still paid on every visit that starts unencrypted. The header Strict-Transport-Security removes it for everyone who has been there before: the browser remembers, for the duration given, that this host is only to be contacted over https, and skips the unencrypted request entirely.
It is worth two warnings. The remembered value is hard to undo, so a short duration belongs in the first attempt. And the header only counts when it arrives over https, which means it has to sit on the final address rather than on the redirect that leads there.
Reading all four at once
Checking this by hand means eight to sixteen calls with curl -I, plus the discipline not to let the shell follow the redirects silently.
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" http://example.com/The Redirect Chain and Canonical Host Tracer in the toolbox performs these checks in one operation. It traces the entered address hop by hop, recording the status code, Location header and time for each hop, then fetches all four variants and reports whether they end at one address. It explicitly flags chains longer than one hop, temporary codes where permanent ones belong, and redirects from https back to http, so these findings do not have to be picked out of the list by hand.
Questions and answers
What does an Apache rule look like that fixes scheme and host form in a single hop?
Two conditions joined with OR, and a target that sets both correctly at once. With the www form as the final address:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
Every entry point that is not already the final address then reaches it after exactly one hop, including the unencrypted bare domain. The path travels along through the capture group, and Apache appends the query string again by itself.
There is a trap in the first condition. If a load balancer or CDN in front of the server terminates TLS and passes requests on internally over http, %{HTTPS} always reads off, and the rule redirects every request again, which ends in a loop. The condition then has to check the header set by the upstream service, usually X-Forwarded-Proto. And the rule does not replace the certificate: the bare domain has to be listed in it, or the handshake fails before the rule is ever reached.
Do includeSubDomains and preload belong in the very first HSTS header?
Better not. includeSubDomains forces every subdomain onto https, including those that have no valid certificate yet, and inclusion in the browsers’ preload list requires a duration of at least one year and can only be undone slowly. Both therefore belong in a later stage, once every subdomain is reachable over https.
Is a canonical tag enough instead of redirecting the other three addresses?
For search engines it is a hint; for visitors it is nothing at all. Anyone who calls up the bare domain over http stays on the unencrypted version, and logins and consent stored in cookies or browser storage remain tied to the address they were created on. Even as a hint it is weaker than a 301: search engines may overrule it, and inbound links keep pointing at both hosts.
The canonical tag makes sense in addition to the redirect, on the final address and pointing to itself. Then both signals agree, and copies with appended parameters are assigned correctly as well.
Related articles
