www vs apex domain: which to use and how to redirect

Pick one of example.com or www.example.com, serve the site on that one, and answer every request for the other with a permanent redirect to it. Which of the two you pick matters much less than picking at all. A site that answers on both without redirecting is two sites as far as caches, cookies, analytics and search engines are concerned, and the day that becomes obvious is usually the day somebody logs in on one host and is logged out on the other.

There is one real technical difference between them, and it is not a matter of taste: www.example.com is an ordinary subdomain and can be a CNAME, while example.com is the apex of the zone and cannot. Everything else in the argument - which looks better, which is shorter, which is more "modern" - is preference. This post covers the constraint, the choice, the records, the redirect, the certificate, and the four ways the redirect goes wrong.

What apex and www actually mean#

The apex, also called the root, the naked domain or the zone apex, is the name you registered with nothing in front of it: example.com. It is special because the zone's own administrative records live there - the SOA record that says which nameserver is authoritative and how the zone ages, and the NS records that list the nameservers. Those are always present, and they are the source of the restriction below.

www is a subdomain like any other. It has no special status in DNS, in HTTP or in any browser. It is a convention left over from the era when one organisation's machines were www, ftp, mail and news, and it survived because it turned out to be useful: a name with a label in front of it can be pointed at anything, including a name owned by somebody else.

Browsers hide the difference. Chrome, Safari and Edge all strip www. and https:// from the address bar display, so most visitors never see which one they are on. That is an argument for not agonising over the aesthetics, and an argument for making sure both work - people still type the one they remember.

Why you cannot put a CNAME at the apex#

A CNAME record says "this name is an alias for that name, go and look there instead". The DNS specification is strict about it: if a name has a CNAME, it may have no other records of any type. That rule exists because a resolver that finds a CNAME stops looking at this name entirely and restarts at the target.

The apex always has SOA and NS records. So the apex can never have a CNAME. Authoritative servers that accept one anyway produce a zone that breaks in ways that are hard to diagnose: mail stops being delivered because the MX record is invisible behind the alias, or the delegation itself disappears.

This matters because a lot of infrastructure only gives you a hostname, not an address. A load balancer, an object-storage website endpoint, a platform-as-a-service and most CDNs hand you something like d1a2b3c4.cloudfront.net and reserve the right to change the addresses behind it whenever they like. A subdomain can CNAME to that. The apex cannot, so vendors invented three workarounds:

• CNAME flattening - the DNS provider stores what looks like a CNAME at the apex, resolves it themselves, and answers queries with the resulting A and AAAA records. Cloudflare does this.
• ALIAS or ANAME records - the same idea under a different name, offered by several managed DNS providers. Same behaviour: alias in, addresses out.
• Provider-native alias records - Route 53's alias record type, which points at the provider's own resources and is resolved internally.

All three are a feature of your DNS host, not of DNS. If you move the zone to a provider that does not offer one, an apex that relied on it breaks. That is the single strongest practical argument for making www the canonical host: it keeps the apex a simple redirect you can serve from anywhere, and leaves the real name free to be a CNAME.

If your site runs on a fixed address - a server, a VDS, a container on a panel - none of this applies. You write an A record at the apex with the address in it, and you are done. DNS records explained covers the record types themselves, and nameservers vs DNS records covers who is holding the zone in the first place.

Choosing the canonical host#

Neither choice will affect your search rankings. Google has said as often as it says anything that the two are equivalent as long as one of them is consistently canonical. The real differences are these.

The cookie point is the one that bites later. A cookie set on example.com with a Domain attribute is sent to api.example.com, blog.example.com and every other subdomain, including ones you hand to a third party. If you ever host something you do not fully control on a subdomain, an apex session cookie travels there too. Serving the site on www and keeping the apex as a redirect keeps that blast radius small.

On the other side: the apex is shorter, it is what people write on a business card, and if your site will always live at a fixed address the CNAME restriction never comes up. For a small shop, a blog or an application on a single server, the apex is a perfectly good choice.

Pick, write it down, and do not change it later on a whim. Changing the canonical host after launch means a redirect that stays in place indefinitely, links in the wild pointing at the old host, and a search index that takes weeks to catch up.

The records, both ways#

Say your server's address is 203.0.113.10. Both hosts must resolve before anything else works, including the certificate. There is no arrangement in which the non-canonical host is left unresolved.

example.com.        300   IN   A       203.0.113.10www.example.com.    300   IN   CNAME   example.com.

example.com.        300   IN   A       203.0.113.10www.example.com.    300   IN   A       203.0.113.10

Both are valid. In the second one you can also make www a CNAME to a platform hostname and leave the apex pointing at a small server whose only job is to redirect - that is the arrangement large sites end up with.

The TTL is worth a thought before a move rather than after. A 300 TTL means a resolver forgets the answer within five minutes; 86400 means a day. Set it low a day or two before you change anything, and raise it again once the new address is proven. This is the same discipline described in migrating WordPress to a new host, and it is the difference between a cutover measured in minutes and one measured in "some people still see the old site".

Redirecting, in one hop, with the right status code#

The redirect belongs in the web server or the reverse proxy, in front of the application. Use 301 Moved Permanently. Browsers and search engines cache it, which is exactly what you want for a host that will never move back.

server {    listen 443 ssl;    server_name www.example.com;    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;    return 301 https://example.com$request_uri;}

$request_uri is what carries the path and query string across, so https://www.example.com/shop?page=2 lands on https://example.com/shop?page=2 rather than the home page. A redirect that drops the path is worse than no redirect: every deep link from every other site on the internet arrives at your front door instead of the page it was promised.

On Apache, the same thing in .htaccess, which is what you get on most shared PHP hosting:

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

Two details separate a correct redirect from a slow one:

1. One hop, not three. http://www should go straight to https://example.com/path, not to https://www and then to https://example.com. Each extra hop is a full round trip, including a TLS handshake on the ones that are already encrypted. Write the rules so that the first response carries the final URL.
2. Redirect before the application runs. A PHP or Node application deciding to redirect has already paid for a database connection and a session lookup. The proxy or web server can answer in microseconds.

If the application is the only thing that can do it - WordPress, for instance, redirects to whatever is in its siteurl and home options - then set those to the canonical host and let it. Just do not have both the server and the application redirecting, because that is how loops start.

308 Permanent Redirect exists and is technically stricter: it forbids changing the method, where 301 historically allowed a POST to become a GET. For a canonical-host redirect on a normal website, 301 is the safe and expected choice. Use 302 only while you are testing, because a 301 you got wrong is cached in browsers you cannot reach.

The certificate has to cover both names#

A redirect from https://www.example.com can only happen after the browser has completed a TLS handshake with something that holds a certificate valid for www.example.com. If the certificate covers only the apex, the visitor gets a full-page security warning and never reaches your redirect. This is the most common half-finished setup on the internet: the apex works, www throws a certificate error, and the owner has no idea because they never type it.

So the order is: both names resolve to your server, then the certificate is issued for both names, then the redirect goes in.

Let's Encrypt follows redirects while validating an http-01 challenge, so a www to apex redirect does not usually block issuance. What does block it is a name that resolves somewhere else - a leftover record at an old host, or a www that was never created. HTTPS and Let's Encrypt explained goes through the validation itself.

On RE:NODE, app and web plans include a reverse-proxy slot: you point an A record at the address shown in it, and the certificate is issued and renewed automatically inside a 21-day window. Add both names there, not just the one you use. We do not register domains and we do not host DNS zones, so the records themselves are made wherever your zone lives - your registrar, or whichever DNS provider your nameservers point at. Pointing a domain at your server has the walkthrough.

Telling everything else which host is real#

The redirect handles visitors. A few other things need to be told separately, and skipping them is how you end up with two versions of every page in a search index.

• Canonical link elements. Every page should declare its own canonical URL on the chosen host. Most content systems generate this from a single site-URL setting, so fixing that setting fixes every page.
• The sitemap. Absolute URLs in sitemap.xml must use the canonical host. A sitemap that lists the other one is a direct instruction to crawl the redirect.
• Internal links. Prefer root-relative links (/about) so they cannot point at the wrong host. Absolute links hardcoded to http://www. are the usual source of a redirect on every click.
• Search Console and analytics. Register both hosts, or use a domain property that covers the whole zone, so you can see traffic that is still arriving at the old one.
• Open Graph and structured data. Image and page URLs in metadata are absolute by necessity. If they point at the non-canonical host, every share fetches through a redirect.

Redirect loops and the other ways this breaks#

The proxy loop. Your reverse proxy terminates TLS and forwards plain HTTP to the application. The application sees http://, decides the visitor must be upgraded, and issues a redirect to https://. The proxy terminates that too, forwards plain HTTP again, and the browser gives up after twenty hops with ERR_TOO_MANY_REDIRECTS. The fix is to make the application trust the proxy's X-Forwarded-Proto header instead of looking at its own socket - in WordPress that means setting $_SERVER['HTTPS'] from the header in wp-config.php, in Express it is app.set('trust proxy', 1), in Laravel it is the trusted-proxies middleware. What a reverse proxy does explains the header.

The two-rulesets loop. The web server redirects www to apex, and the application, still configured with the old site URL, redirects apex back to www. Each is correct in isolation. Decide which layer owns the redirect and disable it in the other.

HSTS applied too early. Strict-Transport-Security: max-age=31536000; includeSubDomains tells a browser to refuse plain HTTP for this host and everything under it, for a year, with no way for you to take it back. Add includeSubDomains only once every subdomain you own has a working certificate, and submit to the preload list only when you are certain, because removal from it takes months.

Mixed content after the move. Pages loading scripts or images from http://www.example.com hardcoded in a database. A search-and-replace across the content is the standard fix; do it on a copy first, and take a backup you have actually restored before you start.

Cookies that do not follow. If sessions were set on www and you move the canonical host to the apex, everybody is logged out once. Harmless, but tell people before they file a ticket about it.

Caches and CDNs keyed by host. A cache in front of your site treats the two hosts as separate keys. After the change, the non-canonical key holds copies of real pages until they expire. Purge it. HTTP caching headers explained covers what is being keyed and for how long.

FAQ#

Does www or apex affect SEO?

No, as long as one is consistently canonical and the other redirects to it with a 301. What does affect search is serving the same pages on both hosts with no redirect and no canonical link, because the crawler has to guess which one to index and your signals are split across two.

Can I just use a CNAME at the apex if my provider allows it?

If the provider offers CNAME flattening, ALIAS or ANAME, yes - they answer with addresses, so the zone stays valid. A provider that stores a literal CNAME at the apex and serves it as one is producing a broken zone, and mail delivery is usually the first casualty. Check what the provider actually returns with dig example.com ANY before trusting it.

Should the redirect be 301 or 302?

301 for a canonical host, because it is permanent and you want it cached. 302 while you are testing, so a mistake does not stick in browsers for months. Once you are confident, switch to 301 and do not switch back.

Do I need a certificate for the host I am redirecting away from?

Yes, if anyone will ever reach it over HTTPS - which they will, because browsers try HTTPS first and other sites link with https:// prefixes. A redirect cannot be delivered until the handshake succeeds, so the certificate has to cover both names.

What about a domain with no www at all?

Perfectly valid. Create the apex record, leave www out of the zone, and visitors who type it get a resolution failure rather than an error page. Most people prefer to create www and redirect it, because typing it is an old habit and a failure looks like your site is down.

Where do I do all this if my host does not give me a DNS editor?

At whoever answers for your zone, which is usually your registrar by default. We do not host DNS zones here, so on RE:NODE the records are made in your registrar's or DNS provider's panel, and only the address you point them at comes from us.