Respuesta corta

Las aplicaciones codificadas por Vibe se muestran en el lado del cliente, por lo que los rastreadores ven un <div> vacío. Lo solucionas colocando un Cloudflare Worker entre tu dominio y Lovable que devuelve HTML renderizado por el servidor a los bots, o migrando el proyecto a una pila real (Claude Code + Supabase + Vercel) antes de invertir en marketing.

Herramientas como Lovable, Bolt y v0 son increíbles para presentar una idea en una tarde. No son buenos en SEO. Toda la página es un paquete React del lado del cliente, lo que significa que el robot de Google en su primer rastreo ve un <div id="root" /> vacío. Sin contenido. Sin títulos. Sin esquema. Sin clasificaciones. Para un MVP que depende del tráfico orgánico, ese es un problema del año de fundación.

Estas son las dos correcciones que utilizamos en Start Apps Studio, ordenadas desde el menor esfuerzo hasta el mayor beneficio.

Solución 1: proxy SSR de Cloudflare Worker

Un Cloudflare Worker se sitúa entre tu dominio y Lovable. Cuando llega una solicitud, el Worker comprueba el User-Agent: los visitantes reales se redirigen a Lovable como siempre; los bots (Googlebot, Bingbot, GPTBot, PerplexityBot, ClaudeBot) reciben HTML renderizado en el servidor con contenido real y schema markup completo desde la misma URL.

Esto no es un encubrimiento cuando se hace correctamente. El contenido que recibe el bot debe coincidir con lo que el usuario finalmente ve una vez que se ejecuta JS. La configuración consta de dos pasos:

  1. Agregue un CNAME a su DNS apuntando su dominio personalizado a Cloudflare Worker.
  2. Pegue un prompt dentro de Lovable para que el Cloudflare Worker tenga un inventario de páginas canónicas desde el que renderizar en el servidor.

Solución 2: migrar de Lovable con Claude Code

El Cloudflare Worker te da tiempo. Pero si la aplicación tiene que posicionarse en serio, manejar contenido dinámico o ser mantenida por personas dentro de un año, querrás pasar a una pila web "normal". La forma más rápida que hemos visto es dejar que Claude Code haga la migración por ti.

La receta de migración de 10 pasos

  1. Envía tu proyecto Lovable a GitHub para que Claude pueda trabajar con él fácilmente.
  2. Instale Claude Code localmente para que pueda leer y editar su repositorio directamente.
  3. Apunte a Claude a su repositorio (ruta local o remota de GitHub).
  4. Cree un proyecto Supabase para base de datos y autenticación (aproximadamente cinco minutos).
  5. Pídale a Claude que migre el proyecto fuera de Lovable con este mensaje: "Migra este proyecto de Lovable a una pila web normal y organiza el repositorio de manera limpia".
  6. Configure el hosting en Vercel. El nivel gratuito cubre la mayoría de los MVP.
  7. Pregúntele a Claude qué variables de entorno y claves API se requieren; es sorprendentemente bueno para identificarlos.
  8. Genere las claves y cree un archivo .env (claves Supabase, tokens API, etc.).
  9. Pídale a Claude que configure la implementación. Puede cablear el flujo GitHub → Vercel y conectar Supabase.
  10. Arregle cualquier cosa que no funcione pidiéndole a Claude que depure, un error a la vez.

Esta configuración termina siendo más flexible que el propio Lovable. Dejas de pagar créditos por solicitud para cambios en la aplicación y puedes recurrir a modelos gratuitos para pequeñas ediciones, ya que Lovable ya está usando Claude bajo el capó durante la mayor parte de su generación.

El híbrido Lovable + Claude

Si estás en mitad del proyecto y no estás listo para migrar, hay un camino intermedio que varios usuarios de r/lovable han validado: conecta Lovable a GitHub y luego dale a Claude Code acceso al mismo repositorio. Claude se sienta en una capa encima de Lovable, guiándolo a través de características complejas, depuración y mejoras, mientras usted ejecuta SQL directamente en Supabase para cambios en la base de datos (Lovable no cobra por ejecutar una consulta, por lo que es gratis).

Resultados: menos créditos quemados en componentes de bloqueo (los usuarios informan que se han ahorrado más de 100 créditos en un solo componente), mejor manejo de la lógica enredada y, algo fundamental para este artículo, suficiente control sobre el HTML de salida para que pueda actualizar SSR y el esquema de forma incremental.

¿Qué solución deberías elegir?

  • Solo sitio de marketing o página de destino → Cloudflare Worker SSR. Más barato, más rápido.
  • Producto con contenido dinámico que necesita clasificarse → migrar a Claude Code + Supabase + Vercel.
  • A mitad del proyecto y no puedo reconstruir → Lovable + Claude híbrido, luego modernizar SSR en las páginas que importan.

Preguntas frecuentes

¿Por qué Google no puede indexar las páginas Lovable directamente?

Lovable envía un paquete React renderizado por el cliente, por lo que el HTML inicial es un div raíz vacío. El rastreo de primer paso del robot de Google captura ese HTML vacío; puede (o no) volver más tarde para representar JavaScript. Para dominios nuevos sin autoridad, ese procesamiento de segundo paso a menudo nunca se activa.

¿Se considera encubrimiento la solución de Cloudflare Worker?

No si el bot ve el mismo contenido que un usuario eventualmente ve una vez que se ejecuta JS. Servir HTML prerenderizado a bots es un patrón de SEO establecido; solo se vuelve encubrimiento si ofrece contenido diferente a los bots que a los usuarios.

¿Cuánto cuesta la migración completa?

Bricolaje: un fin de semana y una cuenta gratuita de Vercel + Supabase. Proporcionado por Start Apps Studio: normalmente alrededor de un sprint, incluido en nuestro paquete MVP Production.

¿Puedo seguir editando visualmente después de migrar?

Pierdes el editor en el navegador de Lovable, pero obtienes un bucle de desarrollo normal y puedes incorporar cualquier herramienta visual (u otro creador de IA) en la parte superior del repositorio. La mayoría de los equipos no se lo pierden una vez que ven cuán rápido itera Claude Code.