Lovable acortó mucho el tiempo entre decidir algo y verlo funcionando en nuestro propio sitio. Lo que no hizo fue garantizar que el sitio pudieran leerlo los buscadores y los rastreadores de IA, que la analítica registrara visitas de verdad y que las versiones en inglés y español mostraran contenido en inglés y español. Eso fue trabajo nuestro, y parte de él solo apareció meses después del lanzamiento.
Este es el relato de cómo usamos la herramienta, con los problemas incluidos. Sirve a quien esté evaluando constructores de aplicaciones con IA para el sitio de la empresa, una landing page o un producto interno.
Por qué usamos Lovable
Construimos sitios, plataformas y sistemas para clientes. Cuando llegó el momento de reconstruir el nuestro, con una identidad visual nueva y un contenido que reflejara lo que hace Cortex IQ, el proyecto tenía el destino clásico del trabajo interno: siempre se quedaba para la semana siguiente.
Lovable es un constructor de aplicaciones web en el que usted describe lo que quiere en lenguaje natural y un agente escribe y edita el código. La herramienta se llamaba GPT Engineer antes de cambiar de nombre (Lovable), y por eso, en el historial de nuestro repositorio, los commits que generó aparecen firmados por "gpt-engineer-app[bot]".
El código resultante es un proyecto React corriente: Vite, TypeScript, Tailwind CSS y componentes shadcn/ui, con base de datos y funciones de backend mediante Supabase, que la plataforma ofrece como Lovable Cloud. No es una caja negra. El proyecto se sincroniza con GitHub en ambos sentidos (Lovable Docs), así que se puede abrir el código en cualquier editor y trabajar fuera de la herramienta.
Qué construimos
El alcance no era el de una landing page: páginas institucionales, páginas de servicios, páginas de oferta construidas a partir de una única plantilla alimentada por datos, casos, blog, formularios que guardan en base de datos y envían correo, un banner de cookies que solo activa Google Analytics 4 después del consentimiento y tres idiomas (portugués, inglés y español).
Lo que funcionó fue tratar a Lovable como un desarrollador rápido que necesita un briefing preciso. Cada petición especificaba el stack, los tokens de color exactos, la jerarquía de componentes, el patrón de formularios y las reglas de internacionalización. Cuanto más contexto explícito, menos retrabajo.
Dónde tuvimos que intervenir en el lanzamiento
Tres puntos exigieron a alguien con las manos en el código o reescribiendo la petición:
- Identidad visual de una oferta. Una de las páginas de oferta salió con un tema visual distinto al del resto del sitio. Lo corregimos con un prompt de override detallado. Lección: si la identidad es específica, tiene que estar escrita en la petición, no implícita.
- Archivos para buscadores. Generar el sitemap a partir de los archivos de contenido exigió código escrito a mano. Las tareas ligadas al proceso de build siguen funcionando mejor en manos de un desarrollador.
- Conflictos de dependencias. Versiones incompatibles entre librerías rompieron el build más de una vez. Es el ritmo del ecosistema JavaScript, no un defecto de la herramienta, pero alguien tiene que detectarlo antes de publicar.
Lo que apareció después del lanzamiento
Esta sección se añadió en septiembre de 2026, con el sitio unos meses en producción. Es la parte más útil del relato, porque son problemas que no aparecen en la vista previa.
Todo el mundo leía en portugués. Las páginas de ofertas, de casos y de RÜNARA mostraban el texto en portugués aunque la URL fuera /en-us o /es-es. El menú cambiaba de idioma, el contenido principal no. Nada se veía roto, por eso pasó desapercibido hasta una revisión archivo por archivo.
La analítica no registraba nada. El código cargaba Google Analytics inyectando el script de forma dinámica tras el consentimiento. La capa de datos mostraba los eventos correctos, pero ninguna petición llegaba realmente a Google. Lo resolvimos cambiando a la etiqueta estática en el HTML, con la configuración aún condicionada al consentimiento, el mismo patrón que ya funcionaba en otros dos sitios nuestros alojados en Lovable. También descubrimos que, al tratarse de una aplicación de página única, navegar entre páginas no generaba page_view, y ahora registramos cada cambio de ruta.
Los rastreadores de IA veían una página vacía. Este fue el más grave. El sitio se renderizaba por completo en el navegador: las 84 URLs del sitemap devolvían el mismo HTML vacío, y el contenido solo aparecía después de ejecutarse el JavaScript. Google renderiza JavaScript en una etapa posterior al rastreo (Google Search Central), pero un análisis de Vercel mostró que ninguno de los grandes rastreadores de IA, incluidos GPTBot y ClaudeBot, ejecuta JavaScript (Vercel, 2024). Si quiere que ChatGPT, Claude o Perplexity le citen, eso equivale a no tener sitio. La solución fue una etapa de prerenderizado en el build que genera HTML estático con contenido, título y datos estructurados para cada ruta.
El código local se quedó 23 commits atrás. Como Lovable y GitHub se sincronizan por la rama principal, los cambios hechos directamente en el editor de Lovable y los hechos en local divergieron. Conciliarlos exigió resolver conflictos archivo por archivo. Hoy la regla es simple: cada cambio nace en un único lugar, y quien va a empezar sincroniza antes.
Ninguno de estos problemas es exclusivo de Lovable. Son habituales en cualquier aplicación de página única hecha con prisa. La diferencia es que la velocidad de la herramienta le lleva antes hasta ellos y, a veces, le hace publicar antes de darse cuenta.
Qué haríamos distinto desde el primer día
Con lo que sabemos hoy, tres decisiones habrían llegado antes de la primera pantalla.
- Prerenderizado o renderizado en servidor desde el principio. Corregirlo después obligó a tocar el build, el enrutado y partes del código que accedían a recursos del navegador al cargar. Habría sido más barato nacer así.
- Una regla escrita sobre dónde se hacen los cambios. La divergencia de 23 commits exigió una conciliación archivo por archivo que un acuerdo de dos líneas habría evitado.
- Una prueba automática sencilla en el build que abra cada ruta en cada idioma y compruebe que el contenido principal está en el idioma correcto. Los errores de idioma se habrían detectado el primer día, no meses después.
Ninguna de estas decisiones depende de la herramienta elegida. Todas dependen de que alguien haga las preguntas correctas antes de pedir la primera pantalla.
Checklist antes de publicar un sitio hecho con IA
- Abra el código fuente de la página (no el inspector del navegador) y compruebe que el texto principal está en el HTML. Si no lo está, los rastreadores de IA no lo leerán.
- Cambie el idioma en la URL y lea el contenido, no solo el menú.
- Acepte las cookies y compruebe en el informe en tiempo real de GA4 que aparece la visita. Después rechácelas y confirme que no se envía nada.
- Navegue por tres páginas y compruebe que cada una registra una visualización.
- Pegue el enlace de cada página importante en LinkedIn o WhatsApp y revise título, descripción e imagen.
- Valide el sitemap: cada URL listada debe existir y servir contenido en el idioma declarado.
- Decida dónde se hacen los cambios, en el editor de Lovable o en el repositorio, y déjelo por escrito.
Para quién compensa
Compensa a quien sabe exactamente qué quiere construir, tiene a alguien capaz de leer el código generado y cuenta con un design system mínimamente definido que sirva de ancla. Sin claridad de alcance, cualquier herramienta produce el resultado equivocado más deprisa. Sin alguien técnico revisando, los problemas anteriores solo aparecen cuando el tráfico no llega.
El reparto que nos quedó es el mismo que recomendamos a los clientes: la herramienta genera, las personas deciden, verifican y responden por lo que se publica. Si está valorando este camino para el sitio o un producto de su empresa, vea los proyectos que hemos entregado y cómo trabajamos en apps y productos digitales.