How to Set Up Redirects for www, non-www, HTTP, and HTTPS Correctly

Overview

The safest redirect setup starts with one decision: choose a single canonical version of your site, then redirect every other valid variant to it with a permanent redirect.

For most sites, the variants are:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

You should pick one of the two HTTPS versions as the canonical destination:

• https://example.com if you prefer non-www
• https://www.example.com if you prefer www

Neither is universally better. The right choice is the one you can apply consistently across hosting, CDN, application settings, internal links, sitemaps, and analytics. Once chosen, the redirect behavior should be straightforward:

• HTTP should redirect to HTTPS.
• The non-canonical hostname should redirect to the canonical hostname.
• Redirects should preserve the full path and query string whenever possible.
• The final response should resolve in as few hops as possible, ideally one redirect before the page loads.

A practical example: if your canonical domain is https://example.com, then requests for http://example.com/about, http://www.example.com/about, and https://www.example.com/about should all end up at https://example.com/about.

It also helps to separate roles clearly:

• DNS points a hostname to infrastructure.
• The web server, load balancer, CDN, or application performs the redirect.
• SSL/TLS certificates make HTTPS available for every hostname you expect to receive before redirecting.

That distinction matters because many redirect problems are not actually redirect problems. They are DNS mismatches, missing certificates, or application base URL issues. If you are unsure where to make changes, it is worth reviewing Nameservers vs DNS Records: Which Should You Change and When? and How to Connect a Domain to Your Hosting Provider.

Checklist by scenario

Use the scenario that matches your current task, then test all four domain variants before you consider the work complete.

Scenario 1: New site launch on a fresh domain

This is the cleanest time to get redirect logic right.

1. Choose the canonical hostname first. Decide whether the public site will live on www or non-www.
2. Create DNS records for both hostnames you intend to support. Even if one will redirect, it still needs to resolve.
3. Provision an SSL certificate that covers every hostname that may receive traffic. In many setups that means the apex domain and the www subdomain.
4. Configure redirects at the edge or server layer. Prefer one centralized redirect rule over multiple overlapping rules.
5. Set the application base URL to the canonical HTTPS version. This matters for CMS platforms, WordPress, static site generators, and many frameworks.
6. Use canonical internal links. Navigation, asset URLs, XML sitemaps, and canonical tags should already point to the final preferred version.
7. Test paths, not just the homepage. Include a deep URL, a query string, and a trailing-slash variation.

If you are launching a new project end to end, pair this checklist with How to Launch a Website on a New Domain: End-to-End Setup Checklist.

Scenario 2: Converting HTTP to HTTPS

This is one of the most common redirect changes, and one of the easiest to get partially right and still leave problems behind.

1. Install the certificate before forcing HTTPS. If HTTPS is unavailable on a hostname, users may see certificate errors before any redirect can happen.
2. Redirect all HTTP traffic to the HTTPS equivalent. Preserve the hostname if that is a separate decision, or combine both rules into one final target.
3. Update hard-coded internal links and asset references. Avoid mixed content problems where pages load over HTTPS but images, scripts, or CSS still call HTTP URLs.
4. Update canonical tags, sitemap URLs, and application settings.
5. Review security headers carefully. HSTS can be valuable, but only enable it after you are confident HTTPS works correctly on all intended hostnames and subdomains.
6. Retest forms, login flows, webhooks, and third-party callbacks. Some integrations store an exact callback URL and may fail if the scheme changes.

If your environment is changing at the same time, such as a hosting move, coordinate redirects with the migration plan rather than treating them as an afterthought. See Website Migration Checklist: Moving Hosts Without Downtime.

Scenario 3: Redirecting www to non-www

This is a common preference for smaller brands, product sites, and teams that want the shortest possible public URL.

1. Confirm that both example.com and www.example.com resolve in DNS.
2. Make sure the certificate covers both names.
3. Set one permanent redirect from https://www.example.com/* to https://example.com/*.
4. Update the CMS or application to use the non-www version as its site URL.
5. Review CDN, cache, and reverse proxy settings. Some platforms may have hostname rules that need explicit alignment.
6. Check email and other DNS records separately. Web redirects do not affect MX or TXT records, but teams sometimes edit the wrong DNS entries while changing hostnames.

Remember that the apex domain cannot usually be handled with a CNAME in a traditional DNS setup unless your provider supports alias or flattening behavior. If your DNS design is part of the issue, compare your options in Managed DNS vs Registrar DNS: Performance, Control, and Failover Differences.

Scenario 4: Redirecting non-www to www

This remains common for large organizations, cookie scoping preferences, and setups that want clearer hostname separation.

1. Point both hostnames to infrastructure that can answer requests.
2. Issue a certificate for the apex and www names.
3. Redirect https://example.com/* to https://www.example.com/*.
4. Standardize internal references on the www version.
5. Update external integrations where the domain is stored explicitly. This may include SSO callbacks, API allowlists, CSP policies, and analytics settings.

The key is not the choice itself. The key is that every layer agrees with it.

Scenario 5: Redesign, platform change, or reverse proxy introduction

Many redirect issues appear when a site starts using a CDN, load balancer, managed host, or container platform that terminates SSL before traffic reaches the application.

1. Map where redirects currently happen. Check the CDN, ingress controller, load balancer, web server, and app configuration.
2. Remove duplicate logic where possible. Competing redirect rules are a common source of loops.
3. Ensure the app trusts proxy headers correctly. If the origin thinks requests are HTTP while the edge serves HTTPS, it may keep redirecting unnecessarily.
4. Verify host header handling. Some applications need explicit allowed-host configuration to serve the canonical hostname cleanly.
5. Test from outside your office network. Cached behavior and local overrides can hide problems.

If you are also evaluating infrastructure, these related guides may help: VPS vs Shared Hosting vs Managed Hosting: Which Is Best for Your Site?, How to Choose Cloud Hosting for a Small Business Website, and WordPress Hosting Comparison: Managed WordPress vs General Cloud Hosting.

What to double-check

Before and after any redirect change, use this verification list. It catches most real-world issues faster than staring at a configuration file.

• All expected hostnames resolve in DNS. The redirect target cannot help if the source hostname does not resolve at all.
• SSL works on every incoming hostname. Browsers negotiate TLS before receiving an HTTP redirect.
• The redirect status code is appropriate. Use a permanent redirect for long-term canonicalization. Temporary redirects are better reserved for short-lived testing or maintenance cases.
• Only one canonical destination exists. There should not be different rules for the homepage and deep links unless you intend that.
• Paths and query strings are preserved. Redirecting everything to the homepage can break campaigns, bookmarks, and search indexing.
• No redirect chains. A request should not pass through HTTP to HTTPS, then non-www to www, then slash normalization. Combine logic where practical.
• No redirect loops. Test both hostnames and both schemes directly.
• Canonical tags match the final destination. Redirects and canonical tags should reinforce each other, not disagree.
• Sitemaps list canonical URLs only.
• Robots rules are still correct. Avoid blocking a version you still need crawlers to reach for redirect discovery.
• Application settings match the canonical domain. WordPress site URLs, framework environment variables, and asset hosts often need updates.
• Cookies and sessions still behave as expected. Host-only cookies can change behavior when switching between www and non-www.
• Monitoring checks the canonical endpoint. After changes, update uptime and SSL monitoring so alerts match the production path. See Website Uptime Monitoring Guide: What to Track and Which Alerts Matter.

Also keep DNS timing in mind. If you recently changed records, apparent inconsistency may be propagation or cache behavior rather than a bad redirect rule. For that, review How to Speed Up DNS: TTL, Anycast, and Provider Features That Matter.

Common mistakes

Most redirect problems fall into a short list of avoidable patterns.

Using DNS as if it were a full redirect engine

DNS can point traffic to a service that performs redirects, but standard DNS records do not rewrite URLs, preserve paths, or issue HTTP status codes by themselves. If you need a real www to non-www redirect or HTTP to HTTPS redirect, the redirect must happen in a web-aware layer.

Forcing HTTPS before the certificate covers every hostname

This is especially common when teams secure the canonical hostname but forget the alternate one. A browser hitting https://www.example.com needs a valid certificate there before it can be redirected to https://example.com.

Creating chains instead of a direct canonical domain redirect

A chain can still function, but it adds latency and complexity. If possible, redirect every variant directly to the final HTTPS hostname in one step.

Changing only the homepage

Some redirect tools are configured as if the homepage is the whole site. A proper domain redirect configuration should preserve the rest of the URL unless you are intentionally restructuring content.

Leaving the application configured for the old URL

The server may redirect perfectly while the CMS still generates old absolute URLs, old canonical tags, or insecure asset paths. Redirects should be paired with application-level URL updates.

Overlooking integrations

Authentication providers, payment gateways, webhook senders, and API consumers may store exact callback URLs. A hostname change can break those quietly.

Ignoring caching while testing

Browsers cache redirects aggressively, and CDNs can cache them too. Test with fresh sessions, different networks, command-line requests, and response header inspection when behavior looks inconsistent.

Mixing host canonicalization with unrelated rewrites

Do one thing at a time when troubleshooting. If you change HTTPS enforcement, trailing slash rules, lowercase normalization, and legacy path rewrites together, it becomes much harder to find the real cause of a loop or mismatch.

When to revisit

Redirect rules are not a one-time setup. Revisit them whenever the inputs change, and use this short action list as a maintenance routine.

• Before a redesign or replatforming project. Confirm where redirects will live in the new stack and who owns them.
• Before moving hosts, CDNs, or load balancers. Record the current behavior and compare it after cutover.
• When issuing or renewing certificates. Make sure all redirect entry points are still covered.
• When changing DNS providers or nameservers. Verify that the alternate hostname still resolves to the redirect-capable service.
• When updating CMS, reverse proxy, or ingress settings. Proxy trust and base URL behavior can change unexpectedly.
• When seasonal traffic, campaigns, or launches are approaching. Test redirects before demand spikes, not during them.
• When uptime alerts or crawl reports show anomalies. Unexpected spikes in redirect responses, SSL failures, or crawl duplication are good reasons to audit the setup.

A simple repeatable process works well:

1. List your canonical domain choice.
2. Test the four common variants plus one or two deep links.
3. Inspect the number of hops and final URL.
4. Confirm the certificate is valid on every incoming hostname.
5. Check that the application, sitemap, and canonical tags match.
6. Review uptime and SSL monitoring after deployment.

If you document that process once, your future self can reuse it for migrations, SSL changes, hostname updates, and platform upgrades. That is the real value of a good redirect setup guide: it keeps a small configuration detail from becoming a larger availability, trust, or SEO problem later.