Este blog saiu do endereço temporário fluxonar.pages.dev e passou a responder em fluxonar.com.br hoje. O processo inteiro levou menos de uma hora — mas só porque três pegadinhas que a documentação não destaca foram resolvidas na ordem certa. Este post é o registro real desse go-live, passo a passo, para quem for fazer o mesmo com um site estático no Cloudflare Pages.

O contexto: domínio .com.br registrado no registro.br, zona DNS criada na Cloudflare e nameservers delegados no dia anterior. Se você ainda não fez essa parte, ela vem primeiro — e a propagação dos nameservers (algumas horas) é a única espera real de todo o processo.

Pegadinha 1: criar a zona não publica nada

A primeira armadilha é achar que delegar os nameservers já “liga” o site. Não liga. A zona ativa na Cloudflare é só o pré-requisito: sem o passo seguinte, o domínio continua sem nenhum registro DNS apontando para o projeto — NXDOMAIN para quem tentar acessar.

O passo que efetivamente publica é plugar o domínio no projeto Pages: Workers & Pages → projeto → aba Custom domains → Set up a custom domain → digitar o apex (fluxonar.com.br, sem www). Como a zona já está na mesma conta, a Cloudflare cria o registro DNS sozinha e emite o certificado TLS. O painel avisa “até 48 horas”, mas com a zona na própria conta o status Initializing virou Active em poucos minutos no meu caso — o DNS respondia antes de eu terminar o café.

Pegadinha 2: o www não é um segundo domínio

A tentação é repetir o processo e adicionar www.fluxonar.com.br como segundo custom domain. Funciona — e cria um problema: o mesmo conteúdo servido em duas URLs, que o Google trata como duplicado e você mesmo passa a dividir sinais de ranqueamento entre elas.

O desenho correto é redirect 301 do www para o apex, em dois registros:

  1. CNAME www → fluxonar.com.br, com proxy ligado (nuvem laranja) — para o request do www chegar à Cloudflare.
  2. Uma regra de redirecionamento. No meu painel, Redirect Rules nem aparecia no menu — mas as Page Rules clássicas resolvem igual: URL www.fluxonar.com.br/*, ação Forwarding URL, status 301, destino https://fluxonar.com.br/$1. O $1 preserva o caminho: www…/sobre cai em …/sobre, não na home.

Quem digitar www chega ao site certo; o Google consolida tudo numa URL só. Um domínio, um conteúdo, um sinal.

Teste executável: curl -I https://www.seudominio.com.br/qualquer-pagina tem que devolver 301 com Location apontando o mesmo caminho no apex.

Pegadinha 3: o token de analytics que você NÃO deve configurar

Essa foi a mais contraintuitiva. O plano era o fluxo documentado do Cloudflare Web Analytics: criar o site no painel, copiar o token do snippet, injetar o beacon via variável de ambiente no build. Só que o botão Manage site → Get code snippet simplesmente não existia no painel.

O motivo: esse fluxo manual é para site hospedado fora da Cloudflare. Quando o domínio está proxied na própria Cloudflare (nuvem laranja), ela injeta o beacon automaticamente no edge — sem token, sem snippet, sem rebuild. Adicionei o site em Web Analytics, e minutos depois o painel já mostrava visitas e Core Web Vitals reais.

O corolário importante: se o seu código também injeta o snippet manual (o nosso tinha esse suporte via variável de ambiente), não configure o token — você teria dois beacons na mesma página e contagem dobrada. Verificação: o HTML servido deve conter static.cloudflareinsights.com/beacon.min.js exatamente uma vez. Detalhe do teste: a injeção automática só acontece para requests que parecem navegador — um curl sem User-Agent de browser não vê o beacon e você conclui, errado, que a medição está desligada.

Search Console: a verificação virou um clique

A parte que mais melhorou nos últimos anos. Criei a propriedade de Domínio (não “prefixo de URL”) no Google Search Console, e em vez de copiar o registro TXT à mão, o Google ofereceu verificação direta via provedor: um clique, autorização OAuth na Cloudflare, e ele mesmo criou o TXT google-site-verification na zona. Propriedade verificada em menos de um minuto.

Duas notas práticas do envio do sitemap:

  • Em propriedade de Domínio, o campo de sitemap rejeita caminho relativo — enviei a URL completa (https://fluxonar.com.br/sitemap-index.xml) e passou.
  • O status inicial foi um vermelho assustador: “Não foi possível buscar o sitemap”. É comportamento normal logo após o envio — a busca é assíncrona. No meu caso virou Processado, com as 13 páginas encontradas, em cerca de uma hora. Não mexa em nada nesse meio-tempo.

O checklist executável do fim

Go-live declarado só depois destes cinco comandos passarem — cada um verifica uma promessa do processo:

  1. curl -I https://seudominio/ → 200 com os headers de segurança do site (no nosso caso, x-frame-options: DENY e companhia, servidos via _headers).
  2. curl -I https://www.seudominio/sobre → 301 + Location preservando o caminho.
  3. curl -I https://seudominio/sitemap-index.xml → 200, content-type: application/xml.
  4. curl -I https://seudominio/pagina-inexistente → 404 real, não um soft-404 disfarçado de 200.
  5. HTML de uma página (com User-Agent de navegador) contendo o beacon de analytics exatamente uma vez.

Nada aqui exigiu suporte, plano pago ou espera de 48 horas. O que exigiu foi saber que a zona não publica sozinha, que www é redirect e não domínio, e que o token de analytics — no cenário proxied — é exatamente o que você não deve usar.