«Hazme una web de artículos. Lo demás, encárgate tú».
La IA se pone manos a la obra: más artículos, más idiomas, artículos relacionados, enlaces internos, buscador, controles de calidad, controles de seguridad y reparación automática. Lo que iba a ser una tiendita de barrio termina convertido en una fábrica con equipo de traducción, equipo de revisión, oficina de auditoría y hasta un «comité que aprueba cada coma».
Al final, la pantalla dice BUILD FAILED.
IA: «Listo, lo arreglé». Siguiente build: falla. IA: «Arreglé otra cosa». Vuelve a fallar. Derrotas al jefe final y aparece otro jefe final. Aquí te explicamos por qué pasa esto, con Cloudflare Pages y Astro como ejemplo, y qué hacer. Es una explicación general, no el diagnóstico de un sitio concreto.
1. ¿Qué hace un build, en pocas palabras?
Tus textos en Markdown, las imágenes, el diseño y el código son ingredientes, no una web terminada. El build toma esos ingredientes y los convierte en páginas y archivos que el navegador puede mostrar. Astro normalmente deja los archivos estáticos listos para publicar en una carpeta llamada dist.[1]
El texto es la receta; el build es cocinar. Poner una cebolla cruda y un libro de cocina en la mesa y decir «a comer» no convence a nadie.
2. ¿Qué hace Cloudflare y qué no?
Cloudflare Pages puede traer tu código desde Git, ejecutar el comando de build que configuraste y publicar el resultado.[2] El orden típico es: bajar el código, instalar herramientas, revisar antes, generar páginas, comprobar el resultado y publicar (deploy). Los pasos exactos dependen de tu proyecto.
Build es fabricar; deploy es despachar y publicar. Si el build nuevo falla, esa versión no sale. Cloudflare pone la nave, pero la cadena de montaje con forma de laberinto muchas veces la armó el propio código del sitio.
3. Una web que publica sola trabaja mucho antes de crear una página
Un blog sencillo pasa el texto a HTML y listo. Un sistema de publicación automática puede sumar trabajo antes y después: ¿este artículo se puede publicar? ¿Están todas las traducciones? ¿Coinciden el ID del artículo y la URL? ¿Están bien los artículos relacionados y los enlaces internos? ¿Se pueden generar los datos del buscador? ¿Cumplen los títulos, las descripciones de imágenes, los anuncios y las reglas de seguridad?
Cada revisión, por separado, tiene sentido. El problema es cuando cambiar una frase obliga a todos los departamentos a repetir la reunión de la mañana. Querías corregir una coma y llega toda la plantilla con casco.
4. ¿Por qué se complica con muchas páginas e idiomas?
10,000 páginas no significan sí o sí 10,000 veces más trabajo. Pero crecen los archivos, los artículos se enlazan entre sí y cada idioma suma sus propias URL y datos de búsqueda. Si en cada build comparas cada artículo con todos los demás, todo se vuelve más pesado a medida que creces.
Por eso conviene recalcular solo lo que cambió, guardar los resultados que se puedan reutilizar y medir cuánto tarda cada paso. Lo lento se descubre con números, no a ojo. Si cada libro nuevo obligara a reordenar todas las bibliotecas del país, el bibliotecario se pondría a llorar.
5. ¿Por qué cada arreglo destapa otro error?
Cuando los pasos van en fila, el error de adelante tapa los de atrás. Falla la revisión de artículos, la arreglas. Ahora corre la revisión de enlaces y falla, la arreglas. Luego falla la generación de páginas. Después, los datos del buscador.
Eso no quiere decir que cada arreglo haya creado un bug nuevo. Puede que los problemas estuvieran ahí desde el principio, haciendo fila. Aunque también puede pasar que un arreglo rompa algo. Para saber cuál de las dos, mira los registros (logs) y el historial de cambios. Abres la puerta del calabozo y hay otra puerta, y todas dicen «ÚLTIMO NIVEL».
6. Las 6 causas típicas de un build fallido
1) Código y paquetes: errores de escritura, paquetes que faltan, versiones distintas. 2) Datos de entrada: textos que faltan o con el formato equivocado. 3) Reglas de revisión: la página se genera, pero una regla la frena. 4) Recursos: límites de tiempo, memoria o cantidad de archivos. 5) Entorno: la configuración de tu computadora y la de Cloudflare no coinciden. 6) Publicación: falla la revisión final o la subida.
Cloudflare Pages marca el build como fallido cuando el comando termina con un código distinto de 0.[2] O sea, el «Build failed» del final es el resultado, no necesariamente la causa. Mirando la portada de una novela policíaca no sabes quién es el asesino.
7. Cómo leer el registro: busca el primer fallo
En los detalles de cada deploy de Cloudflare puedes abrir el Build log.[3] No te quedes con la última línea en rojo: busca el primer paso que de verdad falló y clasifícalo: ¿datos, código, regla, recursos o entorno? Si puedes correr ese paso solo, reprodúcelo por separado. Distingue el parche rápido de la solución de fondo y, después de arreglar, comprueba que los pasos siguientes también pasen.
Darle 100 veces a «volver a ejecutar todo» no hace aparecer un archivo que no existe. Hace falta el número de la máquina rota, no más ganas.
8. Cloudflare no tiene un solo límite
Según la documentación oficial al 10 de octubre de 2026, el plan gratuito de Pages incluye 500 builds al mes, 1 build a la vez, 20 minutos máximo por build y hasta 20,000 archivos estáticos por sitio.[4] En un sitio grande no solo cuenta el HTML: las imágenes y los archivos del buscador también suman.
Workers tiene límites aparte para peticiones y tiempo de ejecución. Las peticiones de Pages Functions pueden contar para Workers, pero que se acabe la cuota de Workers no prueba que esa sea la razón por la que falló el build de Pages.[4][5] Si alguien grita «¡nos quedamos sin presupuesto!», primero pregunta cuál.
9. Sofisticado no es lo mismo que necesario
Una filtración de datos personales, un problema grave de seguridad o una página clave rota sí deben frenar la publicación. ¿Pero parar todo el sitio porque el orden de los artículos relacionados no quedó perfecto? Eso es otra cosa.
Divide las revisiones en tres grupos: las que bloquean la publicación / las que solo avisan / las que corren aparte, de forma periódica. El criterio es el daño real para los lectores y para quien lleva el sitio, no lo impresionante que suene el nombre de la revisión. Si por polvo en la manija de la oficina de control cierras la fábrica para siempre, el control se adueñó del negocio.
10. La trampa del «encárgate tú»
«Haz que salga mejor en Google». «Agrega idiomas». «Que no vuelva a fallar». «Suma otra revisión». La IA agrega funciones rapidísimo. Cada una parece correcta, pero si las encadenas todas puedes terminar con un sistema donde ningún artículo sale hasta que todos los departamentos pongan su sello.
No es un problema exclusivo de la IA: los equipos humanos también acumulan funciones de más y deuda técnica. La IA solo lo hace más rápido. No necesitas escribir cada línea de código, pero sí decidir qué hay que proteger, qué puede esperar y dónde parar. Le pides a la IA que barra el piso y arma un comité de supervisión de la aspiradora robot. El piso sigue sucio.
11. Volver a publicar en 3 pasos
Parar la hemorragia: pausa las funciones nuevas, protege la última versión que se publicó bien y encuentra el primer fallo. No apagues a la ligera las revisiones de privacidad o seguridad.
Separar: deja en cada build solo la generación de páginas que de verdad hace falta. Lo pesado, como analizar todo el sitio o las revisiones menores, pásalo a tareas aparte. Cloudflare tiene Build watch paths (para decidir qué cambios disparan un build) y caché de build.[6][7] Pero activarlos no hace que tus propios scripts de todo el sitio procesen solo lo que cambió.
Que no se repita: registra cuánto tarda cada paso, qué tipo de errores hay, cuántos archivos se generan, cuántas publicaciones salen bien y cuánto tardas en recuperarte. El éxito no es «la IA dijo que lo arregló»; es una versión que pasó todas las revisiones y quedó publicada de verdad.
12. Quizá el jefe final sea el cableado de tu propia fábrica
Manejar muchos artículos, muchos idiomas, enlaces relacionados y controles de calidad es difícil de verdad. Pero no hace falta meter todo eso en un solo build. Pregúntate por qué esa advertencia frena la publicación, por qué se recalcula todo cada vez y qué tareas podrían seguir por su cuenta.
Lo ideal: mientras duermes, los artículos riesgosos se frenan, los seguros salen y solo te avisa el paso que se rompió.
IA: «¡Todo listo!» Persona: «¿Y ya está publicado?» IA: «Falló el build».
Lo único totalmente automático era la fábrica de excusas.
- Astro Docs, CLI reference: astro build docs.astro.build
- Cloudflare Docs, Build configuration (updated 2026-09-18) developers.cloudflare.com
- Cloudflare Docs, Debugging Pages (updated 2026-06-02) developers.cloudflare.com
- Cloudflare Docs, Pages limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Workers limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Build watch paths (updated 2026-04-21) developers.cloudflare.com
- Cloudflare Docs, Build caching (updated 2026-05-27) developers.cloudflare.com
