This blog left the temporary address fluxonar.pages.dev and started responding at fluxonar.com.br today. The whole process took less than an hour — but only because three traps the documentation does not highlight were resolved in the right order. This post is the real record of that go-live, step by step, for anyone who is going to do the same with a static site on Cloudflare Pages.

The context: a .com.br domain registered at registro.br, a DNS zone created on Cloudflare, and nameservers delegated the day before. If you have not done that part yet, it comes first — and nameserver propagation (a few hours) is the only real wait in the whole process.

Trap 1: creating the zone publishes nothing

The first trap is thinking that delegating the nameservers already “turns the site on”. It does not. An active zone on Cloudflare is only the prerequisite: without the next step, the domain still has no DNS record pointing at the project — NXDOMAIN for anyone who tries to reach it.

The step that actually publishes is attaching the domain to the Pages project: Workers & Pages → project → Custom domains tab → Set up a custom domain → type the apex (fluxonar.com.br, without www). Because the zone is already on the same account, Cloudflare creates the DNS record on its own and issues the TLS certificate. The panel warns “up to 48 hours”, but with the zone on the account itself the Initializing status became Active in a few minutes in my case — DNS was answering before I finished my coffee.

Trap 2: www is not a second domain

The temptation is to repeat the process and add www.fluxonar.com.br as a second custom domain. It works — and it creates a problem: the same content served at two URLs, which Google treats as duplicate, and you yourself start splitting ranking signals between them.

The correct design is a 301 redirect from www to the apex, in two records:

  1. CNAME www → fluxonar.com.br, with the proxy on (orange cloud) — so the www request reaches Cloudflare.
  2. A redirect rule. In my panel, Redirect Rules did not even appear in the menu — but the classic Page Rules solve it the same way: URL www.fluxonar.com.br/*, action Forwarding URL, status 301, destination https://fluxonar.com.br/$1. The $1 preserves the path: www…/sobre lands on …/sobre, not on the home page.

Whoever types www reaches the right site; Google consolidates everything into a single URL. One domain, one piece of content, one signal.

Executable test: curl -I https://www.seudominio.com.br/qualquer-pagina must return 301 with Location pointing at the same path on the apex.

Trap 3: the analytics token you should NOT configure

This was the most counterintuitive one. The plan was the documented flow for Cloudflare Web Analytics: create the site in the panel, copy the snippet token, and inject the beacon through an environment variable at build time. Except the Manage site → Get code snippet button simply did not exist in the panel.

The reason: that manual flow is for a site hosted outside Cloudflare. When the domain is proxied on Cloudflare itself (orange cloud), Cloudflare injects the beacon automatically at the edge — no token, no snippet, no rebuild. I added the site in Web Analytics, and minutes later the panel was already showing real visits and Core Web Vitals.

The important corollary: if your code also injects the snippet manually (ours had that support through an environment variable), do not configure the token — you would have two beacons on the same page and a doubled count. Check: the served HTML must contain static.cloudflareinsights.com/beacon.min.js exactly once. A detail of the test: automatic injection only happens for requests that look like a browser — a curl without a browser User-Agent does not see the beacon, and you conclude, wrongly, that measurement is off.

Search Console: verification became one click

The part that has improved the most in recent years. I created a Domain property (not “URL prefix”) in Google Search Console, and instead of copying the TXT record by hand, Google offered verification directly through the provider: one click, OAuth authorization on Cloudflare, and it created the google-site-verification TXT in the zone itself. Property verified in less than a minute.

Two practical notes on submitting the sitemap:

  • On a Domain property, the sitemap field rejects a relative path — I submitted the full URL (https://fluxonar.com.br/sitemap-index.xml) and it went through.
  • The initial status was a scary red: “Could not fetch the sitemap”. That is normal behavior right after submission — the fetch is asynchronous. In my case it became Processed, with the 13 pages found, in about an hour. Do not change anything in the meantime. Later, the indexing report also shows what the site leaves out of the index on purpose, such as tags with few posts.

The executable checklist at the end

Go-live is declared only after these five commands pass — each one checks a promise of the process:

  1. curl -I https://seudominio/ → 200 with the site’s security headers (in our case, x-frame-options: DENY and the rest, served via _headers).
  2. curl -I https://www.seudominio/sobre → 301 + Location preserving the path.
  3. curl -I https://seudominio/sitemap-index.xml → 200, content-type: application/xml.
  4. curl -I https://seudominio/pagina-inexistente → a real 404, not a soft-404 disguised as 200.
  5. HTML of a page (with a browser User-Agent) containing the analytics beacon exactly once.

Nothing here required support, a paid plan, or a 48-hour wait. What it required was knowing three things: that the zone does not publish on its own, that www is a redirect and not a domain, and that the analytics token, in the proxied scenario, is exactly what should not be configured.

Sources