www and Root Domain Don't Match (Only One Loads)

Q: Why does my apex domain reject the CNAME record?

Per RFC 1034, a `CNAME` can't coexist with the `SOA` and `NS` records that every apex carries. Use your provider's `ALIAS`/`ANAME` flattening, Cloudflare's CNAME flattening, or an `HTTPS` record instead — or point the apex at an `A`/IP and keep the `CNAME` only on `www`.

Q: Do I need the apex record if I redirect everything to www?

Yes. The apex still has to resolve to *something* so the host can receive the request and issue the redirect. A dead apex record means the redirect never gets a chance to fire.

www.example.com works but example.com returns an error (or vice versa). Fix the missing DNS record, then add a 301 redirect to one canonical version.

Published: May 17, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

www.yourdomain.com loads fine. yourdomain.com (the apex / root) returns This site can't be reached or DNS_PROBE_FINISHED_NXDOMAIN. Or the reverse. Users who type the shorter version hit an error and bounce.

Fastest fix: the problem is almost always one of two things, and they get conflated. (1) Both hostnames need a working DNS record pointing at your host. (2) A single 301 redirect must consolidate visitors onto the one canonical version. Run the two dig checks in the first cause below to find out which half is broken, then jump to the matching step.

This guide covers both halves and the per-platform implementation for Vercel, Netlify, and Firebase, current as of June 2026.

Which bucket are you in

Run these two commands and compare:

dig yourdomain.com +short
dig www.yourdomain.com +short

What you see	Diagnosis	Go to
One command returns nothing	Missing DNS record (NXDOMAIN side)	Cause 1
Both resolve, both load, neither redirects	Missing 301 redirect	Cause 2
Apex `dig` errors at your DNS host	Apex CNAME / record conflict	Cause 3
Both resolve but one returns 404	Domain not added on the host	Cause 6
Redirect only happens after the page renders	Redirect lives in app code, not the platform	Cause 5

Common causes

Ordered by hit rate, highest first.

1. Only one DNS record set

You configured an A record for the apex but no CNAME for www, or you set the www CNAME but forgot the apex. The unconfigured side returns NXDOMAIN.

How to spot it:

dig yourdomain.com +short
dig www.yourdomain.com +short

If one returns nothing, that’s the missing record. (Note: a freshly added record can take time to propagate — see DNS propagation in the fix steps.)

2. Both DNS records set but no redirect

Both versions resolve and load the site, but they serve content independently. Google treats this as duplicate content and may split ranking signals; users see inconsistent URLs.

How to spot it:

curl -sI https://yourdomain.com | head -3
curl -sI https://www.yourdomain.com | head -3

If both return HTTP/2 200 (instead of one returning 301 with a Location header pointing at the other), the redirect is missing.

3. Apex tried to use CNAME (RFC violation)

You set a CNAME at the apex (root) domain. Per RFC 1034, a CNAME cannot coexist with any other record at a name, and the apex always carries SOA and NS records — so a CNAME at the apex is invalid. Strict DNS providers reject it outright; permissive ones may accept it but break MX mail delivery and conflict with TXT verification records.

How to spot it: a DNS-host error like CNAME cannot coexist with other records at apex, or silent partial failure. The supported alternatives are flattening records that some providers offer — ALIAS, ANAME, or Cloudflare’s CNAME flattening — or the newer HTTPS record type (RFC 9460), all of which are CNAME-like but legal at the apex.

4. Hosting platform requires a specific apex / www value

If you point the apex A record at the wrong IP, or use a stale www CNAME target, the host can’t match the request to your project. As of June 2026:

Vercel apex: A record to 76.76.21.21. www: CNAME to cname.vercel-dns.com (newer projects may be shown cname.vercel-dns-0.com — use exactly what your project’s Settings > Domains page displays). Vercel does not support IPv6, so don’t add an AAAA record.
Netlify: external DNS uses Netlify’s load-balancer A for the apex and a CNAME to your your-site.netlify.app for www; the dashboard shows the exact values.
Firebase Hosting: shows two apex A records to copy when you add the custom domain.

How to spot it: compare your live A / CNAME values (dig) against what the platform dashboard shows for that exact domain. A mismatch means edit the record.

5. Redirect set in app code, not at the platform

You added a redirect in your application (e.g., a React Router rule or a Next.js middleware that runs late). It only fires after the page or JS loads, so the initial HTTP response is still 200, and crawlers plus direct hits never see a clean 301.

How to spot it: curl -sI returns 200 even though the browser eventually jumps to the canonical URL. The redirect should be an HTTP 301 issued at the platform / DNS edge, before any HTML is served.

6. www (or apex) not provisioned on the host

You added yourdomain.com to the host but not www.yourdomain.com (or vice versa). The DNS record points correctly, but the host has no project bound to that hostname, so it returns 404 or a generic platform error page.

How to spot it: open the platform’s domains list (Vercel Settings > Domains, Netlify Domain management > Production domains, Firebase Hosting). If only one hostname is listed, add the other.

Shortest path to fix

Step 1: Pick a canonical

Either the apex or www. Commit to one and don’t flip later. Trade-offs:

Apex (yourdomain.com): shorter and looks cleaner in print. Requires apex DNS flattening (ALIAS/ANAME/HTTPS) on some hosts, which not every registrar supports.
www (www.yourdomain.com): the www host takes a normal CNAME, which avoids the apex-CNAME problem entirely and resolves faster behind a CDN. Both Vercel and Netlify recommend www as primary when you use third-party (external) DNS, because apex A records can’t follow their anycast routing as efficiently.

If you have no strong preference, www-as-canonical is the lower-friction choice. Write the decision down so you don’t second-guess it.

Step 2: Set both DNS records

You need records for both hostnames regardless of which is canonical — the non-canonical one still has to resolve so it can be redirected.

For Vercel with www as canonical:

CNAME  www   cname.vercel-dns.com
A      @     76.76.21.21

For Vercel with the apex as canonical:

A      @     76.76.21.21
CNAME  www   cname.vercel-dns.com

Use the exact target your Settings > Domains page shows; some projects display cname.vercel-dns-0.com. After saving, expect propagation to take anywhere from a few minutes up to 24–48 hours; check progress at whatsmydns.net.

Step 3: Add both domains to your host

In the Vercel, Netlify, or Firebase dashboard, add both yourdomain.com and www.yourdomain.com as project domains. The platform can only redirect a hostname it knows about. Many platforms then auto-redirect the non-canonical one once both are present; others need the explicit step below.

Step 4: Configure the redirect at the platform level

Vercel — Project Settings > Domains. Add both hostnames, then on the non-canonical one open the row menu and choose Edit > set it to redirect to your canonical domain (307/308 for the temporary/permanent option Vercel exposes; pick the permanent redirect). Vercel also offers a one-click “Redirect to” field when you add the second domain.

Netlify — Domain management > Production domains. Set your canonical hostname as the primary domain; Netlify then automatically 301-redirects the other one. No file changes needed.

Firebase Hosting — this is not done in firebase.json. Cross-domain www↔apex redirects are a console option. In the Firebase console go to Hosting > Add custom domain, enter the non-canonical hostname, and check the box Redirect [domain] to an existing website, then enter your canonical domain and click Continue. (firebase.json redirects only handle same-domain path rules like /old → /new, not host-to-host redirects.)

Step 5: Verify the redirect

# Non-canonical should return a 30x with a Location header to the canonical host
curl -sI https://www.yourdomain.com | head -5
# Expect something like:
# HTTP/2 301
# location: https://yourdomain.com/

If both hostnames still return 200, the redirect isn’t live yet — recheck Step 4 or wait for propagation. Also test the http:// versions; they should redirect to https:// on the canonical host in a single hop where possible.

Step 6: Self-canonical in HTML and JSON-LD

Even with a working 301, your rendered pages should declare the canonical version so crawlers don’t have to rely on the redirect alone:

<link rel="canonical" href="https://yourdomain.com/article/" />

Match your chosen canonical exactly — don’t emit https://www.yourdomain.com/article/ if your canonical is the apex. The hostname in rel="canonical", your sitemap URLs, and your 301 target should all agree.

How to confirm it’s fixed

You’re done when all four checks pass:

dig yourdomain.com +short and dig www.yourdomain.com +short both return a value.
curl -sI on the non-canonical host returns 301 (or 308) with a location: header pointing at the canonical host.
curl -sI on the canonical host returns 200.
The <link rel="canonical"> in your HTML matches the canonical host.

In Google Search Console, both hostnames should resolve to the canonical version in the URL Inspection tool within a few days of the redirect going live.

Prevention

Choose your canonical at launch and don’t flip it later — switching causes weeks of Search Console churn.
Set up both DNS records (apex A/flattened record and www CNAME) on day one.
Add both hostnames to your host immediately, not just the one you type most.
Verify with curl -sI that the redirect is a real 301, not a client-side JS redirect.
Keep rel="canonical", sitemap URLs, and the redirect target all pointing at the same host.

FAQ

Should I make apex or www my canonical? Either works for SEO; Google has no preference as long as one redirects to the other. For lower setup friction on third-party DNS, www is easier because it uses a plain CNAME and avoids apex flattening. Choose one and keep it.

Why does my apex domain reject the CNAME record? Per RFC 1034, a CNAME can’t coexist with the SOA and NS records that every apex carries. Use your provider’s ALIAS/ANAME flattening, Cloudflare’s CNAME flattening, or an HTTPS record instead — or point the apex at an A/IP and keep the CNAME only on www.

Both versions return 200 — is that actually a problem? Yes. Serving identical content on two hostnames without a redirect splits link equity and can let Google index the wrong version. Add a 301 from the non-canonical host to the canonical one.

How long until the redirect takes effect? DNS changes propagate in minutes to 24–48 hours depending on the previous TTL. The redirect rule itself is usually live within seconds of saving on Vercel/Netlify, but you may need to clear your browser cache, since browsers aggressively cache 301 responses.

Do I need the apex record if I redirect everything to www? Yes. The apex still has to resolve to something so the host can receive the request and issue the redirect. A dead apex record means the redirect never gets a chance to fire.

Tags: #Troubleshooting #DNS #Debug