www vs non-www Redirects: How to Choose and Configure the Preferred Version

Overview

If your site loads at both https://www.example.co.uk/page and https://example.co.uk/page, you effectively have two hostnames serving the same content. Search engines can often work out the relationship, but relying on that is unnecessary risk. The cleaner approach is to choose one preferred hostname and redirect the other to it with a server-side permanent redirect.

For most teams, the decision is less important than consistency. A site can perform well on either version if implementation is clean. Problems usually start when the site is mixed: internal links point to both versions, canonicals disagree, the sitemap includes the wrong hostname, or multiple redirect rules create chains such as HTTP to HTTPS to www to non-www.

Here is the practical model to use:

• Choose one canonical hostname: either www or non-www.
• Use a 301 redirect from the non-preferred hostname to the preferred one.
• Keep all internal references aligned with the chosen hostname.
• Test every protocol and host variant to make sure they resolve in one step where possible.

In most environments, you will also want to combine this with protocol and normalisation rules so that all of these variants resolve cleanly:

• http://example.co.uk
• http://www.example.co.uk
• https://example.co.uk
• https://www.example.co.uk

The end state should be one preferred version only.

If you need a broader refresher on status codes before deciding between temporary and permanent behaviour, see 301 vs 302 vs 307 vs 308 Redirects: When to Use Each Status Code.

How to choose between www and non-www

There is no universal winner. Use the version that best fits your operational setup and existing footprint.

Choose www if:

• You want a clear convention for large sites with multiple subdomains.
• You prefer to keep the root domain and the website hostname conceptually separate.
• Your infrastructure, CDN, or legacy tooling already assumes a www host.
• You want cookie behaviour controlled more explicitly across subdomains.

Choose non-www if:

• You want the shortest possible public-facing URL.
• Your brand already uses the bare domain consistently in offline and digital materials.
• You are launching a new site and have no established hostname history to preserve.

Keep your current setup if:

• The site is already consistent and stable.
• Search visibility is healthy and you have no strong operational reason to change.
• A hostname switch would create avoidable migration work across platforms, campaigns, and integrations.

For established websites, stability often matters more than preference. If the site has used www for years, changing to non-www may be possible, but it should be treated as a controlled migration rather than a cosmetic tidy-up.

Checklist by scenario

Use the checklist that matches your situation. The goal is to make a clear decision, implement a single website redirect rule, and avoid duplicate URL versions.

Scenario 1: New site with no hostname history

This is the easiest case because there is little migration risk.

1. Pick your preferred hostname early. Decide whether your public site will live on www or non-www before launch.
2. Provision DNS for both. Even if only one version will be public, the alternate hostname still needs to resolve so it can redirect.
3. Install TLS certificates that cover both hostnames. A redirect cannot help if the browser fails before the HTTPS connection is established.
4. Set one server-side 301 redirect. Redirect the alternate hostname to the preferred hostname.
5. Use the preferred hostname everywhere. Internal links, canonical tags, XML sitemaps, hreflang references, structured data, and feeds should all match.
6. Test protocol combinations. Confirm that HTTP and HTTPS variants of both hostnames all end on the final preferred URL.

Scenario 2: Existing site is accessible on both versions

This is a duplicate-content and consistency cleanup task. The main risk is partial implementation.

1. Audit current behaviour. Use a redirect checker or command-line request to document how each host and protocol responds.
2. Choose the preferred hostname based on current signals. Look at internal links, backlinks, canonical tags, sitemap URLs, analytics filters, and brand usage.
3. Implement a permanent redirect. Use a 301 redirect from the non-preferred host to the preferred one.
4. Update canonical signals. Canonical tags should support the redirect, not contradict it.
5. Regenerate sitemaps. Remove non-preferred URLs.
6. Review external systems. Paid ads, email templates, QR codes, social profiles, marketplace links, and app deep links should point to the preferred hostname.
7. Check for redirect chains. A direct redirect is better than a path that bounces across multiple rules.

If your site also needs a protocol upgrade, combine the work carefully. Our guide on HTTP to HTTPS Redirects: Best Practices, Common Mistakes, and Testing Steps is useful when the hostname change and protocol change happen together.

Scenario 3: Moving from www to non-www

A www to non-www redirect is common when a team wants shorter URLs. Treat it as a host migration.

1. Confirm why the change is worth it. If the reason is only aesthetic, weigh that against migration complexity.
2. Inventory affected systems. CDN configuration, origin host settings, cookies, CSP rules, OAuth callbacks, analytics, and Search Console properties may all need updates.
3. Create one redirect rule. Every https://www.example.co.uk/* URL should map to the same path on https://example.co.uk/*.
4. Preserve path and query strings where appropriate. Campaign parameters and deep links should not be stripped unless there is a deliberate reason.
5. Update internal references before or at launch. Do not leave your own navigation pointing through redirects.
6. Monitor 404s and loops after launch. Pay special attention to legacy hard-coded URLs in templates and integrations.

Scenario 4: Moving from non-www to www

A non-www to www redirect often appears when teams want a clearer hostname structure or are standardising subdomain conventions.

1. Verify DNS and certificate setup for www. The target host must be fully ready before redirects go live.
2. Set a host-level 301 redirect. Map every bare-domain page to the equivalent www page.
3. Review root-domain services. Email, verification records, and non-web services attached to the apex domain should not be disturbed.
4. Align platform settings. CMS base URL, asset URLs, cache rules, and plugin settings often need hostname updates.
5. Test canonicalisation across templates. Product pages, blog posts, category pages, and paginated URLs should all output the preferred host.

Scenario 5: Domain forwarding set at registrar or DNS provider

This can work for simple cases, but check whether it is sufficiently flexible for your needs.

1. Confirm the redirect status code. Some forwarding tools default to temporary behaviour or obscure how the response works.
2. Check HTTPS support. Basic forwarding tools may not handle certificates or full-path forwarding cleanly.
3. Verify path handling. Redirecting only the homepage is not enough if deep links exist.
4. Test query string preservation. This matters for campaign URLs and analytics attribution.
5. Prefer server or edge control for complex sites. If you need rule logic, observability, or reliable SEO redirect behaviour, application, server, CDN, or edge-layer control is usually better.

Scenario 6: WordPress, Apache, Nginx, or Cloudflare implementation

The exact syntax differs, but the logic is the same: check the incoming host, then send a permanent redirect to the preferred host while preserving the request URI.

Implementation checklist:

• WordPress: Set the site URL correctly, then use server or plugin rules carefully. Avoid competing plugin and server redirects.
• Apache redirect: Use a host condition and a single rewrite rule. Keep it high enough in the stack to avoid extra hops.
• Nginx redirect: Create a dedicated server block for the non-preferred host and return a 301 to the preferred host.
• Cloudflare redirect: Use a redirect rule or equivalent edge rule, then confirm it does not conflict with origin redirects.

Whatever the platform, one principle matters most: only one layer should be responsible for the host redirect unless you have deliberately designed multi-layer logic.

What to double-check

Before and after launch, review the details that commonly get missed. This is where many preferred domain redirect projects become untidy.

1. Status code

For a long-term hostname choice, use a 301 redirect. A 302 redirect suggests temporary intent and can create mixed signals if left in place indefinitely.

2. Path preservation

The redirect should normally keep the same path and query string. A request for /products/widget?utm_source=email should not collapse to the homepage unless that is an explicit exception.

3. HTTPS certificate coverage

If users can reach the alternate hostname over HTTPS, its certificate needs to be valid. Otherwise the browser may stop before the redirect can happen.

4. Canonical tags

Canonicals are supporting signals, not substitutes for redirects. They should point to the preferred hostname. If canonicals say non-www but the server redirects to www, the setup is sending mixed instructions.

5. Internal links and navigation

Update your own site to link directly to the preferred hostname. Internal links that rely on redirects create unnecessary hops and can hide configuration problems.

6. XML sitemaps and feeds

Sitemaps should include only final URLs on the preferred host. The same applies to feeds and any machine-readable exports consumed by partners or internal tools.

7. Hreflang and structured data

If your site uses hreflang, every referenced URL should use the chosen hostname consistently. Structured data URLs should do the same.

8. Analytics and campaign tracking

Review hostname filters, referral exclusions, UTM reporting assumptions, and short-link destinations. Hostname inconsistency can fragment reporting. This is especially important if you use campaign routing or QR code redirects.

9. Redirect chains and loops

Check whether the rule order creates a chain such as:

http://example.co.uk → http://www.example.co.uk → https://www.example.co.uk

A cleaner setup would go directly to the final destination in one step where possible. Also test for accidental loops, especially when CDN, origin, and application rules overlap.

10. Search platform settings and verification

Make sure the preferred hostname is reflected in the relevant webmaster and analytics properties you actively use. The exact interface may vary over time, but the principle remains: your monitoring setup should match your canonical domain setup.

Common mistakes

These are the patterns that most often turn a simple URL redirect task into a longer clean-up project.

• Treating canonical tags as enough. If both hosts remain live, a canonical alone is weaker than a redirect-backed preferred domain setup.
• Using a 302 for a permanent hostname decision. Temporary redirects have valid uses, but preferred host choice is usually not one of them.
• Redirecting only the homepage. Deep links matter. A host redirect should preserve the full path.
• Forgetting query strings. This can break attribution, search parameters, login flows, and campaign tracking.
• Leaving mixed internal links in place. Navigation, content links, image references, and canonicals should not alternate between versions.
• Stacking multiple redirect layers without coordination. Registrar forwarding, CDN rules, web server rewrites, CMS plugins, and application code can easily conflict.
• Ignoring cookies and session behaviour. Hostname changes can affect auth flows, shopping baskets, and consent tooling if cookie scope is not reviewed.
• Changing hostname during another migration without a plan. If you are also changing CMS, URL structure, templates, or analytics, document the redirect mapping and rollout sequence carefully.
• Not testing the edge cases. Test trailing slashes, uppercase URLs, parameters, old marketing links, and any major landing pages with historic backlinks.

For larger estates or sensitive environments, a verification-first approach to redirect changes is often worth adopting. A useful companion read is A Verification-First Framework for Redirect Audits in Regulated and High-Trust Environments.

When to revisit

Your preferred hostname should not change frequently, but the decision and its implementation should be revisited whenever the underlying setup changes. Use this section as an action-oriented review list before seasonal planning cycles or when workflows and tools change.

Revisit your setup when:

• You are redesigning or replatforming the site.
• You are moving hosting, CDN, or DNS providers.
• You are consolidating subdomains or launching new ones.
• You are changing analytics, tag management, or campaign routing tools.
• You are updating your CMS, redirect plugin, or edge rules engine.
• You notice indexing anomalies, duplicate URL versions, or referral data fragmentation.
• You are preparing a migration checklist for wider URL changes.

Quick recurring review checklist

1. Request all four host and protocol combinations for the homepage and a sample of deep URLs.
2. Confirm every route lands on the final preferred hostname with the intended status code.
3. Run a redirect checker to spot chains and loops.
4. Check canonical tags, sitemap entries, internal links, and hreflang references.
5. Validate campaign links, QR code destinations, and any short links that rely on clean forwarding.
6. Review server, CDN, and application rules to confirm there is no duplicate logic.
7. Document the current rule set so future teams understand why the preferred host was chosen.

If your site changes often, redirect governance matters as much as the initial rule. These related reads can help you build a more durable process: Redirect Governance for Fast-Changing Content: Lessons from High-Velocity Data Systems and How to Use Real-Time Insights to Decide Between 301, 302, and Canonical at Scale.

Final takeaway: pick one hostname, redirect the other permanently, align every supporting signal, and test the setup whenever infrastructure or workflows change. That keeps your preferred domain redirect simple, understandable, and durable.