www or non-www? How to Redirect Your Site to One Domain

To see how many addresses your site answers on today, run your domain through our redirect checker. We at Talha Aslan and team start most technical SEO audits with this exact check. If even one of the four variants loads on its own, your link signals and your reports start to split.

In this guide, we cover how to pick a preferred domain, how to test all four variants, how a canonical tag supports the redirect, and what to look for in Search Console. Every example below is an example scenario, and we use example.com as the domain throughout.

Why do www and non-www behave like two separate sites?

Technically, www.example.com and example.com are two different hostnames. Therefore, browsers and search engines treat them as different addresses. So if the same content loads on both, you end up with two copies of every page. If you want the background on what www actually is, read our explainer on what www means; here we stay focused on redirects.

The protocol adds another layer. HTTP and HTTPS are separate schemes, so each hostname doubles again. As a result, one site can expose four different starting addresses to the outside world.

Google states in its documentation that some duplicate content is normal and does not violate its spam policies. That said, the same page notes that duplicates can create a poor user experience. They also make it harder to track how your content performs in search. For the wider picture, see our guide on duplicate content. In short, the goal is not avoiding a penalty. The goal is consolidating signals on one address.

What are the four variants, and why must they all lead to one URL?

Every domain has four basic public versions, and the www or non-www question touches two of them. The table below shows what each variant should do in an example scenario where the preferred address is https://www.example.com.

If you prefer the non-www version, simply flip the table. Then https://example.com returns 200 and the other three point to it. Two things matter here. First, every variant must reach the same final URL. Second, it must get there in one hop.

Why one hop? Because when http://example.com first goes to https://example.com and only then to https://www, you create a two-step chain. We explain why chains waste crawl effort and slow visitors down in our article on redirect chains.

What are the technical differences between www or non-www?

There is no SEO difference, yet a few real infrastructure differences exist. Therefore, we suggest you base the decision on your DNS and hosting setup rather than on taste.

• DNS flexibility: The DNS standard (RFC 1034) says that if a CNAME record exists at a node, no other data should exist there. Your root domain already holds SOA and NS records, so a classic CNAME cannot live at the apex. Because www is a subdomain, you can point it to a CDN or host with a CNAME.
• Cookie scope: A cookie set on the root domain can reach subdomains, depending on its Domain attribute. If you serve static files from a separate subdomain, a www setup keeps cookies cleaner.
• Length and brand: A non-www address looks shorter and is easier to say. That helps on business cards and in ad copy.
• Habit: Also, some people still type www. With a correct redirect, that causes no trouble at all.

On the other hand, many modern DNS providers now offer CNAME-like options at the root. So the non-www route works perfectly well today in most setups. Check your provider's documentation, then decide.

Does the choice affect Google rankings directly?

No. Using www or skipping it gives no ranking boost on its own. Google's guide to consolidating duplicate URLs states no preference between the two. Instead, it tells you to pick one URL as canonical and redirect the others to it.

However, the indirect effects are real. For example, if your backlinks point to both variants, signals may look divided until Google settles on one canonical. In addition, Search Console can show clicks under two different addresses. That makes a traffic drop easy to misread.

Google also stresses that a canonical preference is a hint, not a rule. So if you declare https://www.example.com while internal links, the sitemap and redirects point elsewhere, Google may not follow your choice. That is why aligning every signal in the same direction works best.

In other words, the choice itself is neutral, and inconsistency is the costly part. Moreover, the cost reaches beyond search. Your analytics may list the same page twice, ad platforms may store different landing pages, and your team ends up merging reports by hand.

How do you pick your preferred domain?

We suggest you answer these questions in order. Each one nudges you toward one side.

1. Which version has the site used the longest? Where do most old backlinks and indexed pages sit? Keeping the current setup usually carries the least risk.
2. Does your host or CDN support the root domain directly? If not, a www setup makes life easier.
3. Which address appears in print, ads and email signatures? Would changing it cost money or effort?
4. Do you run separate apps on subdomains? If cookie separation matters, www may be the cleaner choice.

For a brand-new site, both www or non-www options are fine. Still, we do not recommend moving an established site only because one version looks more modern. Every move means Google has to process the new URLs again, and that takes time.

Once you decide, write the decision down. Then your developer, content team and ad team all use the same address. Later, when someone launches a new campaign, nobody links to the wrong variant by accident.

Which status code should the redirect use?

In short, use a permanent redirect: 301 or 308. According to Google's redirects and Google Search documentation, both codes mean the page has moved permanently. The same page says Google's indexing pipeline uses a permanent redirect as a signal that the target should become canonical.

By contrast, 302 and 307 are temporary. With a temporary code, Google may keep showing the source page in results. So a temporary redirect for www consolidation says the opposite of what you mean. We compare all four codes in detail in our 301 vs 302 vs 307 vs 308 guide.

The difference between 301 and 308 lies in the request method. The HTTP standard RFC 9110 notes that, for historical reasons, a browser may change a POST request to GET after a 301 or 302. A 308 keeps the method. For a simple brochure site, either works. If forms might post to an old variant, however, 308 is the safer pick.

Also, handle the redirect on the server. Google says a server-side redirect has the highest chance of correct interpretation. It recommends JavaScript redirects only when no server-side or meta refresh option exists.

How do you set up the redirect step by step?

Where you configure it depends on your stack: hosting panel, server config or CDN rules. We stay at the concept level here, because exact steps differ from one environment to another.

1. Prepare DNS records: Create a record for both the root domain and www. A variant with no record never resolves, so the redirect never runs.
2. Cover all variants with SSL: Anyone who opens https://example.com sees that hostname's certificate before any redirect happens. If the certificate only covers www, the browser shows a warning.
3. Write one rule: If the incoming scheme or hostname is not the preferred one, send the request straight to the final URL. Keep the path and query string intact.
4. Preserve the path: http://example.com/services/ should land on https://www.example.com/services/, not on the homepage.
5. Match the app setting: The site URL setting in your CMS must name the same variant as the server rule. Otherwise the two layers bounce visitors back and forth.
6. Clear caches, then test: A CDN or server cache can hold the old behavior for a while.

Step five gets skipped most often. When the server sends visitors to www and the app sends them back to non-www, you get an endless loop. Our guide to the too many redirects error walks through that fix.

How do you test all four variants with the redirect checker?

After you write the rule, trust measurement, not memory. Your browser caches old redirects, so a test in your own browser can mislead you. A tool that requests every hop fresh from the server gives a cleaner answer.

1. Open the redirect checker tool and type your domain into the Address (URL) field, for example example.com.
2. Pick the "4 versions" mode. The tool then compares the HTTP, HTTPS, www and non-www versions side by side.
3. Press Check. The tool sends a new request at every hop and follows the chain for up to 10 hops.
4. Read each row: status code, address and response time. Confirm that all four variants end on the same URL with a 200.
5. If the badge or notes flag a temporary code, a chain, a loop or an HTTPS to HTTP downgrade, fix the rule and check again.

Next, do not stop at the homepage. Test a few inner URLs as well, such as a service page, a blog post and a URL without a trailing slash, using "Single URL" mode. Some rules work on the homepage yet drop the path on deeper pages.

Which test results point to a problem?

In practice, a healthy setup looks almost boring: three variants end with one 301 or 308, and the preferred variant returns 200 right away. Any other pattern tells you something.

• Two redirects: If HTTP goes to HTTPS first and then to www, your rule has two parts. Merge both conditions into one rule.
• A 302 or 307: Hosting panels often default to a temporary code. Switch it to a permanent one.
• A different final URL: If one variant ends somewhere else, the duplicate risk remains.
• Certificate errors: If an HTTPS variant fails to connect, the certificate probably does not cover that hostname.
• A 404 at the end: The rule likely breaks the path or targets the wrong host.

For instance, imagine an example scenario where http://www.example.com goes to https://www.example.com with a 302. The final URL looks right, yet the temporary code tells Google the move is not permanent. In practice, the final URL alone is not enough; the code and the path both have to be right.

If you want to dig into the HTTP to HTTPS side in detail, see our guide on how to check an HTTP to HTTPS redirect. Here we only cover the part where it overlaps with www.

How do canonical tags and redirects work together?

A redirect physically moves visitors and crawlers to one address. A canonical tag, on the other hand, lets the page declare which URL is the main version. Google's documentation calls both strong signals and says these methods stack, so they become more effective when combined.

So the right setup looks like this. The redirect gathers all four variants on one address, and every page on that address names its own preferred URL as canonical. For example, the canonical of https://www.example.com/services/ should be exactly that URL, not a non-www or HTTP version.

Google also warns against one specific mistake: do not name different canonical URLs for the same page through different methods. If the redirect points to www while the canonical tag names non-www, the two signals weaken each other. In addition, Google advises against using robots.txt for canonicalization.

For general canonical tag usage, see our guide on what a canonical tag is. The one rule to remember here is simple: the canonical must match the address where the redirect lands.

Which address should the sitemap and internal links use?

Your sitemap and internal links should use the preferred address without exception. Google treats a sitemap as a weak signal, yet even a weak signal adds confusion when it pulls the other way.

The pattern we see most often goes like this. The redirect rule works, but menu links, older blog posts or the sitemap still point to the other variant. As a result, every click passes through an extra redirect, and Googlebot follows the same redirect on every crawl.

• Start every sitemap URL with the preferred scheme and hostname.
• Write menu, footer and in-content links as relative paths or with the full preferred URL.
• Use the same variant in schema markup, Open Graph tags and hreflang annotations.
• Update ad landing pages, social media profiles and email templates.

This cleanup matters as much as the rule itself. A redirect hides the mistake, while clean internal links remove its source. Also, your server stops handling thousands of needless requests.

Which Search Console property type should you use?

Search Console offers two property types. According to Google's add a property help page, a Domain property aggregates data for all subdomains, protocols and subpaths. It automatically includes both www and non-www, and it requires DNS verification.

A URL-prefix property, by contrast, only includes URLs that start with the exact prefix, protocol included. So a prefix property for https://www.example.com shows nothing for https://example.com. This gap explains many "lost traffic" scares after a www change.

For that reason, we recommend a Domain property for day-to-day tracking. If you also want to watch one variant on its own, add a URL-prefix property next to it. We explain the trade-offs in our comparison of the Domain vs URL-prefix property.

Keep in mind that the property type does not decide which URL Google picks as canonical. A property is only a reporting window. The decision comes from redirects, canonical tags and internal links.

How do you confirm your www or non-www choice in Search Console?

After the setup, use the URL Inspection tool to see whether Google accepts your preference. According to Google's help page, the tool shows the user-declared canonical and the Google-selected canonical as separate fields.

1. Inspect an important page on your preferred address.
2. Check that the user-declared canonical shows that address.
3. Compare it with the Google-selected canonical. If both match, Google has accepted your choice.
4. Inspect the other variant too. In the page indexing report, a status like "Page with redirect" is normal for it.

The help page also notes that the Google-selected canonical can lag a few hours behind the index. It adds that Google may not choose your preferred canonical. So do not judge after a single check; watch a handful of sample pages for a few weeks.

If you wonder why redirected URLs appear under their own heading, our article on the Page with redirect status explains that report. For a www or non-www consolidation, this status is the expected outcome, not an error.

Does the Change of Address tool help with a www switch?

No. Google's Change of Address tool help page tells you not to use the tool for moves between www and non-www on the same domain. Instead, it points you to canonical tags and redirects. The same page also rules the tool out for HTTP to HTTPS protocol changes.

This matters because many site owners treat a www switch like a domain migration and go looking for the wrong tool. In this scenario, Google detects the change on its own by following redirects and canonical signals. So your job is to keep those signals clean and consistent.

On the other hand, a full domain change is a different story. If you move from example.com to a brand-new domain, the Change of Address tool does apply. A www consolidation, however, stays inside the same domain.

In short, what you need from Search Console here is verification and monitoring, not a migration button. Knowing that saves you time and a fruitless search through settings.

What are the most common redirect mistakes?

Below, we list the mistakes that come up again and again in our audits. Each one looks minor. Together, though, they send Google mixed signals.

• Redirecting only the homepage: If example.com/contact/ still returns 200, the consolidation is only half done.
• Sending everything to the homepage: Visitors lose the page they wanted. Keep the path instead.
• Dropping query strings: If campaign tags disappear during the redirect, your ad tracking breaks.
• Conflicting rules in two layers: When the CDN sends traffic to www and the server sends it back, you get a loop.
• A certificate for one variant only: If https://example.com throws a warning, the redirect never even runs.
• HTTPS to HTTP redirects: Google's documentation says these can make Google prefer the HTTP version very strongly.

Feel free to use this list as a checklist for your own site. Also, rerun the four-variant test after every change. That way, you catch problems before your visitors do.

How does HSTS fit with your preferred domain?

HSTS (HTTP Strict Transport Security) is a security header that tells browsers to load a domain only over HTTPS. RFC 6797 defines it. Google's canonicalization guide also lists HSTS among the ways to reinforce the HTTPS version.

The link to your www decision starts with one directive. If the policy includes includeSubDomains, it covers subdomains too. Therefore, before you turn on HSTS, make sure every subdomain, www included, loads cleanly over HTTPS. Otherwise, a subdomain without HTTPS support may become unreachable in browsers.

Here is the order we suggest. First, consolidate the four variants and verify the certificates. Then monitor for a few weeks. After that, start HSTS with a short duration and extend it once nothing breaks. For duration values, check current recommendations from official sources.

Note that HSTS does not replace the redirect. On a first visit, the browser has not seen the header yet, so the HTTP request still reaches your server. That is why the permanent redirect rule should stay in place no matter what.

What should you watch when moving an existing site to the other variant?

Still, sometimes a switch is unavoidable. For example, a new hosting platform may only support www, or a brand decision may change the address. Either way, plan the move instead of improvising it.

1. Export the currently indexed URLs and the pages that bring the most traffic.
2. Launch the new variant on staging or during a low-traffic window.
3. Set up page-level redirects that keep the path, then run the four-variant test.
4. Update canonical tags, the sitemap and internal links on the same day.
5. Monitor the Domain property in Search Console. If you rely on URL-prefix properties, add one for the new variant.

During the transition, some old URLs may keep appearing in results for a while. Google's redirect documentation says old URLs can still show as alternate names after a move and that this fades over time on its own.

If you wonder how long to keep the rules live, see our article on how long 301 redirects should stay. Our advice for www rules is simple: keep them for the life of the site.

Example scenario: what does the setup look like for example.com?

Let us make this concrete with an example scenario. A small service business runs on example.com. The site has used www for years, and the business cards say www too. So the decision is easy: the preferred address becomes https://www.example.com.

The first test shows this pattern. http://example.com goes to https://example.com and then to www, which is a two-hop chain. Meanwhile, https://example.com reaches www with a 302. On top of that, half the sitemap lists non-www URLs.

The fix happens in this order. First, the developer merges two rules into one, so every variant goes straight to https://www.example.com with a 301. Next, they switch the panel's temporary code to a permanent one. Then they rebuild the sitemap and check each canonical tag.

In the final test, three variants end with a single 301 and the preferred URL returns 200. After that, the team tracks a few sample pages with URL Inspection. This is a typical fix flow, not a measured case; your own order may differ.

Which checklist confirms the switch to one URL is complete?

We turned this guide into a list you can tick off after setup. Once every item holds, your www or non-www decision is technically complete.

• You have recorded the preferred scheme and hostname in writing.
• All four variants have DNS records and a valid SSL certificate.
• Three variants reach the target in one hop, with a permanent code, keeping the path.
• The app setting and the server rule name the same variant.
• Canonical tags, the sitemap and internal links use the preferred URL.
• A Domain property runs in Search Console, and you watch sample pages regularly.

Above all, this check makes a solid starting point for the rest of your technical SEO. After all, crawling, indexing and reporting all assume your site lives at one address. We at Talha Aslan and team recommend locking in this foundation before any content or link work.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.