Cloudflare Pages www down: fix Error 1016

Guide October 21, 2026

Built 2026-09-22
Stack Astro 5 static · Cloudflare Pages/Workers · Cloudflare Registrar + DNS
Total cost $10.46/year, all in

This is the failure that cost me the most, and I caused it by following advice I’d give you again. If you just deployed, start at the Astro → Cloudflare Pages walkthrough — this is the thing that breaks after you’re live.

The advice: once your real domain works, disable the workers.dev subdomain, because two addresses serving identical content is a duplicate-content problem.

So I disabled it. And www.mossbysea.com, which had returned 200 twenty minutes earlier, started returning:

Error 1016 — Origin DNS error
Cloudflare is currently unable to resolve your requested domain

What Error 1016 actually means

Error 1016 always means the same thing: the hostname is on Cloudflare, but the DNS record it’s supposed to resolve to can’t be resolved. Cloudflare is proxying the request (orange-clouded), it looks up where www should go, and that target doesn’t answer.

It is not a build failure. It is not Cloudflare being down. It is a dangling pointer.

The cause

www had been set up as a CNAME pointing at the workers.dev subdomain — something like www → project.account.workers.dev. When I disabled workers.dev, that target stopped existing. The CNAME was left pointing at nothing, and Cloudflare, still proxying www, had nowhere to send the request.

You can confirm it in thirty seconds: open DNS for the domain and look at the www row. If it’s a CNAME to anything ending in workers.dev (or pages.dev), and that subdomain is now disabled, that’s your 1016.

Two ways out

Fix it (keep www). Delete the broken www record, then add www.yourdomain.com as a Custom domain on the Worker/Pages project — not a hand-written DNS record. Cloudflare creates the correct record and issues the certificate itself, with no dependency on workers.dev. This is the part I should have done in the first place.

Drop it (no www). Delete the www record and don’t replace it. Every page on a static site already emits <link rel="canonical"> pointing at the apex domain, so search engines consolidate there regardless. The only loss is that someone who types www. gets a “server not found” — which is better than the Error 1016 page they get today.

I took the second option. An error page is worse than nothing. Both are valid; pick based on whether you care about the www prefix.

The dangerous part: deleting the wrong record

When you go to delete that www row, slow down. The same DNS list holds the record serving your apex domain and the MX and TXT records running your email. Remove the wrong row and you take the site or the inbox down instantly — exactly the kind of mistake covered in the Cloudflare setup gotchas list.

After I deleted www, I scrolled the list and confirmed all three MX records and the SPF TXT record were still intact. Do that. It takes ten seconds and prevents a second, worse outage.

The order that avoids it

The trap only exists because www was a manual CNAME to a subdomain you later disable. Close it at setup time:

Enable workers.dev first and verify the build on that URL.
Add the apex domain as a Custom domain. Wait for the certificate.
If you want www, add it as a Custom domain on the Worker — never a hand-written CNAME to workers.dev.
Only now disable workers.dev. Then reload the site and confirm nothing depended on it.

If you’re setting up Email Routing on the same domain, do that before you start deleting DNS rows — the SPF and MX records it adds are exactly the ones you don’t want to take down by accident.

What I’d tell myself

Disabling workers.dev is still correct advice. The mistake was having www depend on it via a CNAME. Add www as a Custom domain on the project instead, and the subdomain becomes safe to turn off. If it’s already broken: delete the dangling CNAME, re-add www as a Custom domain (or don’t have one), and check your MX/TXT before you touch anything else.