3 defaults de Cloudflare que rompen sitios sin avisar

En pocas palabras: Fueron tres: el toggle «Managed robots.txt» de AI Crawl Control que reescribe el robots.txt de tu sitio Astro, el redirect 308 que agrega la barra final a las URLs y el interruptor Always Use HTTPS desactivado por defecto en Cloudflare Pages, sin arrojar ningún error.

Un sitio estático hecho con Astro salió a producción en Cloudflare Pages y llegó roto: tres valores por defecto de la plataforma alteraron su robots.txt, sus URLs y su sitemap sin arrojar ni un solo error, según documentó el propio desarrollador en su posteo en DEV. El build estaba verde, los checks locales pasaban y el dominio resolvía. Tres cosas seguían rotas, y las tres eran defaults que jamás tocó (spoiler: ninguno tiró error).

Cloudflare Pages es el servicio de hosting estático de Cloudflare: conectás un repositorio Git, la plataforma compila tu proyecto y lo distribuye por su red global. Los problemas de configuración de Cloudflare Pages más frecuentes no viven en tu código sino en los defaults que cada zona nueva activa sola: la reescritura del robots.txt mediante AI Crawl Control, el redirect 308 con barra final y el interruptor Always Use HTTPS apagado.

Cloudflare es una empresa estadounidense de servicios de infraestructura y seguridad web fundada en 2009 por Matthew Prince, Lee Holloway y Michelle Zatlyn. Ofrece una red de distribución de contenidos (CDN), resolución DNS, protección contra ataques DDoS y certificados SSL para sitios web.

¿Qué es Cloudflare Pages y por qué sus valores por defecto te rompen el sitio?

Cloudflare Pages es hosting gestionado para sitios estáticos: le das un repositorio, él compila y sirve. Este caso muestra su punto ciego: la capa que vos controlás (build, canonicals, lógica del sitemap) y la capa que controla el host (redirects, robots, TLS) pueden decir cosas distintas, y cuando eso pasa no existe ninguna alerta que te lo cuente.

El desarrollador tenía todo el ritual local armado: build de producción, chequeo de headers, link checker y test del sitemap. Compiló en local, todo daba verde, subió el repo, el build salió impecable en el dashboard, el dominio custom resolvió sin drama, anunció el lanzamiento, y recién ahí descubrió que el origin estaba sirviendo otra cosa, porque el robots.txt venía reescrito, las URLs redirigían con barra y el sitemap había crecido solo durante la noche.

Sin excepciones, sin logs, sin alertas. Solo comportamiento distinto.

Como resume el autor en su texto: “None of them throw an error. That is the whole problem” (ninguno tira un error; ese es todo el problema). Esa frase define el issue mejor que cualquier ticket: es un contrato que cambia debajo de tus pies sin levantar la mano.

Cloudflare reescribe tu robots.txt automáticamente: AI Crawl Control

Ponele que tu robots.txt tiene cuatro líneas: permitís todo, apuntás al sitemap, fin. Lo deployás, abrís tudominio.com/robots.txt desde el navegador y aparece un bloque que vos jamás escribiste. ¿Y qué dice ese bloque? Esto:

# BEGIN Cloudflare Managed Content
Content-Signal: search=yes,ai-train=no
User-agent: Google-Extended
...
# END Cloudflare Managed Content

Ese contenido lo inyecta el toggle “Managed robots.txt”, que vive dentro de AI Crawl Control y viene activado por defecto en cualquier zona nueva. La gracia (o la trampa) es que Googlebot y Bingbot siguen pasando normalmente: tu indexación orgánica se ve perfecta, así que no tenés razón alguna para ir a revisar ese archivo. Todo indica que funciona, y por eso nadie mira. Te puede servir nuestra cobertura de gestionar variables y secretos en Workers.

Si tu intención era bloquear crawlers de IA, bárbaro, la plataforma te lo hizo sin pedirte permiso. El problema es el escenario inverso: el autor quería lo opuesto y se enteró después del lanzamiento (gracias por el “favor” de fábrica).

Para verificarlo alcanza un comando, con una condición: leé el cuerpo completo, no el código de estado. Un curl -I te devuelve un 200 tranquilizador y no te dice nada de quién escribió ese contenido. El check real es curl https://tudominio.com/robots.txt y leer hasta la última línea.

El toggle está en AI Crawl Control → Overview. Un click, y tu robots.txt vuelve a ser el tuyo.

¿Por qué Cloudflare agrega una barra al final de mis URLs?

Porque Pages normaliza las rutas sumando la barra final mediante un redirect 308, sin importar lo que diga la configuración de tu framework. Es decisión del host, no del generador estático, y por eso tu config local no puede salvarla.

En el caso concreto, el sitio declaraba trailingSlash: 'never' en Astro, así que cada canonical apuntaba a la forma sin barra. Pero en producción pasaba otra cosa: GET /bosses/how-many-bosses respondía 308 y mandaba a /bosses/how-many-bosses/. Traducción práctica: los 33 canonicals del sitio apuntaban a URLs que redirigen.

¿Es fatal? No. ¿Duele? También: es un hop extra en cada página indexable (que no es poco si vivís de tráfico orgánico), y Search Console termina tratando el canonical y el destino del redirect como URLs separadas a la hora de evaluar. Más contexto en configurar correctamente tu DNS autoritativo.

Lo peor es por qué nadie lo vio venir: el servidor estático local hacía justo lo contrario (sí, en serio). Probaste diez veces contra localhost y diez veces el comportamiento fue el opuesto al del edge. Moraleja técnica: esto no se zafa en local. Deployá una página de prueba y tirále un curl -I a una ruta sin barra. Si aparece el header Location, ya sabés cómo normaliza tu host.

Treinta y tres páginas. Un redirect cada una. Todos los días.

El efecto dominó: el redirect rompió el sitemap en silencio

Este fue, según confiesa el propio autor, el episodio que más disfrutó (ironía incluida). El sitemap filtraba las páginas con noindex comparando rutas con match exacto, construidas a partir de las rutas del filesystem. Cuando Pages empezó a servir las URLs con barra, esa comparación dejó de matchear de golpe.

¿Y qué pasó entonces? Nada. Ningún error, ningún warning. El sitemap pasó de 33 URLs a 44, reincorporando en silencio 11 páginas que siguen teniendo la etiqueta noindex en su HTML, según el registro detallado en el posteo original.

Un sitemap que lista páginas marcadas como noindex es una contradicción que le entregás a Google a propósito. Le decís “indexá estas 44 direcciones” mientras 11 de ellas le contestan “no me indexes”.

El arreglo puntual es una línea: normalizar las rutas (unificar criterio de barra) antes de comparar. La lección de fondo es más incómoda: un cambio de configuración en un archivo modificó en secreto el contrato de una búsqueda en otro archivo, y los dos seguían “funcionando” durante todo el proceso. ¿Alguien validó el sitemap contra el origin? Nadie. Por eso todo siguió verde hasta el final.

Always Use HTTPS viene apagado y divide tus señales en Google

En toda zona nueva, el interruptor Always Use HTTPS está desactivado por defecto. Resultado directo: las peticiones por HTTP responden 200 en vez de redirigir a HTTPS, y Search Console puede indexar la versión http como una propiedad separada del sitio. Para más detalles técnicos, mirá benchmarks de cold start entre plataformas.

Eso parte tus señales en dos: enlaces, historial y datos de rastreo quedan repartidos entre dos propiedades que en realidad son la misma web. El autor lo listó como “bonus”, pero para cualquier proyecto con ambiciones orgánicas pesa igual que los otros tres puntos.

La corrección está en SSL/TLS → Edge Certificates → Always Use HTTPS, según la documentación oficial de SSL/TLS de Cloudflare. Un toggle, y el HTTP empieza a responder con redirect.

¿Qué defaults de Cloudflare hay que revisar y dónde se corrigen?

Cuatro ajustes concentran el riesgo del caso: tres toggles o comportamientos de zona y un efecto cascada en tu propio build. Esta tabla resume dónde vive cada uno, en qué estado arranca y cómo se corrige.

Ajuste	Dónde está	Estado en zona nueva	Qué provoca	Corrección
Managed robots.txt	AI Crawl Control → Overview	Activado	Inyecta Content-Signal con ai-train=no	Apagar el toggle si querés permitir crawlers de IA
Trailing slash	Comportamiento interno de Pages	Agrega barra (308)	Canonicals hacia URLs que redirigen	Probar con curl y alinear canonicals o normalizar rutas
Filtro del sitemap	Tu código de build	Efecto cascada	Re-agrega 11 páginas con noindex (de 33 a 44)	Normalizar paths antes de comparar
Always Use HTTPS	SSL/TLS → Edge Certificates	Apagado	HTTP responde 200 y parte señales en Search Console	Activarlo manualmente

¿Cómo testear antes de publicar en Cloudflare Pages?

Deployá primero y corré los checks contra el origin vivo. El autor tenía build de producción local, chequeo de headers, link checker y test de sitemap: todo verde, y aun así los tres problemas habitaban el hueco entre “mi salida de build” y “lo que el host realmente sirve”. La secuencia que propone es clara: nada de validar contra el directorio de build, nada de localhost. El origin.

• Deploy mínimo primero: publicá una página de prueba antes de anunciar nada y trabajá sobre esa URL real.
• curl al robots.txt completo: el cuerpo entero, buscando bloques que vos no escribiste.
• curl -I a una ruta sin barra: si aparece un 308 con Location, ya sabés cómo normaliza tu host.
• Prueba HTTP → HTTPS: pedí la versión http y verificá que responda redirect, no 200.
• Conteo del sitemap: compará la cantidad de URLs publicadas con la esperada; si creció sola, algo rompió el matching.

Una aclaración: este no es un mal exclusivo de Cloudflare. Cualquier host mete su propia capa de serving encima de tu build, sea un gigante global o un proveedor local como donweb.com. El ritual es idéntico: validá lo que el servidor entrega, no lo que dice tu carpeta dist.

¿A quién afectan estos problemas de configuración de Cloudflare Pages?

El perfil claro son sitios estáticos generados con Astro, Hugo, Jekyll o Next.js en modo export, proyectos donde la config local es coherente pero la plataforma introduce inconsistencias de serving. Si tu web depende de SEO orgánico, canonicals limpios y un sitemap confiable, estás en plena zona de impacto.

El ejemplo corregido del autor sigue online en gawrguraquestforbread.com, una wiki fan pequeña, por si querés inspeccionar cómo queda la salida una vez resueltos los tres puntos.

Ojo con una cosa: la lista de defaults de zona no termina acá. Cloudflare también administra componentes como su managed ruleset del WAF, capaz de modificar el manejo de requests según reglas administradas. El caso documenta tres defaults y un bonus; auditar la zona completa antes del lanzamiento sigue siendo tarea tuya.

Errores comunes al configurar Cloudflare Pages (y cómo evitarlos)

Nada exótico: los mismos tropiezos que se repiten en cada migración hacia un host gestionado. Esto se conecta con lo que analizamos en servir los assets desde R2.

• Fiarle el lanzamiento a los checks locales: tu servidor local y el edge no se comportan igual; en este caso, uno agregaba barra y el otro no. Corrección: validá siempre contra el origin.
• Validar el robots.txt por código de estado: un 200 no garantiza que el contenido sea el tuyo. Corrección: leé el cuerpo completo con curl.
• Comparar rutas con match exacto: cualquier normalización externa rompe la comparación sin hacer ruido. Corrección: normalizá las rutas antes de compararlas.
• Dar por hecho el redirect a HTTPS: en zona nueva viene apagado. Corrección: activá Always Use HTTPS y comprobalo con una petición http.

Preguntas Frecuentes

¿Qué configuración de Cloudflare puede romper mi sitio sin avisarme?

Tres defaults del caso documentado: el toggle Managed robots.txt de AI Crawl Control, el redirect 308 con barra final de Pages y Always Use HTTPS desactivado. Ninguno genera errores; cambian lo que el origin sirve respecto de tu build.

¿Cómo desactivo el bloqueo de crawlers de IA en Cloudflare?

Entrá a AI Crawl Control → Overview y apagá el toggle “Managed robots.txt”. La zona deja de inyectar el bloque con “Content-Signal: search=yes,ai-train=no” y tu archivo original vuelve a servirse tal cual. Verificalo después leyendo el robots.txt completo con curl.

¿Por qué Cloudflare agrega una barra al final de mis URLs?

Porque Pages normaliza las rutas con un redirect 308 hacia la versión con barra, de manera independiente a la configuración del framework. Si tus canonicals apuntan a la forma sin barra, cada página suma un hop extra y Search Console puede contar ambas versiones como URLs distintas.

¿Qué revisar antes de publicar un sitio en Cloudflare Pages?

Deployá una página y corré cuatro checks contra el origin: el robots.txt completo, la respuesta de una URL sin barra, el redirect de HTTP a HTTPS y el conteo de URLs del sitemap. Los tests locales no alcanzan porque el host agrega su propia capa de comportamiento.

¿Cloudflare Pages tiene plan gratuito?

Sí, Pages tiene plan gratuito para proyectos estáticos. Igual conviene precisarlo: el caso documentado no se debió a límites del plan sino a valores por defecto, algo que afecta igual a cuentas gratuitas que a pagas.

Conclusión

Lo que pasó es fácil de contar y feo de vivir: un sitio estático salió a producción con build verde y tres defaults de Cloudflare le reescribieron el robots.txt, redirigieron sus 33 URLs y agrandaron el sitemap hasta 44 entradas, todo sin un solo mensaje de error. El autor documentó el caso completo con el sitio ya corregido funcionando como prueba.

¿Por qué importa? Porque estos defaults no rompen funcionalidad visible: rompen contratos SEO (canonicals, sitemap) que Google lee en silencio durante meses. El daño no aparece en tu dashboard; aparece en tus métricas dentro de un tiempo, cuando ya perdiste posiciones sin saber por qué.

Mi lectura, ya que estamos: que AI Crawl Control venga con bloqueo de entrenamiento de IA activado puede tener sentido para muchos editores, pero sobreescribir en silencio el contenido que alguien publicó a propósito me parece diseño discutible. Un aviso en el dashboard al crear la zona resolvería el 100% de este dolor.

Qué hacer ahora: si ya tenés una zona en Cloudflare, revisá hoy los cuatro puntos de la tabla; si estás por lanzar, adoptá el ritual deploy-first y corré los checks contra el origin. Cinco minutos de curl ahorran semanas de SEO perdido.

Fuentes

• Tres defaults de Cloudflare que rompieron en silencio mi sitio estático el día del lanzamiento – posteo original del caso en DEV
• Cloudflare Pages – documentación oficial del servicio
• Always Use HTTPS – opciones de certificados edge en la documentación de SSL/TLS de Cloudflare
• Cloudflare Managed Ruleset – documentación del WAF administrado