WWW or non-WWW: choose a canonical website address and verify both routes

Understand the two addresses

https://example.com/ and https://www.example.com/ use different hostnames. You can configure them to reach the same website, but they can also point to different applications or projects. Treat their setup as something to verify, rather than assuming a browser will add or remove www for you.

The preferred or canonical URL is the version you intend to use consistently. Google may choose a canonical when substantially similar content is available at multiple addresses. Your redirects, annotations and other signals can indicate a preference; they do not give you an unconditional command over Google’s selection. See Google’s canonical URL guidance.

For a small new site, choose the version your platform supports cleanly and use it in navigation and public materials. For an established site, review its current final URL, internal links and indexed information before changing anything. A cosmetic preference alone may not justify another migration.

Check the existing behaviour before choosing

Open the site’s current homepage and one important inner page with and without www. Record the final browser address, visible content and any error. Then inspect the relevant platform’s domain settings to identify the intended primary address.

Suppose a fictional repair business already uses https://www.example.com/services/ in its navigation, customer messages and public profiles. If that route is working, first make the non-www version reach the same service page. Reversing the established preference simply because another site omits www adds work without demonstrating a business benefit.

If the two hostnames show different sites, pause. Confirm the domain and intended project before creating redirects. A redirect can hide an accidental project assignment from casual inspection while leaving the underlying account or hosting error unresolved.

Configure both hostnames at the correct layer

Follow the website platform’s specific domain instructions at the provider hosting the authoritative DNS. Keep a record of the existing configuration and confirm the target project. Do not replace working email records or nameservers merely to choose a website hostname; a separate mail or DNS migration requires its own plan.

A DNS alias and an HTTP redirect do different jobs. DNS can direct a hostname toward a service; the web service must still decide what response to return. Mozilla’s HTTP redirect explanation describes the redirect response that tells a browser to request another URL.

If a platform offers a primary-domain control, check whether it also configures the alternate hostname and its redirect. If a host, CDN and application each have redirect rules, give them the same destination. Maintain one understandable policy instead of several layers trying to undo one another.

HTTPS must work before relying on the redirect

Check certificate coverage for both hostnames you expect visitors to use. Mozilla explains that TLS server authentication binds a server’s certificate to its domain name. A broken secure connection at the alternate HTTPS address cannot be repaired by assuming the visitor will reach a later HTTP redirect. See TLS server authentication.

Certificate names matter: Let’s Encrypt’s certificate glossary explains Subject Alternative Names and notes that a wildcard for *.example.com covers www.example.com but not example.com itself. Inspect actual coverage rather than relying on a “wildcard” label.

Do not ask visitors to bypass a certificate warning. Resolve the affected hostname’s certificate and hosting configuration, then repeat the test. The homepage working securely at your preferred hostname does not prove that a saved alternate address is safe to open.

Redirect matching pages to the chosen version

For a permanent choice, Google recommends a server-side permanent redirect where possible; HTTP 301 and 308 identify permanent moves. See Google’s redirect guidance. Use a supported platform or server method rather than copying a rule intended for a different installation.

If www is preferred, the non-www /services/ address should reach the www /services/ page, not the homepage. If non-www is preferred, apply the same relationship in the other direction. Keep the requested page path and required query parameters intact where appropriate.

For a simple setup, aim to send an alternate HTTP or HTTPS URL directly to the final preferred HTTPS destination. Check the actual response chain: extra hops can come from separate www, HTTPS and trailing-slash rules. Avoid a loop where one layer adds www and another removes it.

Make discovery signals consistent

Use the preferred HTTPS address in internal links, sitemap entries and canonical metadata. Google’s canonical guidance warns against conflicting preferences across those methods and recommends linking consistently to canonical URLs. If a page has a canonical annotation, it should identify that page’s appropriate preferred URL.

Do not canonicalise every article to the homepage: that describes a different relationship from choosing one hostname for each article. Equally, using noindex or blocking crawling on the alternate hostname is not a replacement for a correct redirect and canonical policy.

Check important public profile links and campaign destinations you control. Updating them reduces dependence on redirects, while the alternate hostname should remain supported for bookmarks and existing external links.

Use Search Console to observe, not to force the prefix

Search Console no longer has the old Preferred Domain setting. Google retired it in 2019 and directs owners to canonical signals. Ignore instructions that require finding that obsolete control.

A Domain property includes protocols and subdomains, including www and non-www. A URL-prefix property covers its specified prefix. Choose the scope you need and follow its verification requirements; adding a property does not configure a website redirect. See Search Console property types.

For an important page, URL Inspection’s indexed data can show the user-declared and Google-selected canonical. Compare its crawl date with your change. A live test checks current accessibility and detectable issues, but cannot guarantee future canonical selection. See the URL Inspection guide.

Google’s current move documentation says Change of Address is not required when switching between www and non-www on the same domain. That is distinct from moving to another registered domain.