Pick One Address: Redirect www to Non-www (or Back) With a 301

Pick one address for your site, either example.com or www.example.com, and send every visit to the other one there with a permanent 301 redirect. Google does not prefer either version, so the choice is yours; what matters is that you choose one and point everything at it.

Here is the detail that trips people up: Apache's own copy-paste recipes for this job use the flag [R] with no number, and Apache's documentation says that without a number it sends a 302, which is a temporary redirect. Google's documentation says temporary redirects are not used as a signal that the target should be the canonical URL. So the most common recipe on the internet works in the browser but quietly sends the weaker signal.

By the end of this guide you will have one working rule for your server, a curl check that proves it returns 301, and a short list of fixes for the problems people hit most.

What a www to non-www redirect actually is

Your site can usually be reached under two names: example.com (the "bare" or "apex" domain) and www.example.com (a subdomain called www). To a browser and to Google these are two different hosts, even when they show the same pages.

Think of it like a shop with two front doors on different streets. Customers can find you either way, but the post, reviews and directions get split between two addresses. A redirect is a sign on one door that says "We moved round the corner" and walks the visitor to the other door.

A redirect is the server's reply that says "this page lives at another URL", sent with a status code and a Location header. The status code tells browsers and search engines how long the move is meant to last. Google lists 301 and 308 as permanent, and 302, 303 and 307 as temporary.

Why this matters: Google calls a redirect "a strong signal" that the target should become canonical. A canonical URL is the one version of a page that Google picks to show in search when several URLs carry the same content.

Before you start

Run through this list first. It takes two minutes and saves you from a locked-out site.

• Access: your hosting control panel login (for example cPanel), or SSH access, or someone who has it.
• The file: on Apache hosting this is the .htaccess file in your site's document root, the folder that holds your homepage files.
• DNS: both example.com and www.example.com must already reach your server. If the www name has no DNS record, no visitor ever gets to your redirect. Our guide on A records and CNAME records for a bare domain covers this.
• Certificate: your SSL certificate must cover both names. An HTTPS redirect is only sent after the secure connection is set up, so a certificate that only covers example.com gives a browser warning on https://www.example.com/ before the redirect can happen.
• A terminal with curl: curl is a free command-line tool; if typing curl --version gives an error, install it first.
• A backup: a copy of your current .htaccess file, made in Step 1 below.
• Time: about 15 minutes, plus testing.
• Risk level: low to medium. A typo in .htaccess can make the whole site return an error, but restoring the backup fixes it straight away.

Decide which address wins

There is no SEO winner. Google's documentation on duplicate URLs uses www and non-www versions only as examples and simply says to "pick one of those URLs as your canonical URL."

Pick the version that already gets most of your links and traffic, because that means fewer URLs change. If your business cards, email signatures and old backlinks mostly say www.example.com, keep www. If you are starting fresh, the shorter bare domain is a fine choice.

Quick tip: also decide on HTTPS now. Google prefers HTTPS pages as canonical unless there are certificate problems or conflicting signals, so your final address should be https://example.com/ or https://www.example.com/. The rules below redirect HTTP and the wrong host in one step.

Made-up example: Priya runs a bakery site. Her old printed menus say www.example.com, but her new logo says example.com. She checks her analytics, sees that most visits already land on example.com, and picks that. Her www links keep working because they now redirect, and Google gets one clear signal instead of two competing ones.

Set it up on Apache with .htaccess

.htaccess is a configuration file that Apache reads from your site's folders. mod_rewrite is the Apache module that lets you write redirect rules in it. Apache's own docs say the cleanest method is a Redirect in the server configuration, and to use mod_rewrite when you are limited to .htaccess, which is the normal situation on shared hosting.

Step 1: Find and back up the .htaccess file

In cPanel, open File Manager and go to the folder that holds your site, the document root.

Files that start with a dot are hidden by default. Click Settings, tick Show Hidden Files (dotfiles), then click Save. You should now see .htaccess in the list. If it is not there, your site may not have one yet, and you can create a new file with that exact name.

To back it up, select the file and download it to your computer. If you have SSH, this command makes a dated copy next to the original.

cp .htaccess .htaccess.backup-2026-11-07

Heads up: cPanel's File Manager editor refuses files larger than 1 MB. A normal .htaccess is far smaller, but if yours is huge, download it and edit it locally.

Step 2: Redirect www to non-www

Select .htaccess and click Edit. Put the rules at the very top of the file, above any other rewrite rules such as a WordPress block, so the redirect runs first.

This rule sends any HTTP visit, and any visit to the www name, to https://example.com/ with the same path, using a permanent 301.

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

Replace example.com with your domain in both places, and keep the backslash before each dot in the condition line.

Here is what each part does, in plain words:

• RewriteEngine On switches the rewrite module on for this folder.
• %{HTTPS} is on for secure connections and off otherwise, so the first condition catches plain HTTP.
• [OR] joins the two conditions with "or". Without it, Apache would need both to be true.
• %{HTTP_HOST} is the host name the visitor typed. [NC] makes the match ignore upper and lower case, so WWW.Example.com is caught too.
• ^(.*)$ captures the path. In .htaccess, Apache strips the leading slash before matching, which is why the target is https://example.com/$1 with the slash written in.
• R=301 makes the redirect permanent. L stops processing more rules for this request. NE stops Apache from escaping characters such as # and ? in the target.

Why this matters: putting both checks in one rule means http://www.example.com/menu goes straight to https://example.com/menu in a single hop, instead of hopping to HTTPS first and then to the bare domain.

Step 3: Or redirect non-www to www

If you picked www, use this mirror image. It catches HTTP visits and visits to the bare domain, and sends them to https://www.example.com/.

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

But what if you host subdomains like shop.example.com from the same folder? Matching the exact bare name with ^example\.com$ leaves other subdomains alone. A looser pattern like "anything without www" would also push shop.example.com to www.example.com, which is rarely what you want.

Step 4: Keep multi-domain redirects on an allowlist

If one Apache virtual host or document root serves several domains, add an exact redirect for each approved hostname, or put each redirect in that domain's virtual-host configuration. Do not capture an arbitrary request Host value and copy it into the Location header. On a broad or default virtual host, an unexpected hostname could otherwise become an external redirect target. The exact-host rules above also leave unrelated subdomains alone.

Step 5: Save and test straight away

Save the file in the editor, then run the curl checks in the "How to check it worked" section below before you do anything else. If the site shows an error, restore your backup copy and check the rule for typos.

Quick tip: test in a private browser window too. Browsers remember permanent redirects, so a normal window can keep showing an old result after you fix a rule.

If you can edit the Apache server config

If you manage your own server or VPS, Apache's docs recommend a plain Redirect in a separate virtual host for the name you do not want, with no mod_rewrite at all. A virtual host is a block in the Apache configuration that answers for one or more host names.

This example answers for www.example.com on HTTPS and sends everything to the bare domain. Add your normal certificate lines where shown.

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

Google's redirect documentation lists Redirect permanent as the Apache way to send a permanent redirect. Run the deep-path curl test below to confirm /menu lands on https://example.com/menu. You still need your HTTP (port 80) virtual host to redirect to the same final address. Reload Apache after editing so it picks up the change.

Set it up on Nginx

Nginx does not read .htaccess. You add a small server block for the name you do not want, and use return 301, which is the method Google's docs list for Nginx.

This block answers HTTPS requests for www.example.com and sends them to the bare domain, keeping the full path and query string.

server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate and ssl_certificate_key lines go here
    return 301 https://example.com$request_uri;
}

$request_uri is the full original request, including any ? arguments. There is no slash between example.com and $request_uri because $request_uri already starts with one.

For the reverse direction, swap the names: server_name example.com; and return 301 https://www.example.com$request_uri;. Your main server block then only lists the name you kept.

Heads up: in Nginx, return with only a URL and no code sends a 302. Always write the 301.

If Cloudflare sits in front of your site

Cloudflare's SSL/TLS encryption mode decides how Cloudflare talks to your server, and one setting in particular clashes with the rules above.

In Flexible mode, visitors reach Cloudflare over HTTPS, but Cloudflare reaches your server over plain HTTP. Your server then sees %{HTTPS} as off on every request, so the rule in Step 2 redirects to HTTPS forever. Cloudflare's docs say redirect loops happen in Flexible mode when the origin redirects all HTTP requests to HTTPS.

The fix Cloudflare gives is to remove the HTTPS redirect from your server, or switch to Full or Full (strict), which need an SSL certificate on your server. Our guide to Cloudflare Full (strict) without redirect loops walks through it.

Why this matters: redirects can come from your server and from Cloudflare rules at the same time. Cloudflare's docs point out that conflicting redirect rules also cause loops, so keep the www rule in one place.

Back up the redirect with matching signals

The redirect does the heavy lifting, but Google says canonical signals add up, and it warns against pointing different methods at different URLs.

Each page should carry a self-referencing canonical tag, meaning a tag in the page <head> that names the page's own preferred URL. Google says to use absolute URLs, so the tag on your menu page looks like this.

<link rel="canonical" href="https://example.com/menu" />

Most CMS tools and SEO plugins write this tag for you. After you change your preferred host, open a page, view its source, and check the tag shows the new host.

Your sitemap should list only the chosen address. Google calls the sitemap a weak signal, but a sitemap full of the old host sends a mixed message. Update it, then resubmit it as shown in our guide to submitting a sitemap in Google Search Console.

Quick tip: also update internal links in menus, footers and templates. Google says linking consistently to the canonical URL helps it understand your preference, and it saves every visitor a redirect hop.

How to check it worked

curl is a command-line tool that fetches URLs. The -I option asks for the headers only, which is all you need here.

This command checks the www address over HTTPS.

curl -I https://www.example.com/

If you chose the bare domain, the first line should show a 301 and the Location header should name your bare domain, like this (other header lines will vary).

HTTP/2 301
location: https://example.com/

Your first line may say HTTP/1.1 301 Moved Permanently instead; the version does not matter, the 301 does. Header names may be in lower case, which is normal.

Next, check that the final address answers with a normal page and no redirect.

curl -I https://example.com/

You want to see 200 on the first line and no location header. If you see another 301 here, something is redirecting your chosen address too, and you are on the way to a loop.

Now test the other combinations, because the HTTP versions are where most mistakes hide. Each of these should return one 301 pointing straight at your final address.

curl -I http://www.example.com/
curl -I http://example.com/
curl -I https://www.example.com/menu?ref=card

The last one checks that a deeper path and a query string survive the redirect. The location header should keep /menu on the new host.

Troubleshooting

The browser says ERR_TOO_MANY_REDIRECTS

Symptom: Chrome shows ERR_TOO_MANY_REDIRECTS, or Firefox says "The page isn't redirecting properly".

Likely cause: two rules fight each other. Common pairs are a www rule plus a CMS setting that forces the other host, or Cloudflare Flexible mode plus an HTTPS rule on your server.

Fix: run curl -I on each address and look at where each location points. If https://example.com/ redirects back to www, find the second rule. If your CMS has a setting for the site address, make sure it uses the host you chose. With Cloudflare, switch to Full or Full (strict).

curl shows 302 instead of 301

Symptom: the redirect works, but the first line of the curl -I output shows 302.

Likely cause: the rule uses [R] or [L,R,NE] without a code. Apache's flag documentation says a 302 is used by default when no code is given.

Fix: change the flag to [L,R=301,NE]. In Nginx, make sure the line reads return 301 and not return with just a URL.

The whole site shows a 500 error after saving

Symptom: every page shows a server error right after you edit .htaccess.

Likely cause: a typo, such as a missing quote or bracket, or the rewrite module is not available in your folder. Apache's docs say per-directory rewrites need RewriteEngine On and the FollowSymLinks or SymLinksIfOwnerMatch option enabled.

Fix: restore your backup copy first so the site is back up. Then add the rule again carefully, copying it exactly. If it still fails, ask your host whether mod_rewrite is allowed in .htaccess.

The www address shows a certificate warning

Symptom: curl -I https://www.example.com/ fails with a certificate error, or the browser shows a privacy warning before any redirect.

Likely cause: the certificate covers example.com but not www.example.com. The secure connection fails before the server can send the redirect.

Fix: issue or reissue the certificate so it covers both names, through your control panel's SSL section or your host. Make sure DNS for both names points at the server first.

The redirect drops the page path

Symptom: https://www.example.com/menu lands on the homepage instead of /menu.

Likely cause: the target is missing $1 in Apache, or $request_uri in Nginx.

Fix: compare your rule line by line with the examples above. Then rerun the deep-path curl test.

The rule does nothing at all

Symptom: curl -I https://www.example.com/ returns 200, with no redirect.

Likely cause: the rule sits below another rule that ends processing with [L], the file is in the wrong folder, or the host name pattern has a typo. On Nginx, the www name may still be listed in your main server block.

Fix: move the rule to the top of .htaccess, confirm the file is in the folder that serves your homepage, and check your domain spelling in the condition.

When to ask your host or a developer

Ask for help if you cannot see or edit .htaccess, if your host runs Nginx and you have no access to its configuration, or if the site sits behind a proxy or CDN you do not control. Also ask if your site is large and has used both hosts for years, so someone can check analytics and Search Console after the change.

Security note: never paste your control panel password into a support chat or email. Give your host the domain and the result of the curl checks instead.

The one message worth forwarding

Copy this to your developer or host, and change the domain and the chosen version.

Hi, please make https://example.com the only address for our site. Every request to www.example.com, and every plain HTTP request, should get a single 301 redirect straight to https://example.com with the same path and query string. Please check that https://example.com/ returns 200 with no redirect, that the SSL certificate covers both names, and that canonical tags and the sitemap use https://example.com. A curl -I on each version before and after would be great. Thanks!

One address, one permanent 301, and every other signal pointing the same way: that is all Google needs to stop splitting your site in two.