Una web hecha con Lovable o v0 puede posicionar en Google, pero solo si el HTML que recibe un buscador ya trae el texto, los títulos y los enlaces de cada página. El problema aparece cuando la web es una aplicación React que se «arma» en el navegador con JavaScript: quien entra con Chrome ve todo bien, pero un robot que no ejecuta JavaScript recibe una página casi vacía. Google suele ejecutarlo, aunque con demoras; la mayoría de rastreadores de IA, según un análisis de Vercel, no lo hacen.
La buena noticia es que el problema se puede comprobar en cinco minutos y tiene solución. Lovable cambió su plantilla en 2026 hacia el renderizado en servidor, y v0 trabaja sobre Next.js, que también lo permite. En esta guía verás cómo saber si tu web tiene el problema, qué hacer según la herramienta con que la hiciste y cuándo conviene pasar a WordPress u otra plataforma.
Actualizado: octubre de 2026
Lo esencial
- El riesgo no es «usar IA para hacer la web», sino entregar el contenido solo con JavaScript del lado del cliente (renderizado en el navegador).
- Google procesa JavaScript en tres fases (rastreo, renderizado e indexación) y recomienda igual renderizar en servidor o de forma previa.
- Según Vercel (diciembre de 2024), los rastreadores de OpenAI, Anthropic, Perplexity y Meta no ejecutaban JavaScript. Si tu texto depende de él, esas IA no lo leen.
- Lovable usa por defecto TanStack Start con renderizado en servidor en proyectos nuevos desde el 13 de mayo de 2026. Los proyectos antiguos en React + Vite necesitan una actualización.
- La prueba más simple: abre tu web, presiona Ctrl+U y busca en el código el texto de tu página. Si no está, tienes el problema.
Por qué una web hecha con IA puede ser invisible para Google
Lovable, v0, Bolt y herramientas parecidas generan código moderno, casi siempre con React. React se puede usar de dos maneras muy distintas:
- Renderizado en el cliente (CSR): el servidor envía un HTML mínimo, con un contenedor vacío y un archivo JavaScript grande. El navegador descarga ese archivo, lo ejecuta y recién entonces aparecen los textos, imágenes y botones.
- Renderizado en el servidor (SSR) o previo (prerender o SSG): el servidor envía la página ya armada, con el texto en el HTML. El JavaScript se usa después para las partes interactivas.
Para una persona con un celular moderno y buena señal, la diferencia casi no se nota. Para un robot sí. Si el robot solo lee el HTML inicial, en el primer caso encuentra algo así como «Cargando…» y un título genérico repetido en todas las páginas.
Durante buena parte de 2025, muchas webs hechas con Lovable eran aplicaciones de una sola página (SPA) con React y Vite, con renderizado en el cliente. Por eso se volvió común ver negocios con una web bonita que, meses después, seguía sin aparecer en Google ni en las respuestas de ChatGPT.
Qué hace Google con el JavaScript (y por qué no es suficiente)
Google sí ejecuta JavaScript. Su documentación sobre conceptos básicos de JavaScript para SEO explica que procesa estas páginas en tres fases: rastreo, renderizado e indexación. Las páginas pasan a una cola de renderizado, donde normalmente esperan unos segundos, pero a veces más, según los recursos de Google.
En la práctica, esto trae tres riesgos:
- Demoras e inconsistencias. Si el JavaScript falla, tarda demasiado o depende de una llamada a una API que se cae, Google indexa la versión vacía.
- Enlaces que no se descubren. Google solo sigue enlaces que son etiquetas
<a>con atributohref. Un botón que navega con un evento «onClick» no cuenta como enlace. - Metadatos repetidos. Si todas las rutas comparten el mismo
index.html, todas pueden tener el mismo título y la misma descripción, salvo que el proyecto los cambie por página.
La propia Google recomienda en esa documentación seguir usando renderizado en el servidor o previo, porque hace la web más rápida para usuarios y rastreadores, y porque no todos los robots ejecutan JavaScript. Si alguna vez revisaste el caso de JavaScript y SEO en Elementor, el principio es el mismo, solo que en una SPA el problema es mucho más grande: no es un bloque, es toda la página.
El problema más grande hoy: los rastreadores de IA
Aquí está la parte que casi nadie le explica al dueño de un negocio. En un análisis publicado el 17 de diciembre de 2024, Vercel revisó el tráfico de rastreadores de IA en su red y concluyó que ninguno de los principales ejecutaba JavaScript en ese momento. GPTBot, OAI-SearchBot y ChatGPT-User (OpenAI), ClaudeBot (Anthropic), PerplexityBot y el rastreador de Meta descargaban archivos JavaScript, pero no los ejecutaban. Las excepciones eran Gemini, que usa la infraestructura de Googlebot, y Applebot.
Los rastreadores cambian y es posible que alguno haya mejorado desde entonces, pero no hay anuncios oficiales claros de que todos lo hagan. La consecuencia práctica es directa: si tu web depende del JavaScript para mostrar el texto, es muy probable que ChatGPT o Perplexity no puedan leer tus servicios, precios ni preguntas frecuentes, y por tanto no te citen.
Esto importa en el Perú. Según la encuesta ERESTEL 2025 de Osiptel, citada por DPL News, el 16.3 % de los peruanos usa herramientas de IA y el 87 % de ellos usa ChatGPT. Es un canal pequeño todavía, pero crece, y una web que no se deja leer queda fuera desde el inicio. Si quieres verificar qué bots visitan tu web, puedes detectar bots de IA en los logs del servidor.
Cómo saber en cinco minutos si tu web tiene el problema
No necesitas ser programador. Haz estas pruebas en orden:
Prueba 1: ver el código fuente
Abre tu web en Chrome de computadora, presiona Ctrl+U (o clic derecho, «Ver código fuente de la página») y busca con Ctrl+F una frase que se vea en pantalla, por ejemplo el nombre de tu servicio principal. Si la frase aparece en el código, vas bien. Si solo ves un <div id="root"></div> y referencias a archivos .js, el contenido se arma en el navegador.
Prueba 2: desactivar JavaScript
En Chrome, abre las herramientas para desarrolladores (F12), presiona Ctrl+Shift+P, escribe «Disable JavaScript» y recarga. Lo que veas es, aproximadamente, lo que ve un rastreador de IA.
Prueba 3: inspección de URL en Search Console
En Search Console, pega la URL en la barra superior y usa «Probar URL publicada». Luego abre «Ver página probada» y revisa el HTML y la captura. Así ves lo que Google logró renderizar. Si es tu primera vez en la herramienta, revisa la guía de Search Console para MYPE.
Prueba 4: compartir el enlace por WhatsApp
Envía la URL de una página interna a un contacto. Si la vista previa muestra el título genérico del sitio o no muestra imagen, los metadatos no se están entregando por página.
Lovable: qué cambió en 2026 y qué hacer con tu proyecto
Lovable reconoció el problema y cambió su plantilla. Según su documentación oficial sobre la actualización a TanStack Start (consultada el 25 de octubre de 2026):
- Los proyectos nuevos usan por defecto TanStack Start, con renderizado en servidor, desde el 13 de mayo de 2026 (y los nuevos proyectos Enterprise desde el 22 de junio de 2026).
- Los proyectos antiguos en React + Vite no se cambian solos. Siguen funcionando, y Lovable genera una versión prerenderizada solo para buscadores verificados y bots de vista previa de redes sociales. Otros robots ven muy poco contenido.
- La actualización convierte el proyecto a TanStack Start. Según Lovable, se cobra como uso normal y la mayoría cuesta entre 10 y 35 créditos según el tamaño. Tu sitio publicado no cambia hasta que vuelvas a publicar, y puedes revertir desde el historial de versiones.
Qué hacer en la práctica:
- Si tu proyecto es anterior a mayo de 2026, haz la prueba del código fuente. Si sale vacío, planifica la actualización.
- Antes de actualizar, anota tus URLs, títulos y descripciones actuales. Después de publicar, compara página por página.
- Prueba especialmente formularios, mapas y componentes que solo funcionan en el navegador. La propia Lovable advierte que algunas librerías pueden romper el renderizado en servidor.
- Revisa que exista un sitemap.xml y envíalo a Search Console.
v0 y Next.js: más margen, pero no automático
v0 es la herramienta de Vercel para generar interfaces y aplicaciones con IA. Trabaja sobre React y normalmente genera proyectos Next.js listos para desplegar en Vercel. Next.js permite renderizar en servidor o generar páginas estáticas, así que el punto de partida es mejor que una SPA pura.
Pero «permite» no significa «siempre lo hace». Hay dos situaciones frecuentes en las que el problema vuelve:
- Componentes marcados como cliente: si la página entera está marcada con
"use client"y los datos se cargan después con un fetch en el navegador, el HTML inicial puede salir sin el contenido principal. - Metadatos sin configurar: Next.js permite definir título y descripción por página, pero si no se hizo, todas las rutas comparten los mismos.
La prueba del código fuente sirve igual. Si tu web hecha con v0 muestra el texto en Ctrl+U y cada página tiene su título, el renderizado no es tu problema y puedes concentrarte en el contenido y los enlaces.
Comparación: Lovable, v0 y WordPress para SEO
| Aspecto | Lovable (React + Vite, antes de mayo 2026) | Lovable (TanStack Start) | v0 (Next.js) | WordPress |
|---|---|---|---|---|
| HTML inicial con contenido | No (prerender solo para bots verificados) | Sí | Depende de cómo se generó | Sí |
| Legible para rastreadores de IA | Limitado | Sí | Sí, si renderiza en servidor | Sí |
| Títulos y descripciones por página | Requiere configuración | Sí, si se configuran | Sí, si se configuran | Sí, con plugin SEO |
| Sitemap y datos estructurados | Manual o pidiéndolo a la IA | Manual o pidiéndolo a la IA | Manual en el código | Plugins (Rank Math, Yoast) |
| Quién edita un texto | Pidiéndolo en el chat (consume créditos) | Pidiéndolo en el chat | Pidiéndolo en el chat o en código | Cualquier persona desde el panel |
| Blog con muchos artículos | Poco práctico | Posible, pero sin panel editorial | Posible con desarrollo | Nativo |
La fila que más pesa para una MYPE suele ser la de «quién edita un texto». Si cada cambio de precio o cada artículo nuevo pasa por pedirle algo a la IA y revisar el código, la web tiende a quedarse desactualizada. Para más contexto sobre plataformas, revisa la comparación de WordPress, Wix, Shopify o Tiendanube en el Perú.
Lista de control SEO para webs hechas con IA
Una vez resuelto el renderizado, revisa estos puntos. Muchos se pueden pedir directamente en el chat de la herramienta:
- Una URL por página real (/servicios/, /contacto/), sin almohadillas tipo
/#/servicios. - Título y meta descripción únicos en cada página, visibles en el código fuente.
- Un solo H1 por página, con la búsqueda principal.
- Enlaces internos con etiqueta <a href>, no botones con eventos.
- Sitemap.xml y robots.txt accesibles en la raíz. Si tienes dudas sobre qué incluir, mira qué incluir y excluir en un sitemap XML.
- Etiqueta canónica en cada página, apuntando a sí misma.
- Datos estructurados en JSON-LD (Organization o LocalBusiness) dentro del HTML inicial.
- Imágenes con texto alternativo y tamaño razonable.
- Dominio propio, no el subdominio gratuito de la herramienta.
- Página de error 404 real: en muchas SPA, una URL inexistente responde con código 200 y la página de inicio, lo que confunde a Google.
Si después de corregir todo Google sigue sin indexar algunas páginas, el diagnóstico se parece al de cualquier sitio: revisa qué significa «Rastreada: actualmente sin indexar».
Cuándo conviene migrar a WordPress (y cuándo no)
No siempre hace falta migrar. Si tu web es una landing de una sola página para campañas pagadas, el SEO importa poco y el renderizado en el cliente no es grave. Lo mismo si es una herramienta interna o un panel con usuario y contraseña: esas páginas no deben indexarse de todos modos.
Migrar tiene sentido cuando se cumplen dos o más de estas condiciones:
- Quieres posicionar varios servicios o publicar un blog de forma constante.
- Varias personas del equipo necesitan editar textos sin depender de un desarrollador ni de créditos.
- Necesitas una tienda con pasarela peruana (Izipay, Niubiz, Culqi, Mercado Pago) y facturación electrónica.
- Actualizar el proyecto a renderizado en servidor rompe funciones que no sabes reparar.
Si decides migrar, el riesgo principal es perder las pocas posiciones que ya tengas por cambiar URLs sin redirecciones. Sigue el checklist de migración sin perder SEO. Como referencia de costo, los planes de diseño web en WordPress de KOM empiezan en S/ 1,250 + IGV (Plan Profesional), según los precios publicados en kom.pe (consultados en octubre de 2026).
Ejemplo ilustrativo: una clínica dental con web hecha en Lovable
Este es un ejemplo ilustrativo, no un caso real. Una clínica dental de Chiclayo encargó en 2025 una web en Lovable con cinco páginas: inicio, ortodoncia, implantes, blanqueamiento y contacto. Seis meses después, en Search Console solo aparece indexada la página de inicio y las búsquedas por «implantes dentales Chiclayo» no muestran la web.
El diagnóstico sigue los pasos de esta guía:
- Ctrl+U en la página de implantes: el código no contiene la palabra «implantes», solo el contenedor vacío.
- La vista previa en WhatsApp de esa URL muestra el título de la página de inicio.
- La inspección en Search Console muestra que Google sí renderiza la página, pero la considera duplicada de la de inicio porque comparte título, descripción y canónica.
Las opciones serían actualizar a TanStack Start y luego configurar título, descripción y canónica por página, o migrar a WordPress si la clínica quiere publicar artículos sobre tratamientos con frecuencia. En ambos casos, después habría que solicitar la indexación de cada URL y vigilar Search Console durante varias semanas.
Si tu web hecha con IA no aparece en Google y no sabes si el problema es el renderizado, el contenido o ambos, una revisión técnica lo aclara rápido. Puedes ver cómo trabaja el servicio de consultoría SEO de KOM y pedir una evaluación de tu caso.
Preguntas frecuentes
¿Lovable es malo para SEO?
No necesariamente. El problema histórico era que generaba aplicaciones React con renderizado en el navegador, que los buscadores y la IA leen mal. Desde el 13 de mayo de 2026, los proyectos nuevos usan TanStack Start con renderizado en servidor, lo que corrige la base técnica. Aun así, el SEO depende de lo de siempre: contenido útil, títulos únicos, enlaces internos y una estructura clara de páginas.
¿Puedo seguir usando el subdominio gratuito de la herramienta?
Para pruebas sí, pero para un negocio conviene un dominio propio, como .pe o .com. Con el subdominio gratuito no controlas del todo la propiedad de la dirección y, si algún día cambias de plataforma, pierdes lo ganado en Google porque no puedes redirigir. Un dominio propio te permite migrar más adelante sin empezar de cero.
¿Agregar un sitemap soluciona el problema del JavaScript?
No. El sitemap ayuda a que Google descubra tus URLs, pero no cambia lo que encuentra al visitarlas. Si cada página llega vacía y depende del JavaScript, Google puede tardar en renderizarla o indexarla mal, y los rastreadores de IA que no ejecutan JavaScript seguirán sin leer el texto. Primero se corrige el renderizado; el sitemap viene después.
¿Bolt, Base44 u otras herramientas tienen el mismo problema?
Puede pasar con cualquier herramienta que genere aplicaciones React con renderizado en el cliente. Cada plataforma cambia sus plantillas con frecuencia, así que lo más seguro es no depender de lo que diga el anuncio y hacer la prueba tú mismo: ver el código fuente con Ctrl+U y buscar el texto de la página. Si el texto está en el HTML, el renderizado no es el problema.
¿Cuánto tarda Google en indexar la web después de corregir el renderizado?
Varía. Después de publicar la versión corregida, solicita la indexación de las páginas principales en Search Console y envía el sitemap. Algunas páginas pueden reindexarse en días y otras tardar semanas, sobre todo si el dominio es nuevo o tiene pocos enlaces externos. Google recomienda esperar unas semanas antes de evaluar el efecto de cualquier cambio.
