deploy
Tu app se ha publicado, el servidor responde, pero el navegador pinta una página vacía. Casi siempre significa que el JavaScript ha fallado nada más arrancar y se ha parado antes de dibujar nada.
Revisado en agosto de 2026
De paso
Analízala gratis mientras lees. Tarda treinta segundos y no toca nada.
Solo leemos lo que tu app ya le entrega a cualquier visitante.
Diagnóstico
Una app moderna se dibuja entera desde JavaScript: el HTML que llega al navegador está prácticamente vacío y es el código el que lo rellena. Si ese código se cae en la primera línea, nadie rellena nada y te quedas con el fondo blanco. No es que falte la página, es que se ha interrumpido antes de pintarla.
Las causas más frecuentes, por orden: una variable de entorno que falta en producción y hace que algo llegue vacío, y ahí entra el clásico supabaseUrl is required; una ruta de ficheros que en tu ordenador funciona y en el servidor no, porque el editor no distingue mayúsculas y el servidor sí; o una llamada a datos que falla y no está controlada, de modo que el error tumba la aplicación entera en vez de mostrar un aviso.
El diagnóstico es siempre el mismo y lleva dos minutos: abre la app publicada, pulsa F12, ve a la pestaña Console y recarga. El primer mensaje en rojo es tu causa. La pantalla en blanco no es el problema, es el síntoma, y ese mensaje es el problema.
Solución
Primero encuentra el mensaje real, luego actúa. Saltarse este orden es lo que hace que la gente pase horas redesplegando sin cambiar nada.
Si la consola sale limpia y aun así ves blanco, mira la pestaña Network y comprueba que los ficheros de JavaScript se están descargando con código 200 y no con 404.
Pégaselo tal cual al agente que escribió tu app. Está redactado para que te diga lo que ha hecho, no solo para que lo haga.
Prompt para tu agente
Mi app se ve bien en el editor pero sale completamente en blanco al publicarla. En la consola del navegador, el primer error en rojo dice: [PEGA AQUÍ EL MENSAJE COMPLETO]. Necesito que hagas esto: 1. Identifica qué parte del código provoca ese error concreto y explícame en dos frases por qué falla solo en producción y no en local. 2. Añade un límite de error en la raíz de la aplicación, de forma que si algo falla al arrancar se muestre un mensaje comprensible en pantalla en vez de dejarla en blanco. Ese mensaje no debe enseñar detalles técnicos al visitante. 3. Revisa todas las variables de entorno que la app necesita para arrancar y añade una comprobación al inicio que, si falta alguna, diga por su nombre cuál falta. 4. Revisa que las llamadas a datos del arranque tengan manejo de errores y que un fallo de red no tumbe la aplicación entera. Al terminar, dime la lista exacta de variables de entorno que tengo que tener dadas de alta en mi hosting.
Si no sale
O el escáner de arriba ha encontrado algo y prefieres no tocarlo solo. En cualquiera de los dos casos esto ya es de los gordos y merece un humano: no es que no hayas sabido, es que has llegado al punto en que hace falta alguien que entre y lo vea por dentro.
Las 10 primeras apps son gratis. Estoy empezando y necesito casos reales. A cambio te pido permiso para contar después qué me encontré, sin decir de quién era la app ni enseñar tus datos. Sin tarjeta y sin suscripción: cuando se acaben las plazas empezaré a cobrar y lo diré aquí.
Cita a partir de mañana
Gratis
durante el lanzamiento
Elegimos hueco, miro tu app con calma y te digo qué pasa y cómo se arregla.
Hoy, en cola prioritaria
Gratis
durante el lanzamiento
Entras en la cola de hoy. Reservas hueco y lo dejamos resuelto en el día.
Quién
Marc Sala
IT Manager
No es un rating anónimo de un marketplace: es la persona que va a entrar en tu app. Reviso el código, encuentro qué falla y lo arreglo contigo delante, explicándote qué ha pasado sin jerga.
Relacionados