La vista previa funciona pero el sitio en vivo falla: qué comprobar

Qué significa realmente “la vista previa funciona” y “el sitio en vivo falla"

Un enlace de preview es una versión temporal de tu app que se ejecuta en un entorno controlado por tu builder u host. A menudo usa un dominio estándar, ajustes por defecto y un entorno “amigable” donde hay menos reglas que interfieren.

Un sitio en vivo es tu dominio real con ajustes de producción. Los navegadores lo tratan de forma distinta: las cookies se adjuntan al dominio, se aplican reglas HTTPS y tu app debe hablar con el backend correcto con los permisos adecuados.

Así que cuando alguien dice “preview funciona pero en vivo falla”, suele significar que la app se ve bien en la demo y luego se rompe al toparse con las reglas del dominio real.

El fallo puede manifestarse de varias formas comunes: una página en blanco o spinner infinito, un bucle de login (inicias sesión y te devuelven al login), botones que no hacen nada porque las llamadas a la API fallan, datos que faltan aunque la UI cargue, o errores que sólo ocurren en el dominio en vivo.

Además, “funciona” puede ser engañoso. Muchas apps creadas con IA “funcionan” en preview porque la UI se renderiza. Las partes importantes fallan silenciosamente en producción: peticiones a la API, autenticación, subidas, pagos o lecturas de base de datos.

Un ejemplo simple: en preview tu app llama a una API usando una URL de prueba y CORS permisivo, así que las peticiones tienen éxito. En el dominio en vivo, las mismas llamadas se bloquean o la app sigue apuntando a localhost. La página carga, pero nunca aparece la información.

Por eso la primera pregunta no es “¿carga?” sino “¿tienen éxito las llamadas de red en el dominio en vivo?” Si heredaste un prototipo generado por IA, una auditoría rápida de código (como las que hace FixMyMess) suele encontrar el desajuste rápido: una variable de entorno equivocada, un ajuste de cookie atado al dominio de preview o una regla HTTPS que preview no aplicó.

Diferencias de dominio que cambian el comportamiento de la app

Cuando preview funciona y en vivo falla, sospecha del hostname desde el principio. Los navegadores tratan app-preview.example y example.com como lugares distintos, aunque el código sea idéntico. Eso cambia qué cookies se envían, qué reglas de seguridad se aplican y a qué URLs puede llamar tu app.

Una trampa común es pasar de un dominio temporal de preview a un dominio real y suponer que todo se conserva. En realidad, muchos ajustes están ligados a un origen exacto (esquema + host + puerto). Un carácter de diferencia puede convertir funciones que funcionan en funciones rotas.

Subdominio vs dominio raíz: pequeño cambio, gran impacto

Pasar de app.example.com a example.com (o viceversa) puede romper comportamientos que dependen del alcance del dominio. Las cookies pueden establecerse para un host y no aparecer nunca en el otro. Algunos sistemas de auth también esperan un dominio específico para callbacks y orígenes permitidos.

Lo mismo ocurre con www vs sin www. Si tu sitio en vivo redirige de www.example.com a example.com, la app puede cargar bien pero el login fallar porque el proveedor de auth ve una URL de callback distinta a la registrada.

Las descoincidencias de dominio que con más frecuencia causan fallos inmediatos son:

• www vs sin www (las redirecciones cambian la URL final).
• dominio raíz vs subdominio (el alcance de las cookies y orígenes permitidos difiere).
• hostnames de preview distintos por deploy (URLs hardcodeadas dejan de coincidir).
• dominios de staging vs producción (auth y ajustes de API apuntan al lugar equivocado).
• barra final o diferencias de path en URLs de callback (algunos proveedores las tratan como diferentes).

Un ejemplo rápido: tu preview corre en un dominio temporal y el proveedor de login está configurado con ese callback. Lanzaste en www.tuapp.com, el proveedor rechaza el callback y los usuarios ven una página en blanco o un bucle de login. Nada en la UI explica por qué.

Esto es especialmente común en apps generadas por IA porque los dominios se hardcodean en varios sitios (frontend, backend, ajustes de auth). FixMyMess suele encontrar varios lugares donde un único hostname debe coincidir exactamente para que producción se comporte como preview.

Ajustes de entorno: el rompe-producción silencioso

Los entornos de preview suelen “funcionar” porque la plataforma provee valores por defecto silenciosamente. Tu sitio en vivo normalmente no. Esa brecha es una de las principales razones por las que preview tiene éxito mientras producción falla, aunque el código sea idéntico.

Un patrón común es que preview inyecta una URL de API de fallback, una base de datos demo o un modo de auth permisivo. Producción espera valores reales. Cuando faltan, la app sigue funcionando pero se comporta de forma extraña: botones que no hacen nada, páginas con estados vacíos o todas las peticiones fallando.

Los problemas de entorno más habituales en producción se ven así:

• Falta una variable requerida (URL base de API, secreto de auth, URL de la base de datos, claves de pago).
• Hay un valor pero es incorrecto (endpoint de dev, clave de prueba, dominio de staging antiguo).
• Las variables están definidas en un lugar pero leídas en otro (definidas en el dashboard del host, pero el build espera un .env en tiempo de build).
• Los nombres no coinciden exactamente (NEXT_PUBLIC_API_URL vs NEXT_PUBLIC_API_BASE).
• El valor tiene un fallo sutil (slash extra, región equivocada, client ID erróneo).

Otra trampa es dónde se usa la variable. Las variables del lado cliente acaban en el navegador, así que deben ser seguras de exponer. Las variables del lado servidor quedan en el servidor, pero sólo si el código realmente se ejecuta en servidor. Las apps generadas por IA a veces filtran secretos al código frontend. Eso puede “funcionar” en preview y fallar en producción cuando las claves se rotan o entran reglas de seguridad. Además, es un riesgo real de seguridad.

Para detectar un problema de env rápido, revisa logs en vivo y la consola del navegador buscando:

• errores que mencionen undefined o null.
• respuestas 401/403 (clave mala, audiencia equivocada, issuer incorrecto).
• peticiones que van al host equivocado (dominio de dev apareciendo en producción).
• errores de build/arranque como “Missing required env var”.

Ejemplo: el login funciona en preview porque usa un callback de preview, pero en producción sigue apuntando al dominio de preview. El proveedor de auth lo rechaza y los usuarios ven un 401 o un bucle de login.

Si heredaste un código generado por IA y no sabes de dónde viene un valor, FixMyMess puede ejecutar una auditoría gratuita de código y listar qué falta o qué está mal configurado antes de que cambies algo.

HTTPS, redirecciones y problemas de contenido mixto

Un preview puede funcionar porque se ejecuta en el dominio de una plataforma con una configuración conocida y correcta. Al pasar a tu propio dominio, el navegador se vuelve más estricto. Pequeñas malas configuraciones pueden evitar que la app cargue, que se inicie sesión o que llame a APIs.

HTTPS es más estricto que muchos entornos de preview

HTTPS no es solo un icono de candado. Cambia lo que el navegador permite. Las peticiones pueden bloquearse, las cookies comportarse distinto y las redirecciones crear bucles que no aparecieron en preview.

Un ejemplo típico: el sitio en vivo carga por https://, pero la app sigue llamando a una API en http://api.example.com. En preview puede que no lo notes porque todo está en el mismo dominio de la plataforma o las advertencias son fáciles de pasar por alto.

Contenido mixto: el bloqueador silencioso

El contenido mixto ocurre cuando una página HTTPS carga algo por HTTP (API, imágenes, scripts). Los navegadores modernos suelen bloquear esas peticiones, lo que puede hacer que la app parezca “rota” sin un error evidente en pantalla.

Para confirmarlo rápido:

• Abre el sitio en vivo (no el preview).
• Abre la consola del navegador y recarga.
• Busca errores como “Blocked mixed content” o similares.
• Revisa la pestaña Network para peticiones que estén bloqueadas, canceladas o atascadas en redirecciones.

Redirecciones, HSTS y bucles

Los bucles de redirección a menudo ocurren cuando varias capas no coinciden. Por ejemplo:

• la app fuerza HTTPS, pero la plataforma de hosting ya lo hace.
• un CDN fuerza www, pero la app fuerza no-www.
• HSTS está habilitado, por lo que el navegador se niega a intentar HTTP de nuevo.

Cuando esto ocurre, la página puede parpadear, recargarse sin fin o fallar antes de que se ejecute tu código.

Los certificados también importan. Si el certificado es inválido o no está emitido para el dominio personalizado todavía, algunos navegadores bloquearán las peticiones o impedirán que los flujos de inicio de sesión se abran correctamente.

Si la consola está llena de advertencias de contenido mixto y errores de redirección, un enfoque habitual es mapear cada petición que hace la app en vivo y luego corregir URLs HTTPS y reglas de redirección para que producción se comporte como preview.

Cookies y autenticación: por qué fallan los inicios de sesión en vivo

Cuando preview funciona y en vivo falla, el inicio de sesión suele ser lo primero que se rompe. Preview se siente “normal”, pero el dominio en vivo cambia cómo el navegador trata cookies, redirecciones y el almacenamiento de sesión.

Las cookies están ligadas a un dominio. Si preview corre en el dominio de la plataforma y el sitio en vivo en tu dominio personalizado, el navegador puede dejar de enviar la cookie de sesión aunque no cambies código.

Flags de cookie que causan sorpresas

Tres ajustes deciden si tu cookie de login sobrevive la mudanza a producción:

• Domain scope: una cookie establecida para preview.example-host.com no se enviará a www.tudominio.com. Hardcodear el dominio de la cookie suele funcionar en preview y fallar silenciosamente en vivo.
• SameSite: los logins basados en redirecciones (Google, GitHub, magic links) pueden romperse si SameSite=Strict bloquea la cookie en el viaje de vuelta. Lax suele ser más seguro para flujos básicos.
• Secure: las cookies Secure sólo se envían por HTTPS. Si tu sitio en vivo tiene un paso por HTTP (o una cadena de redirecciones complicada), la cookie puede no pegarse.

Síntomas típicos:

• el login “tiene éxito” pero vuelves a la pantalla de login.
• obtienes un bucle: login, redirección, login otra vez.
• funciona una vez en una ventana incógnito y luego falla.
• funciona en preview pero falla sólo en tu dominio real.

OAuth y auth alojada: orígenes permitidos y URIs de redirección

Los proveedores de auth no confían automáticamente en tu dominio personalizado. Los entornos de preview a veces están en una whitelist por defecto, mientras que tu dominio real no. El proveedor puede rechazar el callback, o tu app puede recibir el callback pero fallar el intercambio de código porque el origen no coincide.

Ejemplo: preview usa https://random-preview-host.com y el proveedor está configurado para eso. Cambias a https://app.tudominio.com, pero el proveedor aún sólo permite el origen de preview. La redirección parece bien, luego terminas en una página en blanco, un toast de error o la pantalla de login de nuevo.

Antes de cambiar código, haz estas comprobaciones en DevTools:

• Confirma que el sitio en vivo es totalmente HTTPS sin pasos por HTTP.
• Inspecciona el header Set-Cookie (Domain, SameSite, Secure, expiry).
• Verifica que la cookie aparece bajo el almacenamiento del dominio en vivo y se envía en la siguiente petición.
• Para OAuth, confirma que el dominio en vivo está listado en orígenes permitidos y en los ajustes de redirect/callback.

Los fallos de auth son una reparación común. Se traza la cookie y la ruta de redirecciones de extremo a extremo y se parchán los ajustes descoincidentes para que el login funcione de forma fiable en el dominio en vivo.

CORS y llamadas a la API que se bloquean sólo en vivo

A veces la UI carga, pero todas las llamadas a datos fallan porque el navegador se niega a dejar que tu frontend llame a tu API. Esa negación es CORS (Cross-Origin Resource Sharing). En términos sencillos: el navegador bloquea que un sitio web envíe peticiones a un dominio diferente a menos que el servidor lo permita explícitamente.

Esto aparece más en vivo que en preview porque los hosts de preview a veces reciben un trato especial. Tu API puede permitir el dominio de preview, pero no tu dominio real.

Cómo se ven las fallas de CORS

En la consola o en la pestaña Network verás “blocked by CORS policy” o una petición preflight que falla. Un preflight es una petición OPTIONS automática que el navegador envía primero para preguntar “¿esto está permitido?”.

Los preflights ocurren más seguido de lo que la gente cree. Enviar JSON con encabezados personalizados, usar métodos como POST/PUT o incluir credenciales (cookies) puede activarlos. Si el servidor no responde OPTIONS correctamente, el navegador bloquea la petición real aunque la API funcione en herramientas como curl.

En el lado de la API (o función serverless), las comprobaciones de mayor impacto son:

• permitir el origen exacto del sitio en vivo (esquema + dominio + puerto).
• si envías cookies/encabezados de auth, permitir credenciales y no usar * como origen.
• permitir los encabezados que realmente envías (a menudo Content-Type, Authorization).
• permitir los métodos que usas y responder correctamente a OPTIONS.
• confirmar que tu reverse proxy/CDN no está eliminando los encabezados CORS en producción.

Un escenario común: una app generada por IA llama a api.myapp.com desde preview.mytool.app y funciona. Tras el lanzamiento, el frontend corre en myapp.com, pero la API aún sólo permite preview.mytool.app, así que el login y los guardados fallan en el navegador.

Si estás atascado, a menudo se encuentran problemas de CORS junto a bloqueadores relacionados (como cookies que no se envían por la configuración de credenciales) y se verifican las correcciones con pruebas reales en el navegador antes del relanzamiento.

Cachés, service workers y despliegues obsoletos

A veces no hay nada “roto” en el código. El dominio en vivo simplemente está sirviendo una versión antigua. Los servidores de preview suelen evitar las capas de caché que usa tu dominio real.

Cuando los caches sirven la versión equivocada

Un CDN o la caché del navegador puede mantener bundles JavaScript antiguos incluso después de un redeploy. Si tu build genera archivos como app.123.js, pero el HTML aún apunta a app.122.js, los usuarios cargan una mezcla de archivos viejos y nuevos. El resultado se siente aleatorio: botones que dejan de funcionar, páginas en blanco o errores que no puedes reproducir localmente.

Señales comunes de caché o assets obsoletos:

• la UI parece un diseño antiguo tras un deploy.
• archivos JavaScript o CSS devuelven 404 en la pestaña Network.
• errores que mencionan chunks faltantes o “unexpected token” en un archivo JS.
• sólo algunos usuarios ven el problema (a menudo en móvil).
• refrescar cambia el comportamiento.

Service workers: una versión mala puede quedarse

Si tu app tiene un service worker (común en plantillas PWA), puede seguir sirviendo una versión cacheada del sitio. Una versión mala puede instalarse y seguir cargando incluso después de que arregles producción. Los usuarios pueden necesitar cerrar todas las pestañas, o hay que arreglar el flujo de actualización del service worker.

Otra trampa fácil es un cambio de base URL. Si migraste desde un subdominio de preview a tu dominio real, o cambiaste el path bajo el que se hospeda la app, las rutas de los assets estáticos pueden romperse. Verás 404 para archivos que existen, pero no en la ruta que el navegador solicita.

Pruebas rápidas que evitan adivinar:

• abre una ventana incógnito y prueba el sitio en vivo.
• haz un hard refresh (Ctrl/Cmd + Shift + R).
• en DevTools, deshabilita la caché y recarga.
• busca respuestas 304/404 para archivos JS y CSS.
• si existe un service worker, désinstálalo y recarga.

Si el sitio en vivo sigue sirviendo el build equivocado, es útil determinar si es caché, service worker o un problema en la salida del despliegue antes de perder horas persiguiendo “bugs fantasma”.

Paso a paso: diagnostica el fallo en 20 minutos

Empieza nombrando el síntoma exacto en el sitio en vivo. ¿Es una página en blanco (carga), una página que carga pero no muestra datos (llamada a API) o un login que funciona en preview pero falla en vivo (auth/cookies)? Si eliges el síntoma equivocado, puedes perder una hora persiguiendo lo incorrecto.

Abre el sitio en vivo en una ventana privada nueva y abre DevTools. Mantén abiertas dos pestañas: Consola y Network. La Consola muestra los fallos más ruidosos (errores en rojo). Network muestra la primera petición que realmente falla.

1) Encuentra el primer fallo real

En la Consola busca errores que mencionen peticiones bloqueadas, CORS, contenido mixto, bucles de redirección o variables de entorno faltantes. Ignora advertencias hasta que hayas explicado el primer error en rojo.

Luego ve a Network, recarga y haz clic en la primera petición que falle (a menudo la primera XHR/fetch). Anota la URL de la petición, el código de estado y el mensaje de respuesta:

• 401/403 suele apuntar a auth, cookies o un desajuste de clave/issuer.
• 404 a menudo significa URL equivocada, ruta faltante o path de assets roto.
• 500 apunta a lógica de servidor o configuración rota.
• Peticiones que nunca terminan pueden ser DNS, HTTPS o peticiones bloqueadas por el navegador.

2) Compara preview vs en vivo like-for-like

Abre preview y en vivo lado a lado y repite la misma acción (cargar la página, clicar login, obtener datos). Compara los detalles de la petición fallida:

• diferencias en la URL (dominio, path, http vs https).
• encabezados (falta Authorization, Origin incorrecto).
• cookies (no establecidas, no enviadas, dominio equivocado).
• cuerpo de la respuesta (mensaje de error distinto entre preview y producción).

Si preview llama a api.preview-host.com pero en vivo llama a localhost, suele ser un desajuste de variable de entorno, no un bug aleatorio de producción.

Finalmente, verifica las variables de entorno de producción en tu proveedor de hosting (no sólo en el repo) y haz un redeploy limpio. Muchas apps generadas por IA mantienen valores antiguos hasta que reconstruyes y despliegas.

Si te atasca después de estas comprobaciones, una auditoría de código puede indicar si el problema son env vars, dominio/CORS, HTTPS o auth, y luego reparar con verificación manual.

Errores comunes que hacen perder más tiempo

Cuando alguien dice “preview funciona pero en vivo falla”, la causa suele no ser un bug profundo. A menudo es una simple descoincidencia entre entornos que se pasa por alto.

Los reincidentes

La mayoría del tiempo se pierde persiguiendo síntomas (pantalla en blanco, login fallido, 401s) mientras la causa raíz es una configuración básica:

• URLs de redirección de auth no actualizadas para el dominio real. El proveedor sigue permitiendo solo el hostname de preview, así que los logins en producción rebotan o hacen bucle.
• URLs de preview hardcodeadas en el frontend. Un https://preview-xyz... restante en llamadas a la API, callbacks OAuth o websockets puede romper en vivo.
• Secretos enviados al navegador. Las apps generadas por IA a veces ponen claves privadas en variables de entorno cliente o las empacan en el build. Eso puede romper producción y es un problema de seguridad.
• Preview y producción apuntando a distintas bases de datos. Preview puede usar datos de prueba mientras producción está vacía o tiene un esquema diferente.
• Arreglo aplicado pero no desplegado realmente. Cachés de build, objetivos de deploy equivocados o env updates faltantes hacen que parezca que la corrección no funcionó.

Un ejemplo realista: arreglas la discrepancia del callback OAuth, pero el sitio en vivo sigue fallando porque el frontend aún llama a la URL base de la preview. Dos pequeños errores, un resultado confuso.

Cómo evitar agujeros de conejo

Antes de reescribir código, haz estas comprobaciones:

1. Confirma que el dominio de producción está listado en todos los lugares que tu proveedor de auth espera.
2. Busca en el código el hostname de preview y reemplázalo por una configuración segura para producción.
3. Verifica qué variables de entorno son sólo servidor y cuáles se exponen al navegador.
4. Confirma que la conexión a la base de datos de producción y las migraciones coinciden con lo que preview usó.
5. Redeploy y limpia cualquier caché/CDN/build para que el sitio en vivo sirva el nuevo bundle.

Estos son los primeros puntos que se revisan en un diagnóstico de codebase porque son comunes en prototipos generados por IA y fáciles de pasar por alto.

Checklist rápido y próximos pasos

Cuando preview funciona pero el sitio en vivo falla, trátalo como una descoincidencia de configuración hasta que se demuestre lo contrario. Normalmente no buscas un bug misterioso, buscas una diferencia entre dos entornos.

Empieza con lo básico en el dominio en vivo:

• Confirma que el dominio en vivo apunta al despliegue correcto (proyecto correcto, rama correcta, build más reciente).
• Compara env vars de producción con las de preview (URL base de API, claves de auth, URLs de callback, URL de BD).
• Carga el sitio en vivo con la consola abierta y busca advertencias HTTPS, bucles de redirección y errores de contenido mixto.
• Testea auth end to end en vivo (registro, login, logout, refresh). “Funciona hasta que refrescas” suele apuntar a cookies o ajustes de dominio.
• Reprueba en una ventana privada y en móvil. Cookies antiguas, assets cacheados y service workers pueden ocultar el problema real.

Un ejemplo sencillo: en preview tu app llama a http://api.myapp.local (válido en dev), pero en producción la página es HTTPS y la API es HTTP. El navegador lo bloquea. La UI parece bien hasta que clicas un botón y entonces todo falla.

Si aún no puedes identificarlo, deja de adivinar y haz una auditoría centrada. Las soluciones más rápidas suelen venir de revisar juntos tres áreas: auth y cookies, secretos expuestos y arquitectura general (los prototipos generados por IA suelen venir con lógica enredada que sólo falla bajo condiciones reales de producción).

Si tu proyecto fue generado con herramientas como Lovable, Bolt, v0, Cursor o Replit y ahora falla en un dominio real, FixMyMess está pensado para esta situación: diagnosticar qué cambia entre preview y producción y reparar la base de código para que aguante en producción.