« Blog Overview /Digital Marketing/Tutorials / With or Without www, HTTP or HTTPS:...

Read this article in other languages:

With or Without www, HTTP or HTTPS: Checking the Four Website Addresses

Published: 2026-10-16 07:50 (No comments yet) · 7 min read

Management Summary

The same website can have four familiar entry points: with or without www, and with an encrypted or unencrypted connection. Redirects guide those variants to the intended secure address and equivalent content. This makes links easier to maintain and avoids inconsistent experiences between entry points. Reaching the same address is not enough if forms or page contents change along the way. A slightly longer redirect path can sometimes establish future secure access, so fewer steps are not always the better result.

Contents

A dated example: 2 September 2026
Origins and cookies are different boundaries
A preferred address, without ranking promises
Certificates and the deliberate second hop
HSTS belongs on HTTPS responses
Four checks with explicit evidence
Questions and answers
Sources

For a public website, HTTP and HTTPS combined with the bare domain and the www host produce four common entry addresses. Name resolution (DNS), encrypted transport (TLS) and server rules determine which are reachable and where requests end. These four combinations are a useful checklist, not every possible address of a domain.

Four entry addresses; the redirect policy depends on HTTPS and HSTS requirements.

A dated example: 2 September 2026

The archived measurement covers twelve domains and four variants per domain. Nine sets recorded the same final URL for all four variants. Three differed: kernel.org and apache.org retained separate www and apex targets, while nginx.org retained separate HTTP and HTTPS targets. Matching URLs did not establish successful delivery: the recorded HTTP-apex chain for stackoverflow.com ended with 403.

For the twelve HTTP-apex starting addresses, the snapshot recorded seven one-hop chains, four two-hop chains and one response without a redirect. These counts describe that starting variant, not all 48 tests. The data records observed responses on that date; no current configuration, cause of the choices or universal ranking consequence follows from the snapshot.

Origins and cookies are different boundaries

http://example.com and https://www.example.com have different origins because their scheme and host differ. An origin combines scheme, host and port. Origin-bound browser storage is separate. Cookie scope follows different rules: without a Domain attribute, a cookie is host-only even on the bare domain. With Domain=example.com, a cookie can cover the parent and subdomains; a permitted parent-domain cookie can also be set from www.example.com. Secure, Path and other attributes impose additional conditions. Choosing www does not by itself prevent cookie sharing.

A preferred address, without ranking promises

For equivalent public pages, a consistent HTTPS destination simplifies navigation, links and maintenance. Google can identify duplicates and select a canonical URL, the main address used to represent those copies in search, without an explicit preference. Multiple accessible copies therefore do not automatically mean two indexed pages or permanently divided link signals.

Permanent redirects and rel="canonical" are both strong canonicalization signals. Internal links and sitemaps should agree with the intended destination. A canonical annotation does not redirect a visitor or encrypt an HTTP connection, and no annotation guarantees Google’s choice. Parameters that change substantive content should not automatically be canonicalized away.

Both 301 and 308 indicate a permanent move. Unlike historical 301 handling, 308 preserves the request method and body. Rules for login forms, POST endpoints and APIs therefore need separate consideration; temporary redirects can be correct for temporary situations.

Certificates and the deliberate second hop

Every HTTPS hostname visited in the chain needs valid TLS coverage before an HTTP redirect can be read. One certificate may cover both names, but separate correctly configured certificates are also possible. A redirect is not a substitute for working DNS, a reachable TLS endpoint or a matching certificate.

A direct redirect from http://example.com/path to https://www.example.com/path saves a network hop. However, that visit does not establish HSTS for example.com: a policy received from www does not apply upward to its parent. A deliberate alternative is HTTP to HTTPS on the same host, followed by the host change. The intermediate HTTPS response can set the policy for the original host. Two hops are therefore not automatically a configuration error.

HSTS belongs on HTTPS responses

Strict Transport Security instructs supporting browsers to upgrade future HTTP access within the policy’s scope. A header received through HTTP is ignored; a valid HTTPS redirect can carry an effective header. The policy is not restricted to the final content response.

Initial deployment needs verified HTTPS coverage and a suitable short trial period. includeSubDomains extends the policy to nested subdomains and must match the supported infrastructure. A policy on a child host does not protect the parent. A later max-age=0 response removes that host’s stored policy, but cannot undo an independently applicable parent policy or instantly remove a browser preload entry.

Preloading places the domain on a list shipped with browsers, so HTTPS is required before the first visit. This is a separate long-term decision, not an automatic next step. The preload project’s current guidance recommends HSTS but does not recommend preloading generally. Submission still has strict requirements, including same-host HTTP-to-HTTPS redirection, valid HTTPS across subdomains and the required header directives. Browser HTTPS upgrades and existing preload policies also mean a first visit without an explicit scheme does not necessarily begin with an HTTP network request.

Seeds in the moist furrow sprout, while the same seeds on the stony track beside it do not. Likewise, the HSTS header (an instruction to connect only securely) only works in HTTPS responses.

Four checks with explicit evidence

The following shell example performs a GET for each reserved example address and prints response headers and the next redirect target. It intentionally does not follow redirects. The domain must be replaced with the actual public test target.

Shell

for url in \
  'http://example.com/' 'https://example.com/' \
  'http://www.example.com/' 'https://www.example.com/'
do
  printf '\n%s\n' "$url"
  curl --silent --show-error --connect-timeout 10 --max-time 20 \
    --dump-header - --output /dev/null \
    --write-out 'status=%{http_code} next=%{redirect_url}\n' "$url"
done

Each Location target then needs its own check until a final response or a documented error is reached. A bounded chain, timestamps, HTTP methods, final status, TLS errors and exact URLs make the result reproducible. HEAD requests with -I can behave differently from GET. A command-line client does not reproduce a browser’s stored HSTS, cached redirects, cookies or JavaScript navigation automatically.

All four successful results must converge on the intended equivalent resource, not merely two reachable variants. Lowercasing paths or query values can hide real differences. A 200 response at the end also does not prove that the correct content arrived.

The Redirect Chain and Canonical Host Tracer records server-side redirect chains and highlights possible issues. Its current comparison is heuristic: an agreement among reachable variants does not prove success for all four, and the URL comparison normalizes paths too broadly. Exact URLs and errors need inspection. A temporary code or two hops is a prompt for review, not proof of a fault.

Questions and answers

How can Apache redirect to HTTPS?

In a dedicated HTTP VirtualHost for example.com, a simple same-host rule is:

Apache

Redirect permanent "/" "https://example.com/"

The unmatched path suffix and query are passed through by this form. A separate www HTTP VirtualHost uses its own fixed HTTPS hostname. An HTTPS VirtualHost can then perform the approved host change and send HSTS on that redirect. These are configuration fragments, not a complete TLS setup or a general rule for every application method.

What changes behind a CDN or load balancer?

When TLS ends upstream, the backend’s HTTPS variable can report an unencrypted connection even for an original HTTPS request. Redirects then belong at the appropriate trusted boundary or must use validated proxy information. A publicly supplied X-Forwarded-Proto header is not trustworthy by itself; direct backend access and header replacement need a defined configuration. Blind header checks can cause loops or bypasses.

Is one hop always the best result?

No. Unnecessary chains add latency, but HSTS establishment, a deliberate path move or another documented requirement may justify an additional step. The correct destination, secure transport and preserved application behavior, such as keeping form data intact, matter alongside hop count.

Sources

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

With or Without www, HTTP or HTTPS: Checking the Four Website Addresses

Management Summary

A dated example: 2 September 2026

Origins and cookies are different boundaries

A preferred address, without ranking promises

Certificates and the deliberate second hop

HSTS belongs on HTTPS responses

Four checks with explicit evidence