Canonical Domain: www, Non-www, HTTP and HTTPS

One site, four hostnames

The canonical domain is the single combination of scheme and hostname that every public URL on a site uses, such as https://www.example.com. Choose one host on HTTPS and redirect everything else to it: Google has no ranking preference between www and the bare domain, it does prefer HTTPS, and the old Search Console setting that once recorded this choice no longer exists.

Without that choice, every page exists at four addresses, the http:// and https:// forms of both example.com and www.example.com, and a crawler sees four URLs. The bare form is called the apex (also the bare, naked or root domain); www.example.com is technically a subdomain.

Google called it the "preferred domain," Apache's documentation says "Canonical Hostnames," and Semrush reports a "WWW resolve issue." No standard defines it, so the working meaning of canonical domain is: one host is chosen, and redirects, rel="canonical" tags, internal links, XML sitemaps, hreflang and structured-data URLs all name it. A choice that lives only in a redirect rule is half made.

How Google treats host and protocol duplicates

Google groups the variants into one cluster and selects a single canonical for it. Its 2019 post retiring the preferred domain setting used exactly this example: content found at both http://example.com/ and https://www.example.com/index.html, of which "we'll pick one URL as the 'canonical' for Search."

Protocol is the one dimension where Google states a default. It "prefers HTTPS pages over equivalent HTTP pages as canonical," with exceptions (Google Search Central). Each exception is something a site does to itself:

• the HTTPS page has an invalid SSL certificate;
• it loads insecure dependencies other than images;
• it redirects users to or through an HTTP page;
• its own rel="canonical" points to the HTTP page.

Migrations produce the fourth most often, when a CMS site-URL setting still says http://. Google's December 2015 announcement listed eight conditions, including no on-host links to HTTP URLs and a sitemap that lists the HTTPS URL or omits the HTTP one; the current list is shorter, but the old one remains a useful checklist.

On www versus the apex, Google states no preference anywhere in its documentation, and John Mueller confirmed in August 2017 that the choice does not matter. Bing's December 2025 guidance treats HTTP and HTTPS versions as a routine technical duplicate and names a 301 as its preferred fix.

Choosing between www and the bare domain

With no ranking difference, the decision is operational. One DNS constraint leans toward www. RFC 1034 says that where a CNAME record is present at a node, "no other data should be present," and the apex must carry SOA and NS records, so a plain CNAME from the bare domain to a CDN is not allowed while a www hostname can take one. That is an inference from the DNS standard, not a search rule, and many providers offer proprietary ALIAS or flattening records, but it explains why many CDN-fronted sites choose www.

An established site should usually keep its host. Switching is a site move with migration risk and no documented ranking gain. HTTP to HTTPS is different, because Google does prefer HTTPS, though Google documents that as a site move too. And a site can print the shorter apex in marketing while using www as its canonical domain, provided the apex redirects cleanly.

What replaced the preferred domain setting

In June 2019 Google announced that the Search Console preferred domain setting would not carry over to the new Search Console. Search Engine Land covered it on June 18, 2019. Google's recommended replacements were the rel="canonical" link tag, the rel="canonical" HTTP header, sitemaps, and "301 redirects for retired URLs." Any guide that still says to set your preferred domain in Search Console predates that change; the setting is gone.

Search Console now offers visibility, not control. A Domain property covers "all subdomains, protocols, and subpaths," includes www and non-www automatically, and verifies by DNS record; a URL-prefix property covers one exact prefix, protocol included. The Domain property shows traffic reaching the wrong host in one place, but it expresses no preference to Google.

The Change of Address tool is not for this either. For HTTP to HTTPS, Google's help says "don't use this tool; Google will figure out your changes for you." For www versus non-www it says to use canonical tagging and/or redirects without the tool.

Server rules for one hop to the canonical domain

Apache's own documentation says "The very best way to solve this doesn't involve mod_rewrite at all" and recommends a Redirect in a separate <VirtualHost> for the non-canonical names. Its examples omit a status code, though, and Redirect without one sends a 302, so add permanent:

<VirtualHost *:80>
  ServerName example.com
  ServerAlias www.example.com
  Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

Where only .htaccess is available, one rule can catch both the wrong scheme and the wrong host, so no request takes two hops. This combines Apache's documented host-matching pattern with an HTTPS test; it is an adaptation, not vendor code:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L,NE]

nginx's documentation calls an if ($http_host …) rewrite "a wrong, cumbersome, and ineffective way" and recommends separate server blocks that return 301. Adapted for HTTPS:

server { listen 80; server_name example.com www.example.com;
         return 301 https://www.example.com$request_uri; }
server { listen 443 ssl; server_name example.com;
         return 301 https://www.example.com$request_uri; }  # certificate must cover example.com
server { listen 443 ssl; server_name www.example.com; ... }

Two traps catch these setups. The non-canonical HTTPS host needs its own valid certificate, or browsers stop at an error before the redirect runs. And behind a TLS-terminating CDN or proxy, %{HTTPS} or $scheme reads as HTTP on every request and the rule loops; test the forwarded-protocol header or redirect at the CDN. Status codes and chains are covered on the canonical redirects page.

HSTS helps browsers, not Googlebot

HSTS (HTTP Strict Transport Security) is a response header instructing browsers to use HTTPS only for a host:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Browsers honor it only over HTTPS. Afterward Chrome shows a "307 Internal Redirect" for HTTP links, which the browser creates itself. Googlebot keeps no HSTS state; Mueller said in 2020 that "Googlebot doesn't see the 307 that you'd see in the browser." HSTS sits on top of the server's 301 and never replaces it.

web.dev advises starting with low max-age values, since HSTS hosts are likely to hard-fail if TLS breaks. The preload list requires max-age of at least 31536000, includeSubDomains, preload and a submission at hstspreload.org; wait until every subdomain serves valid HTTPS, because removal is slow.

Preload also creates the one deliberate two-hop pattern. It requires an HTTP-to-HTTPS redirect on the same host first, with the HSTS header on any further redirect from the HTTPS apex, so a www preload site runs http://example.com to https://example.com to https://www.example.com, against Google's advice to go straight to the final destination. That is a fair trade for preload; without it, use one hop.

Aligning canonicals, links and sitemaps with the host

The redirect catches strays; the site's own output should not create them. Three places leak the wrong host:

• Canonical tags. Every page should carry a self-referencing canonical on the canonical domain. A canonical pointing at http:// from an HTTPS page is one of the exceptions that overrides Google's HTTPS preference.
• Internal links. Use root-relative links or absolute links on the chosen host. Ahrefs flags leaks as "HTTPS page has internal links to HTTP" and Semrush as "Links on HTTPS pages leading to HTTP page."
• Sitemaps. The sitemaps protocol requires every listed URL to use the sitemap's protocol and host, and Google asks for fully-qualified, absolute URLs. Semrush reports the common failure as "HTTP URLs in sitemap.xml for HTTPS site."

Where a hosted platform allows no server redirects, Google's 2019 list leaves a fallback: canonical tags plus consistent links and sitemaps. The variants stay reachable, but the signals agree.

Checking the canonical domain

curl -sIL http://example.com/
curl -sIL https://example.com/

Each variant should show one 301 and then the canonical domain answering. Two redirect lines mean a chain; a certificate error on the second command means the non-canonical host lacks a certificate.

In Search Console, work from the Domain property so every host and protocol appears in one Page indexing report. Variants belong under "Page with redirect." Canonical pages showing up as "Duplicate, Google chose different canonical than user" suggest signals still disagree about the canonical domain, and URL Inspection will show the user-declared and Google-selected canonical side by side. Google's troubleshooting guide notes that hosting misconfigurations can cause unexpected cross-domain URL selection.

Semrush adds "Pages with a WWW resolve issue" and "No redirect or canonical to HTTPS homepage from HTTP version." A test many audits skip: start a crawl on the non-canonical host. If internal links keep the crawler there, templates still emit the wrong domain.

Frequently asked questions