Este blog salió de la dirección temporal fluxonar.pages.dev y pasó a responder en fluxonar.com.br hoy. El proceso entero llevó menos de una hora, pero solo porque tres trampas que la documentación no destaca se resolvieron en el orden correcto. Este post es el registro real de ese go-live, paso a paso, para quien vaya a hacer lo mismo con un sitio estático en Cloudflare Pages.

El contexto: dominio .com.br registrado en registro.br, zona DNS creada en Cloudflare y nameservers delegados el día anterior. Si usted todavía no hizo esa parte, esa viene primero, y la propagación de los nameservers (algunas horas) es la única espera real de todo el proceso.

Trampa 1: crear la zona no publica nada

La primera trampa es creer que delegar los nameservers ya “enciende” el sitio. No lo enciende. La zona activa en Cloudflare es solo el prerrequisito: sin el paso siguiente, el dominio sigue sin ningún registro DNS que apunte al proyecto: NXDOMAIN para quien intente entrar.

El paso que de hecho publica es conectar el dominio al proyecto de Pages: Workers & Pages → proyecto → pestaña Custom domains → Set up a custom domain → escribir el apex (fluxonar.com.br, sin www). Como la zona ya está en la misma cuenta, Cloudflare crea sola el registro DNS y emite el certificado TLS. El panel avisa “hasta 48 horas”, pero con la zona en la propia cuenta el estado Initializing pasó a Active en pocos minutos en mi caso: el DNS respondía antes de que yo terminara el café.

Trampa 2: el www no es un segundo dominio

La tentación es repetir el proceso y agregar www.fluxonar.com.br como segundo custom domain. Funciona, y crea un problema: el mismo contenido servido en dos URLs, que Google trata como duplicado, y usted mismo pasa a dividir las señales de posicionamiento entre ellas.

El diseño correcto es un redirect 301 del www al apex, en dos registros:

  1. CNAME www → fluxonar.com.br, con el proxy activado (nube naranja), para que la solicitud de www llegue a Cloudflare.
  2. Una regla de redirección. En mi panel, Redirect Rules ni aparecía en el menú, pero las Page Rules clásicas resuelven igual: URL www.fluxonar.com.br/*, acción Forwarding URL, estado 301, destino https://fluxonar.com.br/$1. El $1 preserva la ruta: www…/sobre cae en …/sobre, no en la home.

Quien escriba www llega al sitio correcto; Google consolida todo en una sola URL. Un dominio, un contenido, una señal.

Prueba ejecutable: curl -I https://www.seudominio.com.br/qualquer-pagina tiene que devolver 301 con Location apuntando a la misma ruta en el apex.

Trampa 3: el token de analytics que usted NO debe configurar

Esta fue la más contraintuitiva. El plan era el flujo documentado de Cloudflare Web Analytics: crear el sitio en el panel, copiar el token del snippet e inyectar el beacon mediante una variable de entorno en el build. Pero el botón Manage site → Get code snippet simplemente no existía en el panel.

El motivo: ese flujo manual es para un sitio alojado fuera de Cloudflare. Cuando el dominio está proxied en la propia Cloudflare (nube naranja), ella inyecta el beacon automáticamente en el edge, sin token, sin snippet, sin rebuild. Agregué el sitio en Web Analytics y, minutos después, el panel ya mostraba visitas y Core Web Vitals reales.

El corolario importante: si su código también inyecta el snippet manual (el nuestro tenía ese soporte mediante variable de entorno), no configure el token: usted tendría dos beacons en la misma página y un conteo doble. Verificación: el HTML servido debe contener static.cloudflareinsights.com/beacon.min.js exactamente una vez. Detalle de la prueba: la inyección automática solo ocurre con solicitudes que parecen de navegador; un curl sin User-Agent de navegador no ve el beacon y usted concluye, equivocado, que la medición está apagada.

Search Console: la verificación se volvió un clic

La parte que más mejoró en los últimos años. Creé la propiedad de Dominio (no “prefijo de URL”) en Google Search Console, y en lugar de copiar el registro TXT a mano, Google ofreció verificación directa a través del proveedor: un clic, autorización OAuth en Cloudflare, y él mismo creó el TXT google-site-verification en la zona. Propiedad verificada en menos de un minuto.

Dos notas prácticas del envío del sitemap:

  • En la propiedad de Dominio, el campo del sitemap rechaza la ruta relativa: envié la URL completa (https://fluxonar.com.br/sitemap-index.xml) y pasó.
  • El estado inicial fue un rojo alarmante: “No se pudo obtener el sitemap”. Es un comportamiento normal justo después del envío: la obtención es asíncrona. En mi caso pasó a Procesado, con las 13 páginas encontradas, en cerca de una hora. No toque nada en ese intervalo. Después, el informe de indexación también muestra lo que el sitio deja fuera del índice a propósito, como las etiquetas con pocos posts.

El checklist ejecutable del final

Go-live declarado solo después de que pasen estos cinco comandos: cada uno verifica una promesa del proceso:

  1. curl -I https://seudominio/ → 200 con los headers de seguridad del sitio (en nuestro caso, x-frame-options: DENY y compañía, servidos mediante _headers).
  2. curl -I https://www.seudominio/sobre → 301 + Location preservando la ruta.
  3. curl -I https://seudominio/sitemap-index.xml → 200, content-type: application/xml.
  4. curl -I https://seudominio/pagina-inexistente → 404 real, no un soft-404 disfrazado de 200.
  5. HTML de una página (con User-Agent de navegador) que contenga el beacon de analytics exactamente una vez.

Nada de esto exigió soporte, plan de pago ni una espera de 48 horas. Lo que exigió fue saber tres cosas: que la zona no publica sola, que el www es un redirect y no un dominio, y que el token de analytics, en el escenario proxied, es justamente lo que no se debe configurar.

Fuentes