«Hazme una web de artículos. Del resto te encargas tú». La IA añade artículos, idiomas, enlaces recomendados, buscador, controles de calidad, seguridad y reparaciones automáticas. Un quiosco se convierte en una fábrica con traductores, inspectores, auditores y una comisión que aprueba las comas.
Entonces se enciende una luz roja: BUILD FAILED. La IA dice «arreglado»; el siguiente intento falla. Se derrota al jefe final y aparece otro jefe final. Esta es una explicación general basada en Cloudflare Pages y Astro, no el diagnóstico de un sitio privado concreto.
1. ¿Qué hace realmente un build?
Markdown, imágenes, estilos y programas son materiales de partida, no una web necesariamente terminada. Un build los convierte en páginas y archivos que entiende el navegador. Astro suele generar archivos estáticos publicables en la carpeta dist.[1]
El texto es la receta; el build, la cocina. No se puede servir una cebolla cruda junto a un recetario y anunciar que la cena está lista.
2. ¿Qué hace Cloudflare?
Cloudflare Pages puede descargar código de Git, ejecutar el comando configurado por el proyecto y publicar los resultados.[2] El proceso habitual es obtener archivos, preparar herramientas, hacer comprobaciones previas, crear páginas, revisar la salida y desplegar. Cada proyecto puede modificarlo.
Build significa fabricar; deploy significa entregar y publicar. Si falla el build, la nueva versión no logra desplegarse correctamente. Cloudflare ofrece la nave industrial, pero el laberinto de la cadena de producción puede haberlo diseñado el sitio.
3. La fábrica trabaja incluso antes de generar una página
Un blog sencillo quizá solo convierta Markdown en HTML. Una fábrica de artículos puede revisar permisos de publicación, traducciones, identificadores y URL, artículos relacionados, enlaces internos, índices de búsqueda, títulos, descripciones de imágenes, anuncios y reglas de seguridad.
Cada paso tiene sentido. El problema surge cuando cambiar una frase obliga a todos los departamentos a repetir la reunión de primera hora. Se quería corregir una errata; ha venido toda la plantilla con casco.
4. ¿Por qué pesan las páginas y los idiomas?
Diez mil páginas no implican necesariamente diez mil veces más trabajo. Pero hay más archivos y relaciones, y cada idioma añade URL correspondientes, traducciones e información de búsqueda. Comparar siempre cada artículo con todos los demás puede ser caro.
Conviene reutilizar cálculos, procesar solo lo que cambió cuando sea posible y medir los tiempos reales. Añadir un libro a una biblioteca no debería obligar a reorganizar todas las estanterías del país.
5. ¿Por qué sale otro error tras cada arreglo?
Si las etapas se ejecutan en serie, un fallo inicial impide descubrir los siguientes. Se arreglan los datos y falla la revisión de enlaces. Se arreglan los enlaces y falla la generación de páginas. Después puede fallar el índice de búsqueda.
Eso no demuestra que cada arreglo creara un fallo nuevo. Tal vez todos estaban esperando turno. Una reparación sí puede introducir un problema nuevo, por lo que hay que comparar registros y cambios. Se abre una puerta y hay otra. Todas dicen «último nivel».
6. Seis clases de fallo
Código y dependencias: errores de sintaxis, paquetes ausentes o versiones incompatibles. Datos: material faltante o mal formado. Validaciones: página generable pero rechazada por una regla. Recursos: tiempo, memoria o límite de archivos. Entorno: diferencias entre el equipo y la nube. Despliegue: falla la verificación final o la subida.
Cloudflare Pages marca un build como fallido cuando el comando devuelve un código distinto de cero.[2] La última línea roja no siempre es la causa. Es la portada de una novela policíaca, no la confesión.
7. ¿Cómo investigar el registro?
En los detalles de cada despliegue de Cloudflare se encuentra el Build log.[3] Busca la primera etapa que realmente falló, no solo el último aviso rojo. Clasifica si es dato, código, regla, recurso o entorno. Si puedes, reproduce esa etapa por separado; distingue un apaño de una solución de fondo y verifica las etapas posteriores.
Pulsar cien veces «ejecutar todo de nuevo» no hace aparecer mágicamente un archivo inexistente.
8. Los límites de Cloudflare son distintos entre sí
Según la documentación consultada el 10 de octubre de 2026, Pages Free permite 500 builds mensuales, uno simultáneo, un límite de 20 minutos por build y hasta 20.000 archivos estáticos por sitio.[4] También cuentan los archivos de imágenes y búsqueda.
Workers tiene sus propios límites de peticiones y ejecución. Algunas peticiones de Pages Functions se computan en Workers, pero agotar una cuota Workers no prueba por sí solo por qué falló un build de Pages.[4][5] Si alguien grita «no queda dinero», hay que preguntar en cuál de las cuentas.
9. Sofisticado no es sinónimo de necesario
Una filtración de datos personales, un fallo grave de seguridad o una página esencial rota deben bloquear una publicación. Pero un orden imperfecto de artículos recomendados puede requerir solo una advertencia.
Divide las comprobaciones en bloqueantes, advertencias y tareas periódicas separadas, según el daño real. Si una mota de polvo en la puerta de auditoría cierra toda la fábrica, la auditoría se ha adueñado del negocio.
10. La trampa de ampliar con IA
«Mejora el SEO», «añade idiomas», «evita errores», «crea otra auditoría». La IA puede sumar funciones a gran velocidad. Individualmente parecen correctas, pero conectadas acaban exigiendo el sello de todos los departamentos para sacar un solo artículo.
Las personas también crean esta deuda técnica; la IA acelera el proceso. No hay que escribir personalmente todo el código, pero sí decidir qué debe bloquearse, qué puede esperar y qué depende realmente de qué. Se le pide que barra el suelo y crea un consejo supervisor del robot aspirador. El suelo sigue sucio.
11. Recuperación en tres pasos
Estabilizar: pausar añadidos opcionales, conservar la última versión correcta, identificar el primer fallo y no desactivar sin más las protecciones de privacidad y seguridad.
Separar: dejar en el camino de publicación solo lo imprescindible; ejecutar auditorías pesadas y análisis de todo el sitio aparte. Cloudflare ofrece Build watch paths y caché de build, pero no vuelve automáticamente incrementales los programas propios.[6][7]
Prevenir: medir duración de etapas, tipos de fallos, archivos generados, tasa de éxito y tiempo de reparación. «La IA dijo que lo arregló» no equivale a publicar correctamente.
12. Quizá el jefe final sea el cableado de la fábrica
Publicar, traducir, enlazar y comprobar muchos artículos es realmente difícil. Pero no hace falta meter todo en un único build gigantesco. Pregunta por qué una advertencia bloquea la publicación, por qué se recalcula todo y qué trabajos pueden continuar solos.
La fábrica ideal retiene lo peligroso, entrega lo seguro y señala exactamente la máquina averiada.
IA: «¡Todo listo!» Persona: «¿Está publicado?» IA: «Falló el build».
Al final, lo único totalmente automático era la fabricación 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
