My Cloudflare Pages site works on the apex but www does not load

By Idea to Traffic Editorial Team · Published August 31, 2026 · Last updated September 27, 2026

Six sites with no www, and no error anywhere

Across six of the sites in this network, every one was missing www. The apex loaded on all six, so nobody checked the other hostname. Nothing in the Cloudflare dashboard indicated a problem: each project listed its custom domain and reported no error, because from the host's point of view nothing was wrong.

Apex loads, www cannot be reached

yourdomain.com loads normally. www.yourdomain.com gives a browser error along the lines of "site can't be reached" or "server not found". The Pages dashboard lists the domain and shows no error against it. Nothing in your deploy log mentions DNS, because the deploy had nothing to do with it.

Attaching a hostname is not creating its record

Attaching www to a Pages project and creating its DNS record are two separate steps, and only the first one is obvious.

The Pages custom domain call registers the hostname with the project so that Pages will answer for it. It does not write a DNS record. When the zone sits on the same Cloudflare account, the dashboard usually creates that record for you as a convenience, which is exactly why people assume the API does the same thing. It does not. Through the API you get the registration and nothing else, so the name is configured at the application layer and has never existed at the DNS layer.

The result is a hostname that is fully set up everywhere except the one place a browser looks first.

Ask a DNS resolver, not a browser

Ask a resolver directly rather than trusting a browser, which will cache a failure and dress it up in its own wording:

curl -s -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=www.yourdomain.com&type=CNAME"

On a hostname with no record at all, the answer looks like this. It was taken from a subdomain of this site that genuinely does not exist:

{"Status":3,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,
 "Question":[{"name":"www.nosuchhost.ideatotraffic.com","type":5}],
 "Authority":[{"name":"ideatotraffic.com","type":6,"TTL":1800,
 "data":"anna.ns.cloudflare.com. dns.cloudflare.com. 2414806675 10000 2400 604800 1800"}]}

"Status":3 is NXDOMAIN. The name does not exist. That points at the missing DNS record, not at Pages, and it is the whole diagnosis.

Once the record is in place, the same question gets an answer. Note what it answers with, because this surprises people: a proxied CNAME on Cloudflare is flattened, so the resolver hands back A records for Cloudflare's edge rather than the CNAME you created. Querying for type A on the live hostname of this site returns:

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,
 "Question":[{"name":"www.ideatotraffic.com","type":1}],
 "Answer":[{"name":"www.ideatotraffic.com","type":1,"TTL":300,"data":"104.21.38.30"},
           {"name":"www.ideatotraffic.com","type":1,"TTL":300,"data":"172.67.218.74"}]}

"Status":0 with an Answer array is what working looks like. If you query for CNAME on a proxied record and get Status 0 with no Answer array, that is not a failure either; it means the name exists and its CNAME is being flattened. NXDOMAIN is the only answer that means what you think it means.

Five steps from NXDOMAIN to a working redirect

1. Attach the hostname to the project, if it is not already listed:

   POST /accounts/$ACCOUNT/pages/projects/$PROJECT/domains
   {"name":"www.yourdomain.com"}

2. Create the record. This is the step that was missing:

   POST /zones/$ZONE/dns_records
   {"type":"CNAME","name":"www.yourdomain.com","content":"$PROJECT.pages.dev",
    "proxied":true,"ttl":1}

3. Poll the domains endpoint until both verification_data.status and validation_data.status read active. In the window before that, the name resolves but the browser shows a certificate warning, which looks like a different and more alarming problem than it is.

4. Add a Redirect Rule sending www to the apex with a 301, so the two hostnames do not compete. Through the API this needs a token carrying Rulesets permission. Without it the call fails with a generic authentication error that does not name the missing scope, which is its own time sink. The dashboard route under Rules takes about thirty seconds and needs no token at all.

5. Confirm the whole chain with one request:

   curl -sI https://www.yourdomain.com/

   On this site that returns:

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

Create both hostnames in the same step

Create www and the apex in the same step, every time, and put the curl -sI check in your launch checklist next to the other one-line checks. The reason this went unnoticed on six sites is that nobody types www any more, so the only people who would have found it were visitors, and there were not enough of them yet to complain.

Hostname problems the record leaves behind

It does not fix a canonical tag that names the wrong hostname; a site serving both names with canonicals pointing at www will keep splitting its signals even after the redirect is in place. It also does not save you from an unproxied CNAME, which half works in the most confusing way available: sometimes the right site, sometimes a certificate mismatch, sometimes a 404, depending on which path the request takes.

Time lost

Questions about www on Cloudflare Pages