Pantalla en blanco en tu app de Lovable: encuentra el error
Una página en blanco al publicar significa que la app falló antes de dibujarse. Cómo leer la consola, qué indica cada error común y cómo arreglarlo.
Read in English →
Una pantalla en blanco en una app de Lovable ya publicada quiere decir que el JavaScript que dibuja tus páginas se rompió en el primer momento o ni siquiera llegó a cargar. La página sí llegó al navegador, así que el servidor está bien: algo se detuvo del lado del navegador. Abre el sitio publicado, abre la consola y lee el primer error en rojo. Ese error te dice cuál de unas pocas causas tienes, y la mayoría se arregla en minutos una vez que la conoces.
Aquí verás cómo obtener el error en menos de un minuto, una tabla con los errores que provocan casi todas las pantallas en blanco, qué revisar dentro de Lovable y cómo lograr que la próxima falla muestre un mensaje en lugar de una página vacía.
¿Por qué se ve en blanco si en la vista previa funciona?
La vista previa y el sitio publicado no son el mismo entorno. El sitio publicado es una compilación aparte de la última versión que publicaste, en otra dirección y, muchas veces, con datos reales y visitantes sin sesión. Por eso "en el editor funciona" descarta poco. Una página en blanco casi siempre viene de alguna de estas situaciones:
- a la compilación publicada le falta un valor que necesita al arrancar (una variable de entorno),
- el código se rompe con datos que la vista previa nunca tuvo (una lista vacía, un campo que falta, un usuario sin sesión),
- el navegador guarda una copia vieja de la página que apunta a archivos que ya no existen,
- tus últimos cambios nunca salieron porque la compilación falló o no se publicó.
¿Cómo veo el error de verdad?
- Abre la dirección publicada (tu dominio o la URL
lovable.app), no la vista previa del editor. - Abre las herramientas de desarrollo: clic derecho en la página y Inspeccionar, o F12 (Cmd+Option+I en Mac).
- Entra a la pestaña Console y recarga la página.
- Busca el primer error en rojo. Los que vienen después suelen ser consecuencia.
- Pasa a la pestaña Network, recarga y busca filas en rojo, sobre todo archivos
.jscon 404.
Si solo falla en el celular, intenta reproducirlo en una computadora con la misma cuenta y anota el modelo y el navegador.
¿Qué significan los errores más comunes?
| Lo que ves | Qué significa | Qué hacer |
|---|---|---|
supabaseUrl is required. | La dirección del backend no estaba disponible al compilar | Revisa que VITE_SUPABASE_URL y VITE_SUPABASE_PUBLISHABLE_KEY estén en .env (o en los ajustes de tu hosting) y vuelve a compilar |
Cannot read properties of undefined (reading 'map') o parecido | El código espera datos que ese usuario no tiene | Contempla el caso vacío y revisa que la consulta devuelva lo que la página espera |
Failed to load module script con MIME type "text/html" | La página pide un archivo de script que ya no existe y el hosting responde con HTML | Recarga forzada; si sigue, vuelve a publicar y revisa que nada guarde en caché index.html |
Failed to fetch dynamically imported module | La pestaña abierta del visitante es de una versión anterior | Recargar lo arregla; en el código, recarga una vez cuando aparezca este error |
| Sin error, pero un 404 en la propia página | Solo en hosting propio: falta la regla que manda todas las rutas a index.html | Agrega esa regla en tu hosting |
Errores con 401 o permission denied | La app se cae cuando le niegan una petición | Corrige la política o la sesión, y maneja el rechazo sin romper la página |
Variables de entorno que faltan
Lovable guarda los valores que puede ver el navegador, como VITE_SUPABASE_URL, en el archivo .env del proyecto y los mete en la compilación. La documentación de secretos de Lovable advierte que no agregues .env a .gitignore en un proyecto de Lovable, porque la compilación lo necesita. Si un desarrollador o un prompt "limpió" ese archivo, la siguiente compilación sale sin esos valores y el cliente de Supabase falla al arrancar. Si alojas el frontend en otro lado, esos mismos valores tienen que estar en los ajustes de ese hosting, y hay que volver a compilar después de cargarlos.
Fallas con datos reales
La vista previa suele correr con tu cuenta y datos de prueba prolijos. En producción hay usuarios nuevos sin registros, registros viejos con campos vacíos y visitantes sin sesión. Pide a Lovable un arreglo puntual y pásale la línea completa del error, con archivo y número de línea:
Mi app publicada muestra una pantalla en blanco. Este es el primer error de la consola:
TypeError: Cannot read properties of undefined (reading 'map') at Dashboard (index-abc123.js:212)
Corrige solo el código relacionado y contempla el caso en que la lista esté vacía o no exista.¿Qué reviso dentro de Lovable?
- ¿La publicación funcionó? Abre el diálogo de Publish. Si dice Build errors need fixing, el sitio en vivo sigue con la versión anterior, o con una rota. Usa Try to fix y vuelve a publicar.
- ¿Tus últimos cambios están en vivo? Cada publicación es una foto fija. Un puntito en el botón Publish indica cambios nuevos: haz clic en Publish y luego en Publish changes.
- ¿Un revert o un push de Git cambió algo? Mira en el historial el último cambio antes de que apareciera la pantalla en blanco.
- ¿El backend está en pausa? Si el backend integrado (Cloud) está pausado, las edge functions se detienen y lo que dependa de ellas falla.
Si el error apunta al backend y no a la página, los registros de More → Cloud → Logs muestran la petición que falla. Los proyectos creados desde mayo de 2026 usan TanStack Start y arman las páginas en el servidor, así que una falla ahí también puede dejar rastro en Server logs.
¿Cómo confirmo que quedó arreglado?
- Abre el sitio en una ventana privada y sin sesión. La página de inicio debe aparecer.
- Entra con una cuenta de prueba nueva, sin datos. Es el caso que más se rompe.
- Entra con una cuenta real que tenga muchos datos.
- Abre directamente una ruta interna, como
/ajustes, y recarga. - Prueba desde un celular con datos móviles, no solo con el wifi de la oficina.
¿Cómo evito que la próxima falla sea una página en blanco?
- Agrega un error boundary. En React, un error boundary atrapa la falla de una parte de la página y muestra un mensaje ("Algo salió mal, recarga") en vez de nada. Pídele a Lovable que lo ponga alrededor de las rutas principales.
- Activa el monitoreo. Project monitoring de Lovable (en beta, desde el plan Pro) revisa los errores recientes de tus visitantes y te avisa. Una herramienta de seguimiento de errores da más detalle; lo explicamos en monitoreo y errores en producción.
- Revisa el sitio en vivo después de cada publicación, no solo la vista previa. Dos minutos en una ventana privada atrapan la mayoría de estos casos.
Si algo que ayer funcionaba hoy dejó de hacerlo, sigue la guía de qué hacer cuando tu app de Lovable o Bolt dejó de funcionar. Y si ya probaste varios arreglos con IA sin suerte, cómo cortar el bucle de arreglos de Lovable te va a ahorrar créditos.
Respuestas rápidas
¿Por qué solo algunas personas ven la página en blanco? Porque sus datos o su sesión provocan una falla que los tuyos no, o porque su navegador guarda una versión vieja. Pídeles el primer error de la consola.
¿Una pantalla en blanco significa que perdí mis datos? No. Falló el dibujo de la página. La base de datos está aparte y casi nunca se ve afectada.
¿Vuelvo a publicar para arreglarlo? Solo cuando sepas la causa. Publicar el mismo código vuelve a generar la misma falla, salvo que el problema fuera una compilación vieja o fallida.
¿Sigues viendo la página en blanco?
Si la consola no dice nada útil o cada arreglo mueve el error a otro lado, una revisión corta del código suele encontrarlo. Prueba el chequeo gratuito de tu app, mira cómo arreglamos apps de Lovable o mándanos la dirección y el error.
