How to redirect a root domain to www?

To redirect a root domain such as example.com to www.example.com, you need two things: DNS records that send both names to a server, and an HTTP 301 redirect on that server which tells browsers to go to www. DNS by itself can't redirect anyone. It only translates names into addresses. So you point example.com with an A record (or ALIAS) and www with a CNAME or A record, then add the redirect in your web server, CDN, hosting platform or registrar's forwarding feature, and make sure HTTPS works on both names.

This is one of the most common DNS questions, and the confusion usually comes from expecting a DNS record to do the redirect. In this guide you'll learn why DNS can't redirect, how to set up the records correctly, how to add the redirect in Nginx, Apache, Caddy, Cloudflare and registrar forwarding, how to handle HTTPS, and how to test that the redirect behaves exactly as it should.

Why DNS Can't Redirect

When a browser visits http://example.com/pricing, two separate things happen:

1. DNS lookup: The browser asks for the IP address of example.com.
2. HTTP request: It connects to that IP and sends a request including Host: example.com and the path /pricing.

A redirect is an HTTP response, such as 301 Moved Permanently with a Location: https://www.example.com/pricing header. Only a web server can send that. DNS answers never contain URLs, paths or status codes.

A CNAME record is often mistaken for a redirect. It isn't. A CNAME says "to find this name's address, look up that other name instead". The browser still sends Host: example.com and the address bar still shows example.com. Nothing changes from the visitor's point of view.

There's also a second problem: a CNAME can't be used at the root of a domain. The apex must hold SOA and NS records, and a CNAME can't coexist with any other record. So even if a CNAME did redirect, you couldn't put one at example.com.

Should You Use www or the Root Domain?

Before setting up a redirect, decide which version is canonical, meaning the one you want people and search engines to use. Both work fine for SEO as long as you pick one and redirect the other.

	www.example.com canonical	example.com canonical
DNS flexibility	www can be a CNAME to a CDN or platform	Apex needs A records, ALIAS or CNAME flattening
Cookie scope	Cookies on www don't leak to other subdomains	Cookies set on the apex can be sent to all subdomains
Appearance	Longer	Shorter, cleaner
Common with	Large sites, CDN-heavy setups	Startups, personal sites

This article assumes www is canonical, so the root redirects to www. If you want the reverse, swap the names in the examples.

Step 1: Set Up DNS for Both Names

Both names must resolve to something that can send the redirect. The typical setup is:

example.com.        3600  IN  A      203.0.113.50
example.com.        3600  IN  AAAA   2001:db8::50
www.example.com.    3600  IN  CNAME  example.com.

Here, both names reach the same server, which serves the site on www and redirects the root.

If your site is on a platform that gives you a CNAME target for www, such as sites.platform.example.net, you'll often use:

example.com.        3600  IN  A      198.51.100.10
www.example.com.    3600  IN  CNAME  sites.platform.example.net.

The A record at the apex points to an IP the platform publishes specifically for redirecting or serving root domains. Many hosting platforms, including Vercel and Netlify, document such an IP, and they handle the redirect for you once you mark www as the primary domain in their settings.

If your DNS provider supports ALIAS, ANAME or CNAME flattening, you can point the apex at a hostname instead of an IP. That's handy when the platform doesn't give you a stable IP for the root.

Check that both names resolve:

dig +short example.com A
dig +short www.example.com

203.0.113.50
example.com.
203.0.113.50

Step 2: Add the Redirect

Pick the option that matches where your traffic is handled.

Option A: Nginx

Use a separate server block for the root domain that does nothing but redirect. This example assumes you already have certificates covering both names:

# Redirect HTTP for both names to https://www
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# Redirect HTTPS on the root to https://www
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

# The real site
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example;
    index index.html;
}

$request_uri keeps the path and query string, so example.com/pricing?plan=pro goes to www.example.com/pricing?plan=pro. The http2 on; directive is the current syntax in Nginx 1.25.1 and later. On older versions, use listen 443 ssl http2; instead.

Test and reload:

sudo nginx -t && sudo systemctl reload nginx

Option B: Apache

In the virtual host for the root domain:

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

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    Redirect permanent / https://www.example.com/
</VirtualHost>

Redirect preserves the rest of the path automatically. If you're on shared hosting and can only use .htaccess, use mod_rewrite:

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

Option C: Caddy

Caddy issues certificates automatically for every site address, so the redirect is two short blocks:

example.com {
    redir https://www.example.com{uri} permanent
}

www.example.com {
    root * /var/www/example
    file_server
}

Option D: Cloudflare Redirect Rules

If your domain uses Cloudflare as its DNS provider, you can redirect at Cloudflare's edge without touching your server. The root domain must have a proxied (orange cloud) record so traffic passes through Cloudflare. If the root doesn't need to reach a real server, a common approach is a proxied AAAA record pointing at 100::, which is the IPv6 discard prefix. Cloudflare answers the request and applies the redirect before anything would be sent there.

Then in the dashboard, go to Rules, create a Redirect Rule, and set:

• When incoming requests match: Hostname equals example.com.
• Then: Dynamic redirect, with the expression concat("https://www.example.com", http.request.uri.path).
• Status code: 301.
• Preserve query string: Enabled.

Cloudflare also offers ready-made templates for "Redirect from root to WWW" in the same section.

Option E: Registrar URL Forwarding

Many registrars, including GoDaddy, Namecheap and Porkbun, offer URL forwarding or domain forwarding. You set the root to forward to https://www.example.com as a permanent (301) redirect, and the registrar sets up the DNS record and a redirect server for you.

It's the easiest option when you don't have a server of your own, but check:

• HTTPS support: Some forwarding services only handle http://. A visitor typing https://example.com gets a certificate error if the forwarder doesn't issue a certificate for the root.
• Path forwarding: Make sure example.com/pricing goes to www.example.com/pricing, not the home page.
• Masked forwarding: Avoid "masked" or "framed" options that keep the root URL in the address bar using a frame. They break bookmarking and SEO.

Step 3: Make Sure HTTPS Covers Both Names

The redirect from https://example.com can only happen after a TLS connection is established, which requires a valid certificate for example.com. If your certificate only covers www.example.com, visitors see a security warning before the redirect ever happens.

With Certbot, include both names when issuing:

sudo certbot --nginx -d example.com -d www.example.com

Check which names a certificate covers:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

Step 4: Test the Redirect

Use curl -I to see the status code and destination without following the redirect:

curl -sI http://example.com/pricing?plan=pro | grep -iE '^(HTTP|location)'
curl -sI https://example.com/pricing?plan=pro | grep -iE '^(HTTP|location)'
curl -sI http://www.example.com/ | grep -iE '^(HTTP|location)'

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/pricing?plan=pro
HTTP/2 301
location: https://www.example.com/pricing?plan=pro
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

Then check that the final page returns 200 and that there's only one hop:

curl -sIL https://example.com/ -o /dev/null -w '%{http_code} %{url_effective} redirects=%{num_redirects}\n'

200 https://www.example.com/ redirects=1

A chain like http://example.com → https://example.com → https://www.example.com works, but it adds a round trip. Sending every variant straight to the final URL is cleaner.

301 vs 302 vs 308

Code	Meaning	Use it when
301	Moved permanently	Your canonical redirect. Search engines transfer ranking signals
302	Found (temporary)	Testing, or a redirect you plan to remove
307	Temporary, keep method	Temporary redirects for APIs that receive POST requests
308	Permanent, keep method	Permanent redirects where POST must stay POST

For a root-to-www redirect on a website, 301 is the standard choice. Browsers cache 301 redirects aggressively, so test with a 302 first if you're unsure, then switch to 301 once it's right.

Common Mistakes

1. Trying to redirect with a CNAME: It doesn't redirect, and it isn't allowed at the apex.
2. No certificate for the root: https://example.com shows a warning before the redirect.
3. Losing the path: Every old link lands on the home page. Use $request_uri, {uri} or path-preserving options.
4. Redirect loops: Both blocks redirecting to each other, or a CDN set to "Flexible" SSL sending HTTP to an origin that redirects back to HTTPS. Check with curl -sIL and look for repeated URLs.
5. Missing AAAA: If the root has an AAAA record pointing at an old server, IPv6 visitors may not get the redirect at all.
6. Forgetting HSTS scope: If you send Strict-Transport-Security with includeSubDomains on the root, make sure every subdomain supports HTTPS first.

---

FAQ: Redirecting a Root Domain to www

---

Conclusion

Redirecting a root domain to www takes DNS and HTTP working together. DNS sends both example.com and www.example.com to a server that can respond, and that server returns a 301 redirect that preserves the path. A CNAME record can't do the job, both because it isn't a redirect and because it isn't allowed at the apex.

Choose the option that matches your setup, whether that's Nginx, Apache, Caddy, a Cloudflare Redirect Rule, your hosting platform or registrar forwarding. Make sure your certificate covers both names, test every variant with curl -sI, and confirm that each one reaches the final URL in a single hop.