¿Por qué mi sitio de Lovable no aparece en Google?
Si el sitio está publicado en Lovable, Google ya recibe HTML renderizado. Lo que suele faltar es lo básico: dirección pública, dominio propio, título y descripción por página, sitemap válido y Search Console. Si la app salió de Lovable como sitio estático en React, la página llega vacía sin JavaScript y necesita prerenderizado.
Recomendación de Heartscale: antes de reescribir textos, conecte Search Console y verifique con la Inspección de URLs que el HTML que recibe Google incluya el título y el texto de la página. Si el sitio salió de Lovable o el texto no aparece en ese HTML, pida una revisión del renderizado antes de invertir en contenido.
Muchas guías sobre el tema son anteriores a mayo de 2026, cuando Lovable cambió la forma de entregar las páginas. Esta guía sigue la documentación actual de Lovable (SEO y SEO and AI search) y la de Google Search Central.
Paso 1: verifique que la dirección pueda aparecer en la búsqueda
Según Lovable, solo las apps publicadas y públicas pueden aparecer en los resultados. Tres casos nunca aparecen:
- un proyecto no publicado;
- un proyecto con acceso al sitio restringido;
- una URL de marca del workspace, con el formato
https://{app}.{workspace}.lovable.app.
Lovable recomienda un dominio propio para construir presencia en la búsqueda. Después de conectar el dominio, ejecute de nuevo la revisión de SEO y verifique el dominio en Search Console (pasos 5 y 6).
Ajuste también la expectativa. Lovable indica que no garantiza posiciones y que la indexación puede tardar días o más.
Paso 2: averigüe si la app es React + Vite o TanStack Start
La forma en que Lovable entrega la página depende de la fecha de creación del proyecto:
| Stack | Proyectos | Qué recibe el rastreador |
|---|---|---|
| TanStack Start | creados desde el 13/05/2026 (22/06/2026 en Enterprise) | HTML completo, renderizado en el servidor, para cualquier visitante |
| React + Vite | creados antes | HTML prerenderizado solo para rastreadores verificados; los demás reciben la app de una sola página |
Los rastreadores verificados, en la lista de Lovable, incluyen buscadores, rastreadores de búsqueda con IA (ChatGPT, Perplexity, Claude, Gemini), bots de vista previa de enlaces y herramientas de SEO verificadas. React + Vite tiene un límite: la documentación advierte que el contenido que carga tarde puede faltar en el HTML prerenderizado.
Para conocer su stack, pregunte en el chat del proyecto: “What stack is this project on?”. Si es React + Vite, Lovable ofrece la migración (Upgrade to TanStack Start):
- en el chat, escriba
/y elija Migrate to TanStack Start; o - en Project settings → General → Project actions, haga clic en Migrate.
La mayoría de las migraciones cuesta de 10 a 35 créditos. El sitio publicado solo cambia cuando usted publica de nuevo, y se puede volver atrás con el historial de versiones. Las bibliotecas que solo corren en el navegador pueden romper el renderizado en el servidor sin que las verificaciones lo detecten. Pruebe cada página antes de publicar.
Paso 3: título y descripción propios en cada página
Una app de una sola página suele nacer con el mismo título en todas las rutas. Google pide títulos y descripciones únicos y descriptivos por página, y acepta que JavaScript los defina (JavaScript SEO basics).
La revisión de Lovable señala títulos genéricos o repetidos, texto de ejemplo, descripciones débiles y canonical incorrecto. También pide etiquetas Open Graph propias en cada ruta, porque las redes sociales leen esas etiquetas del HTML. Para ver cómo aparece la página, abra Social & search appearance en el menú ⋮ del diálogo de publicación.
Dos reglas de Google que valen para cualquier stack:
- los enlaces entre páginas tienen que ser
<a href="...">. Google no descubre enlaces que existen solo como clic en un botón; - las rutas deben usar la History API (
/precios), no fragmentos (/#/precios).
Paso 4: sitemap.xml y robots.txt
Lovable crea un robots.txt en cada proyecto nuevo, pero no siempre crea el sitemap. Las reglas de Google para el sitemap (Build and submit a sitemap):
- URLs absolutas, con
https://y el dominio. La revisión de Lovable también señala URLs relativas y URLs de otro dominio; - hasta 50.000 URLs o 50 MB por archivo, en UTF-8, en la raíz del sitio;
- solo las URLs canónicas que usted quiere en los resultados;
<lastmod>solo si es exacto. Google ignora<priority>y<changefreq>.
Un ejemplo mínimo:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https://sudominio.com/</loc></url>
<url><loc>https://sudominio.com/precios</loc></url>
</urlset>
Y la línea al final del robots.txt:
Sitemap: https://sudominio.com/sitemap.xml
Paso 5: ejecute la revisión de SEO de Lovable
En la barra del proyecto, abra More → Analytics y la pestaña SEO & AI. Haga clic en Run SEO scan. Cada hallazgo tiene Try to fix, y Try to fix all los trata todos. Después, Scan again.
La revisión cubre robots, sitemap, títulos, descripciones, canonical, Open Graph y datos estructurados. No mide velocidad, porque ya no ejecuta Lighthouse, y no evalúa la calidad del contenido, la intención de búsqueda ni los enlaces de otros sitios. Para la velocidad, use PageSpeed Insights.
Paso 6: conecte Search Console
En la misma pestaña SEO & AI, use la tarjeta Google searches. Lovable verifica el sitio con una etiqueta en el HTML, sin subir archivos ni tocar el DNS, y envía el sitemap. Publique los cambios antes, porque Google lee el sitemap del sitio en vivo. Si cambia de dominio, verifique de nuevo.
Con Search Console conectado, use la Inspección de URLs en una página importante:
- Pegue la URL y haga clic en Test live URL.
- Abra View tested page y revise la captura y el HTML que recibió Google. Si el texto de la página no está, el problema es de renderizado.
- Si todo está bien, haga clic en Request indexing.
Hay un límite diario de inspecciones y de solicitudes de indexación por propiedad. Úselas en las páginas que importan.
Paso 7: datos estructurados
Google recomienda JSON-LD y ofrece la Prueba de resultados enriquecidos para validarlo (Introduction to structured data). Un marcado correcto hace que la página sea elegible para un resultado enriquecido, sin garantía de que aparezca.
La revisión de Lovable verifica que los datos se puedan leer, que coincidan con lo que muestra la página y que estén completos. No trata como problema la falta de WebSite, Organization o FAQPage. Marque lo que la página tiene: un producto con precio, un artículo, preguntas visibles.
¿Y las respuestas de IA, como ChatGPT, Perplexity y Gemini?
Google indica que no hay requisitos adicionales para aparecer en AI Overviews y en AI Mode (AI features and your website). La página tiene que estar indexada y poder mostrar un fragmento. Google también indica que no hace falta crear archivos de texto para IA ni marcado especial.
En Lovable, cualquier cliente que pide Markdown recibe la página en Markdown, en los dos stacks. Así leen el sitio los asistentes de IA.
llms.txt es una propuesta de Jeremy Howard: un archivo en la raíz con un título # y enlaces a las páginas principales. Solo el título es obligatorio. Lovable no exige el archivo, no señala su ausencia y mantiene el que ya existe. Sirve como complemento barato. No reemplaza los pasos 1 a 6.
Si la app salió de Lovable
La documentación de Lovable describe el prerenderizado para direcciones publicadas en Lovable. La guía de alojamiento fuera de Lovable no lo menciona. Entonces pruebe en el servidor nuevo:
curl -s https://sudominio.com/precios | grep -i -E "<title>|<h1"
Si el título es el mismo de todas las páginas y no aparece el <h1>, el rastreador recibe una página vacía hasta que corre el JavaScript. Google renderiza JavaScript en una cola que puede tardar, y no todos los bots ejecutan JavaScript. Por eso Google todavía recomienda el renderizado en el servidor o el prerenderizado.
En nuestras revisiones, ejecutamos esta prueba en cada URL del sitemap y comparamos el título, el <h1> y el canonical con lo que la página muestra en el navegador. Cada ruta que difiere entra en la lista de correcciones.
Los caminos, del más simple al más completo:
- React + Vite estático: generar el HTML de cada ruta en el build (SSG o prerender), con título y descripción propios;
- TanStack Start: correr el servidor Node, que ya entrega el HTML listo. Un host que solo recibe archivos estáticos no ejecuta esa parte.
Cuide también el 404. Una SPA suele responder 200 a cualquier ruta, y Google puede tratarlo como “soft 404”. La salida que indica Google es redirigir a una URL que responda 404 o poner noindex en la página de error. Si todavía va a salir de Lovable, la guía Cómo salir de Lovable muestra el orden de la migración.
¿Hacerlo usted mismo o contratar?
Casi toda esta guía se puede seguir sin ayuda. La tabla muestra cuándo conviene llamar a un equipo.
| Situación | Camino |
|---|---|
| Sitio publicado en Lovable, con dominio propio y pocas páginas | Siga los pasos 1 a 7 y revise Search Console |
| App en React + Vite con login, pagos o bibliotecas que solo corren en el navegador, antes de migrar a TanStack Start | Pida una revisión antes de publicar la migración |
| Sitio fuera de Lovable, con páginas que llegan vacías sin JavaScript | Llame a un equipo para generar el HTML de cada ruta o correr el servidor |
| Las páginas importantes siguen fuera del índice y nadie del equipo lee el HTML que recibe Google | Solicite el diagnóstico de Heartscale |
Solicite un diagnóstico de Heartscale
Nuestro equipo revisa lo que Google y los rastreadores de IA reciben de cada página de su sitio, con y sin JavaScript. Corregimos títulos por ruta, sitemap, robots, datos estructurados y Search Console, y prerenderizamos las páginas cuando el sitio está fuera de Lovable. Vea el servicio de SEO para apps hechas con IA. No prometemos posiciones en Google.
El diagnóstico, a precio de lanzamiento, cuesta US$ 19 (antes US$ 79) y se descuenta si contrata la corrección. Solo trabajamos en apps de quien demuestra ser su dueño.