How to Redirect non-www to www (and www to non-www)

Last updated: October 2026

Most websites can be reached at two addresses: example.com and www.example.com. If both load the same pages, search engines see two copies of every URL, your analytics get split, and visitors can run into SSL or login cookie problems.

The fix is simple: pick one version and permanently redirect the other to it. This guide shows how to redirect non-www to www (and www to non-www) on Apache, LiteSpeed, Nginx, cPanel, Cloudflare and WordPress, then how to test it and avoid the usual mistakes.

Quick answer

1. Pick one canonical host: www.example.com or example.com. Either is fine.
2. Make sure both hostnames work: both need DNS records, and your SSL certificate must cover both.
3. Add a 301 (permanent) redirect from the other host to the one you chose, keeping the page path and query string.
4. Go to HTTPS in the same step: http://example.com should land on https://www.example.com in one hop, not through a chain of redirects.
5. Update everything else: WordPress URLs, internal links, canonical tags, your XML sitemap and Google Search Console.

www vs non-www: which should you choose?

For SEO, neither one wins. Google doesn’t give a ranking preference to either version. Its guidance is to pick one URL as the canonical and redirect the duplicates to it. Google removed the old “preferred domain” setting from Search Console in 2019, so redirects, canonical tags and sitemaps are now how you tell Google which host you want.

The real differences are technical:

If your site is already established, keep the host Google is already indexing. Switching later changes every URL on the site, and Google notes that search visibility can fluctuate temporarily while it recrawls after a move like that.

Before you start: DNS and SSL for both hostnames

A redirect can only run if the visitor actually reaches your server first. Check these three things before you touch any code:

• DNS: both example.com (an A or AAAA record) and www.example.com (an A record, or a CNAME pointing to example.com) must point to your server or CDN. If www has no DNS record, people who type it get an error instead of a redirect.
• SSL certificate: the certificate must cover both example.com and www.example.com. If it only covers one, visitors to the other see a browser security warning before the redirect can happen. Free certificates such as Let’s Encrypt can include both names in one certificate.
• Backup: download a copy of your .htaccess file or server config so you can roll back in seconds if something breaks.

Method 1: Apache .htaccess (shared hosting, cPanel)

On most shared and cPanel hosting, you add the redirect to the .htaccess file in your site’s root folder (usually public_html). Open it with cPanel File Manager or FTP and put the rules at the very top, above any # BEGIN WordPress block.

Redirect non-www to www (with HTTPS, in one hop)

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

Redirect www to non-www (with HTTPS, in one hop)

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

Replace example.com with your own domain (keep the backslash before each dot). Here is what the rules do:

• The first condition limits the rule to your domain, so other subdomains or addon domains that share the same folder aren’t affected.
• The next two conditions match if the request is plain HTTP or uses the host you don’t want.
• The rule sends a 301 straight to the final HTTPS address, keeping the page path. The query string (for example ?utm_source=…) is carried over automatically.

We tested both rule sets on Apache 2.4. Every combination (http or https, www or non-www) returns a single 301 to the final HTTPS URL with the path and query string intact.

Behind Cloudflare or a load balancer? If SSL ends at the proxy, Apache may always see the request as HTTP, which causes a redirect loop. In that case replace the %{HTTPS} off line with RewriteCond %{HTTP:X-Forwarded-Proto} !https [OR], or let the proxy handle the HTTPS part (see the Cloudflare section below).

If you control the Apache server config

The Apache documentation says the cleanest approach doesn’t need mod_rewrite at all: give the unwanted host its own virtual host with a simple Redirect. For example, to make www the canonical host:

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

<VirtualHost *:443>
    ServerName example.com
    # SSLEngine, SSLCertificateFile and SSLCertificateKeyFile lines go here
    Redirect permanent / https://www.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    # your normal site configuration
</VirtualHost>

Redirect permanent keeps the rest of the path, so http://example.com/about/ goes to https://www.example.com/about/.

Method 2: LiteSpeed

LiteSpeed Web Server (the Enterprise edition used by many cPanel hosts) is a drop-in replacement for Apache and reads .htaccess rewrite rules, so the Apache rules above work as they are. Just paste them at the top of .htaccess.

OpenLiteSpeed, the free edition, is different. It only reads .htaccess if “Auto Load from .htaccess” is enabled in the WebAdmin console, and you must restart the server after changing rewrite rules.

Method 3: Nginx server blocks

Nginx doesn’t use .htaccess. Add separate server blocks in your site config instead. Avoid if statements for this. A dedicated server block with return 301 is simpler and faster.

Redirect non-www to www

# All HTTP traffic (both hosts) goes to https://www in one hop
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# HTTPS non-www goes to HTTPS www
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    return 301 https://www.example.com$request_uri;
}

# The canonical site
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    # root, location blocks, etc.
}

For www to non-www, swap the hostnames: send www.example.com to https://example.com$request_uri and serve the site from the example.com block. Run nginx -t to check the syntax, then reload Nginx. $request_uri keeps both the path and the query string.

Method 4: cPanel Redirects tool

If you’d rather not edit files, cPanel has a Redirects tool in the Domains section:

1. Set Type to Permanent (301).
2. Pick your domain and leave the path box empty.
3. In Redirects to, enter the full target, including the protocol, for example https://www.example.com/.
4. Choose the www option that matches your goal (Only redirect with www., Redirect with or without www. or Do Not Redirect www.). Never redirect a host to itself, or you’ll create a loop.
5. Tick Wild Card Redirect so each page goes to the same page on the new host instead of the homepage, then click Add.

Two cautions. cPanel writes these rules at the bottom of .htaccess, and cPanel’s own documentation notes that apps such as WordPress may ignore them. It also doesn’t combine the HTTPS step. For a WordPress site, the hand-written rules in Method 1 are more reliable. For HTTPS on its own, use the Force HTTPS Redirect option under Domains.

Method 5: Cloudflare Redirect Rules

If your DNS is proxied through Cloudflare (the orange cloud), you can redirect at Cloudflare’s edge before traffic reaches your server. Use Redirect Rules (called Single Redirects in Cloudflare’s docs). The older Page Rules “Forwarding URL” setting is legacy, and Cloudflare is migrating it to Redirect Rules, so don’t build new redirects there.

1. In the Cloudflare dashboard, open Rules > Overview, then Create rule > Redirect Rule. Templates are available for common cases.
2. For non-www to www, match the wildcard request URL https://example.com/* and set the target URL to https://www.example.com/${1}.
3. For www to non-www, match https://www.* and set the target to https://${1}.
4. Choose status code 301, keep Preserve query string on, and deploy.

The hostname you redirect from must have a proxied DNS record in Cloudflare. These patterns match HTTPS requests, so also turn on Always Use HTTPS (SSL/TLS > Edge Certificates) to upgrade plain HTTP visits. Finally, set SSL/TLS encryption to Full (strict) if your server has a valid certificate. Cloudflare’s Flexible mode combined with an HTTPS redirect on your server causes the classic “too many redirects” loop.

Method 6: WordPress settings and plugins

WordPress has its own idea of your site address, and it must match the host your server redirects to. Otherwise the server and WordPress will bounce visitors back and forth.

1. Go to Settings > General.
2. Set both WordPress Address (URL) and Site Address (URL) to your chosen version, for example https://www.example.com.
3. If these fields are greyed out, the values are hard-coded as WP_HOME and WP_SITEURL in wp-config.php. Edit them there.

WordPress also redirects page requests from the other host to the Site Address with a 301 on its own. That only covers URLs that WordPress handles, though, not images or other static files, and it won’t always do the HTTPS step in the same hop. Treat it as a safety net and keep the server-level redirect.

Plugins such as Redirection or the redirect managers in SEO plugins are great for individual page redirects. For a site-wide host redirect, server level (Methods 1 to 5) is faster and catches every request. After changing hosts, run a search-and-replace on the database so old internal links and image URLs use the new host. This also prevents mixed content warnings.

How to test your redirect

Test all four starting points: http://example.com, http://www.example.com, https://example.com and https://www.example.com. Also test a deep URL with a query string, not only the homepage.

1. Use curl

curl -IL http://example.com/some-page/?ref=test

The -I flag shows only headers, and -L follows redirects. A good result shows one 301 response with a Location: header pointing to the final HTTPS URL, followed by 200 OK. If you see two or more redirects in a row, you have a chain. If you see 302, it’s a temporary redirect.

2. Check in a browser and with a redirect checker

Open each variant in a private window (browsers cache 301s, so a normal window can hide changes). The DevTools Network tab with “Preserve log” ticked shows each hop. An online redirect checker gives you the same information if you prefer not to use the command line.

3. Confirm it in Google Search Console

• Use a Domain property, which automatically includes www and non-www on both http and https.
• Run URL Inspection on a few canonical URLs and confirm Google sees them as indexable, with the canonical you expect.
• In the Page indexing report, the non-preferred URLs will move to Page with redirect. That’s expected: these redirecting URLs aren’t indexed, and the target pages are indexed instead.
• Submit an XML sitemap that lists only canonical-host URLs. You don’t need the Change of Address tool for a www/non-www switch on the same domain.

New to Search Console? Our Google Search Console walkthrough for beginners covers these reports step by step.

4. Update everything that still uses the old host

• Canonical tags: each page should have a self-referencing rel="canonical" on the chosen host.
• Internal links, menus, image URLs and hreflang tags.
• XML sitemap, robots.txt sitemap line, Google Business Profile, social profiles, ad landing pages and email signatures.

Common mistakes to avoid

• Redirect loops: usually caused by conflicting rules, for example the server forcing www while WordPress’s Site Address is non-www, or Cloudflare Flexible SSL combined with an HTTPS redirect on the server.
• Redirect chains: http://example.com → https://example.com → https://www.example.com is two hops. Google’s crawler follows up to 10 hops, but every extra hop slows visitors down. Combine host and HTTPS into one rule like the examples above.
• Using a 302 instead of a 301: Google treats a 301 (or 308) as a strong signal that the target should be canonical, and a 302 (or 307) only as a weak one. Some plugins and control panels default to 302, so double-check.
• Sending every page to the homepage: always keep the path, so /services/ lands on /services/ on the new host.
• SSL that covers only one hostname: https://example.com shows a security warning before the redirect can even run.
• Mixed content: old http:// image, script or CSS links trigger browser warnings after you move to HTTPS. Update them in the database and theme.
• HSTS surprises: once browsers receive a Strict-Transport-Security header, they refuse plain HTTP for that host until it expires. With includeSubDomains it also applies to every subdomain, so make sure all of them support HTTPS first. If you plan to submit to the HSTS preload list, its rules require HTTP to redirect to HTTPS on the same host first. For a preloaded domain, http://example.com → https://example.com → https://www.example.com is the expected pattern, and that’s fine.
• Removing the redirect later: keep it permanently. Old links and bookmarks will keep using the other host for years.

FAQ

Is www or non-www better for SEO?

Neither. Google doesn’t prefer one over the other. What matters is choosing one, redirecting the other with a 301, and using the chosen host consistently in links, canonicals and sitemaps.

Should I use a 301 or a 302 redirect?

Use a 301 (or 308). It tells search engines the move is permanent, and Google uses it as a strong canonical signal. A 302 is meant for temporary moves and is only a weak signal.

Will I lose rankings if I add the redirect?

If you redirect to the host Google already indexes, you’re only cleaning up duplicates and there’s little to lose. If you switch to the other host, expect some temporary fluctuation while Google recrawls. A clean one-hop 301 on every URL keeps that short.

How long should I keep the redirect?

Permanently. Google’s site move guidance says to keep redirects as long as possible, generally at least a year. For a www/non-www redirect there’s no reason ever to remove it.

Do I need to redirect both HTTP and HTTPS?

Yes. All four variants (http and https, www and non-www) should end on the same single HTTPS address, ideally in one hop.

Need a hand?

Redirect rules are small, but one typo can take a site offline or cause a loop. If you’d rather not edit server files yourself, our dedicated webmasters can set up and test the redirect, SSL and Search Console for you. Every Ninja Softs hosting plan includes free SSL, and if you’re planning a bigger rebuild, see our website development services.