AI AI Tools Guidebook
Indie Dev & Website Building

Root Domain or www: How to Pick (2026)

Root vs www is cosmetic until both serve the same content and split your SEO. Use this verified DNS table (Vercel, Firebase, Cloudflare), redirect config, and curl checks to lock it down in one pass.

Published: Updated: Author: AI Productivity Guide Team 🌐 查看中文版本

As of June 2026 the www vs root-domain choice is almost entirely cosmetic. The damage starts the moment you serve the same pages on both yoursite.com and www.yoursite.com with no redirect between them: Google now sees two sites, and link authority that should stack on one URL gets split across two. The decision is small. The execution has to be exact, because DNS, your host’s primary-domain setting, the canonical tag, and Search Console all have to agree.

TL;DR

  • Pick one host as canonical. For new indie sites the apex (yoursite.com) wins on typing habits and is shorter; keep www only if it already has backlinks.
  • 301 (or 308) the other version to it. Google treats both as a strong permanent canonical signal; the only failure that hurts is no redirect at all, or mixed signals.
  • Aim for a single redirect hop. http://www should land on https://apex directly, not bounce through http://apex first.
  • Set the same canonical tag on every page, verify the hop with curl -sI, and register a Search Console Domain property so apex and www are covered together.

Background

Historically www was a hostname convention pointing at the web server, while the root domain might serve mail, FTP, or other services. Modern hosting collapses that distinction: both names can point at the same web service. What matters now is picking one as canonical and making the other 301-redirect to it, so search engines, browsers, and copy-paste users all converge on a single URL.

One real technical asymmetry remains. You can always put a CNAME on a subdomain like www, but most registrars forbid a CNAME at the apex (@). Hosts that hand you a CNAME target (Vercel, Netlify) work around this with provider-specific A records or Cloudflare’s CNAME flattening. That makes the apex slightly more fiddly to set up, not worse to live with.

How to tell

  • Both https://yoursite.com and https://www.yoursite.com load your site (no redirect between them).
  • Search Console shows two properties or split impressions for the same content.
  • Backlinks point at a mix of both versions.
  • You see canonical tag on one version pointing at the other.
  • dig +short returns IPs for both apex and www independently.

How each host handles the redirect

You rarely have to write the redirect yourself anymore. Here is who does it for you, as of June 2026:

HostBuilt-in apex↔www redirectWhat you configure
VercelYes, automaticAdd both domains, mark one Primary; the other auto-301s
Firebase HostingYes, opt-in checkboxIn the connect-domain wizard, check “redirect all requests to a second domain”
Cloudflare PagesYes, via Redirect RulesAdd a single Redirect Rule (see step 4)
NetlifyYes, automaticSet the primary domain; the alias 301s
Plain VPS / nginxNoWrite a server block that 301s the other host

Quick verdict

Pick one. Most modern indie sites pick the apex (yoursite.com) because it is shorter and matches how people type a domain. Set up a 301 redirect from the other version to your chosen one, then make DNS, the host’s primary-domain setting, and the canonical tag all agree.

Before you start

  • Lower DNS TTL to 300s 24 hours before the change.
  • Choose canonical (apex or www) — write it down.
  • Know who runs your DNS (registrar vs Cloudflare).

Step by step

  1. Decide and write it down. Default to apex for new indie sites. Stay with www if you already have an established www site with backlinks.

  2. Add DNS records — both names, ultimately resolving to the same place. Vercel (apex as primary), as of June 2026:

Type   Name        Value                   TTL
A      @           76.76.21.21             300
CNAME  www         cname.vercel-dns.com.   300

Newer Vercel projects are issued a project-specific CNAME target like xxxxxxxx.vercel-dns-016.com instead of the shared cname.vercel-dns.com. The old value still resolves, but run vercel domains inspect yoursite.com to confirm the exact record your project expects before you paste it.

Firebase Hosting gives you the apex IP 199.36.158.100 plus an AAAA record for IPv6. Point both @ and www at the same A record; Firebase shows the verification value to use after you add the TXT record:

Type   Name        Value                   TTL
A      @           199.36.158.100          300
A      www         199.36.158.100          300
AAAA   @           2620:0:890::100         300

  1. In your host, mark one as primary. Vercel: Project → Domains → mark yoursite.com as Primary, and www.yoursite.com auto-redirects with a 301. Firebase: in Hosting → Add custom domain, check the box to “redirect all requests to a second specified domain” so apex and www consolidate onto one.

  2. If your host does not auto-redirect (Cloudflare-fronted only), add a Page Rule or Redirect Rule:

# Cloudflare Bulk Redirects (CSV import)
source_url,target_url,status,preserve_query_string,preserve_path_suffix
https://www.yoursite.com/*,https://yoursite.com/$1,301,true,true

Or in Cloudflare’s Redirect Rules UI:

When incoming requests match
  Hostname equals  www.yoursite.com
Then
  Type:         Static
  URL redirect: https://yoursite.com${uri.path}${uri.query}
  Status code:  301
  Preserve query string: ON
  1. Set canonical tag on every page pointing at the chosen version. In an Astro layout:
<link rel="canonical" href={`https://yoursite.com${Astro.url.pathname}`} />

Verify after deploy:

grep -R 'rel="canonical"' dist | grep -v 'https://yoursite.com' | head
# any output is a leak to the non-canonical version

  1. In Search Console, add the chosen version as the property. Use Domain property (TXT) so both apex and www are covered, then make sure the URLs you submit in the sitemap are the canonical apex.

  2. Verify the redirect with curl:

curl -sI https://www.yoursite.com         | head -3
# HTTP/2 301
# location: https://yoursite.com/

curl -sI http://yoursite.com              | head -3
# HTTP/1.1 301 Moved Permanently
# Location: https://yoursite.com/

curl -sI https://yoursite.com             | head -3
# HTTP/2 200

The chain you want is at most one hop: http://www → https://apex should not pass through http://apex or https://www first. Google can follow up to roughly ten hops, but it prefers a single hop and SEO practice is to stay under three, so collapse any chain you find.

  1. Update controllable backlinks (social bios, GitHub README, email signatures). 301s handle search-engine-visible inbound links; humans see the redirect blink.

Implementation checklist

  • DNS has records for both apex and www, ultimately to the same host.
  • Host’s “primary domain” matches your chosen canonical.
  • curl -sI shows 301 from non-canonical to canonical in one hop.
  • Canonical tag on every page references the chosen version.
  • Search Console Domain property + sitemap uses the canonical.

After-launch verification

  • dig +short A yoursite.com and dig +short A www.yoursite.com both resolve.
  • Lighthouse on both URLs — one gets 200, the other shows the redirect.
  • Search Console Performance page shows traffic only on the canonical version after 4 weeks.

Common pitfalls

  • Serving the same content on both apex and www with no redirect. Google sees duplicate content and splits authority.
  • Pointing apex and www at different builds (one to staging, one to prod). This shows up when a redirect is half-configured.
  • Choosing www then following DNS provider docs that assume the apex, which produces broken records.
  • A mismatched canonical tag: the page is on the apex but the tag says www, or vice versa. That inconsistency makes Google second-guess your chosen URL.
  • Submitting one version to Search Console while the canonical tag points at the other. Pick one and use it everywhere.
  • A multi-hop redirect (http://www → http://apex → https://apex). It still works, but each extra hop is slower and weakens the signal. Collapse it to one hop.

FAQ

  • Does Google care which one I pick? No. Google’s own guidance is to pick one and redirect the other; it has no preference between apex and www. Mixed signals, not the choice itself, are what hurt.
  • 301 or 308 for the redirect? Either works. Google treats both as a strong permanent canonical signal. Use 301 unless your framework defaults to 308 (some do for HTTPS upgrades); just do not use a temporary 302 or 307 for a permanent move.
  • Is www outdated? Stylistically, mostly yes; most new sites drop it. Technically it is still fine and has a small DNS advantage: a CNAME on the www subdomain is universally supported, whereas a CNAME at the apex is not.
  • Can I change later? Yes, but treat it like a mini domain migration: set up the 301s, update the Search Console property, and update every canonical tag. Expect a brief ranking wobble during recovery.
  • What if my host only supports one name? Most modern hosts (Vercel, Firebase, Netlify, Cloudflare Pages) support both with an auto-redirect. If yours does not, front the domain with Cloudflare and add a Redirect Rule.
  • Should I CNAME the apex via Cloudflare CNAME flattening? Yes. That is the standard way to get CNAME-like behavior at the apex when your host wants a CNAME target but the registrar will not accept one at @. Cloudflare resolves the CNAME and serves A records, so it stays spec-compliant.

For Google’s authoritative guidance on consolidating duplicate URLs, see Google’s canonicalization documentation.

Tags: #Indie dev #Domain #DNS #Canonical #SEO

Related Articles