Lovable y el SEO: qué corregir antes de publicar

Sí, una web hecha con Lovable puede indexarse y posicionar en Google. Lo que recibe un rastreador depende, eso sí, de la antigüedad de la app: desde el 13 de mayo de 2026, las apps nuevas se renderizan en el servidor. Las antiguas se construyen en el navegador, y Lovable solo envía una copia prerrenderizada a los rastreadores que ha verificado, como los de Google y Bing. El 17 de octubre de 2026 descargamos 19 sitios de Lovable en español, sin JavaScript y con él. El renderizado funciona; lo que falla son sobre todo ajustes que te tocan a ti: idioma de la página, sitemap, etiqueta canonical y dominio propio.

En resumen: qué recibe Google de un sitio de Lovable

• Apps creadas desde el 13 de mayo de 2026 (el 22 de junio de 2026 en los espacios Enterprise): funcionan con TanStack Start y renderizado en el servidor (SSR). Visitantes y rastreadores reciben la página completa.
• Apps más antiguas: funcionan con React y Vite. Lovable sirve una copia prerrenderizada solo a los rastreadores verificados: buscadores (Google, Bing), rastreadores de las búsquedas con IA (ChatGPT, Perplexity, Claude, Gemini), bots de vista previa de las redes sociales y, según su documentación, unas «herramientas SEO verificadas» que no nombra. El resto recibe una página casi vacía.
• Desde el 28 de julio de 2026, una app antigua puede pasar a TanStack Start dentro del propio proyecto.
• Lo básico sigue siendo cosa tuya: título y descripción de cada página, atributo lang, robots.txt, sitemap, etiqueta canonical y errores 404 de verdad.
• Dominio propio: Lovable redirige entre tus dominios con un 302, nunca con un 301, así que la canonical y el sitemap deben señalar tu dominio.

Si términos como rastreo, renderizado e indexación te suenan nuevos, empieza por nuestra guía qué es el SEO.

¿App nueva o antigua? Tres comprobaciones

1. El código fuente. Abre el código fuente de una página publicada (Ctrl+U en Chrome para Windows, Opción+Comando+U en Mac). Si ves tus textos, la página se renderiza en el servidor. Si apenas hay un <div id="root"></div> vacío y un script bajo /assets/, es la versión antigua.
2. Una dirección inventada. Abre las herramientas para desarrolladores (F12), pestaña Red (Network), y carga una dirección que no exista, por ejemplo /esta-pagina-no-existe. La primera línea debe mostrar 404. Las apps antiguas responden 200, aunque en pantalla salga una página de error.
3. El código del proyecto. En la pestaña Code del editor, el package.json de un proyecto con TanStack Start incluye @tanstack/react-start. También puedes preguntar a Lovable en el chat qué stack usa tu proyecto.

En nuestra prueba, la segunda comprobación separó siempre las dos familias: las 13 apps nuevas respondieron 404 a la dirección inventada y las 6 antiguas, 200.

Nuestra prueba: 19 sitios de Lovable en español, con y sin JavaScript

El 17 de octubre de 2026 tomamos del índice público de Common Crawl (rastreo de septiembre de 2026) las 20 direcciones lovable.app cuyo contenido se detecta como español y que más páginas tienen allí. Una sola petición por dirección: robots.txt, página de inicio sin JavaScript, la misma página en un navegador con JavaScript, una dirección inventada y /sitemap.xml. Descartamos un sitio que mezclaba varios idiomas. Quedan 19: 13 apps nuevas y 6 antiguas.

Tres límites. No somos un rastreador verificado: vimos lo que reciben las herramientas SEO y los bots pequeños, no la copia prerrenderizada que las apps antiguas envían a Google. Algunas direcciones lovable.app pueden ser borradores. Y la muestra no es aleatoria: las cifras valen para nuestra prueba, no para todos los sitios de Lovable.

Nuestras dos pruebas anteriores apuntaban en la misma dirección: 9 sitios lovable.app en inglés el 13 de octubre de 2026 y 43 sitios en alemán de Alemania, Austria y Suiza el 16 de octubre de 2026.

Apps nuevas: HTML completo y errores 404 reales

En 12 de las 13 apps nuevas, el título principal (H1) y el texto llegaban ya en el primer HTML, sin JavaScript; la mediana de las 13 fue de unos 3500 caracteres de texto y 33 enlaces en ese HTML. La decimotercera también mandaba su texto, pero no tenía ningún H1, ni siquiera con JavaScript. En otras dos, una parte del texto (entre una cuarta y una tercera parte) llegaba solo con JavaScript.

Las 13 respondieron a la dirección inventada con un 404 real. Así, todos los rastreadores reciben la misma página que tus visitantes, que es lo que prefiere Google: su guía sobre JavaScript dice que «sigue siendo una buena opción renderizar el contenido previamente o en el servidor», porque la web va más rápido y no todos los bots ejecutan JavaScript.

Eso no significa que una app nueva esté lista:

• 2 de las 13 no tenían robots.txt, aunque Lovable dice que crea uno con cada proyecto nuevo.
• 2 de las 13 no tenían sitemap.xml.
• 2 de las 13 no tenían etiqueta canonical en el HTML, y otras 4 solo indicaban la ruta relativa /.
• 7 de las 13 declaraban el inglés como idioma de la página.

Error 404 real, robots.txt y sitemap a la vez: 11 de los 19 sitios, todos apps nuevas. En la prueba alemana fueron 11 de 43, y en la inglesa, ninguno de 9.

Apps antiguas: una página vacía para los rastreadores no verificados

Sin JavaScript, las 6 apps antiguas no enviaban ni el texto de la página ni enlaces a sus propias páginas: solo el elemento root vacío y scripts. En cinco no había ningún texto visible; en la sexta, solo las palabras «Edit with» del distintivo de Lovable. A eso se suman dos problemas que describe la propia Google:

• Todas las direcciones responden 200. Las 6 respondieron 200 a nuestra dirección inventada, con la misma página vacía y el título de la portada. Google advierte de estos errores soft 404 en las aplicaciones de una sola página y propone dos salidas: una redirección con JavaScript a una dirección que responda 404, o una etiqueta noindex añadida con JavaScript en la página de error.
• Un noindex en el HTML original puede hacer que Google no ejecute el JavaScript; quitarlo después con JavaScript puede no servir.

La copia prerrenderizada que reciben los rastreadores verificados es lo que Google llama renderizado dinámico. Lo describe como «una solución provisional y no una solución a largo plazo» y recomienda en su lugar el renderizado en el servidor, el renderizado estático o la hidratación. No es encubrimiento (cloaking) mientras el contenido sea similar. Lovable aclara que el contenido que carga más tarde puede faltar en la copia.

Para ver lo que recibe Google de verdad, abre la herramienta de inspección de URLs de Search Console, haz clic en «Probar URL publicada» y luego en «Ver página probada», con la captura de pantalla y el HTML. Lovable remite a esa misma herramienta.

Pasar a TanStack Start: cuándo y cómo

Si te importan las visitas desde Google, Bing o las búsquedas con IA, te recomendamos la migración: después, todos reciben la misma página completa y con errores 404 reales. Hay tres formas de lanzarla, siempre con confirmación: escribir / en el chat y elegir Migrate to TanStack Start; hacer clic en Migrate en Project settings → General → Project actions; o pedírselo a Lovable, que muestra una tarjeta con el botón Start migration.

Según la documentación de Lovable (con la interfaz en inglés):

• La mayoría de las migraciones cuestan entre 10 y 35 créditos, según el tamaño del proyecto.
• La web publicada no cambia hasta que vuelvas a publicar, y puedes deshacer la migración desde el historial de versiones.
• Títulos, descripciones, etiquetas para redes sociales y scripts de analítica se trasladan a la nueva plantilla.
• Algunas bibliotecas solo funcionan en el navegador y pueden romper el renderizado en el servidor: prueba cada página antes de publicar.

No es obligatoria: las apps antiguas siguen prerrenderizándose para los rastreadores verificados y, según Lovable, un proyecto alojado en Lovable no necesita un servicio externo de prerrenderizado. Ese prerrenderizado forma parte del alojamiento: si alojas en otro sitio la exportación de una app antigua, comprueba allí con «Probar URL publicada» qué recibe Google.

Idioma, título y descripción: los valores por defecto que hay que corregir

El atributo lang, al principio del HTML, indica el idioma de la página, por ejemplo <html lang="es">. En nuestra prueba, 8 de los 19 sitios en español declaraban lang="en" (7 apps nuevas y una antigua), y JavaScript no lo corregía en ninguno. Lo mismo pasaba en 20 de 43 sitios en alemán y en 6 de 18 sitios en francés (nuestra prueba francesa, también del 17 de octubre).

Google no lo tiene en cuenta: determina el idioma por el contenido visible y no usa el atributo lang. Aun así, conviene corregirlo, porque los lectores de pantalla lo usan para elegir la pronunciación. La revisión de Lovable avisa si falta el atributo; su documentación no dice si detecta un en en un texto en español. Pide a Lovable que ponga lang="es" y compruébalo en el código fuente. es basta tanto para España como para Latinoamérica; en la prueba, un sitio usaba es-ES y otro es-PY. Los códigos de país sirven sobre todo en las etiquetas hreflang (lo explicamos en nuestra guía de SEO internacional).

Lovable genera el título y la descripción de cada página al construir la app. La imagen para compartir se elige al servir la página: la que le hayas pedido o la última captura de pantalla de la app. Los cambios se piden en el chat, consumen créditos y solo llegan a la web en la siguiente publicación. Para revisarlos: menú ⋮ del diálogo de publicación y luego Social & search appearance.

En nuestra muestra ningún título seguía siendo «Lovable App», algo que sí vimos en 4 apps antiguas de la prueba alemana, pero un sitio usaba aún la imagen para compartir de Lovable y 2 mantenían a Lovable como autor en los metadatos. El distintivo «Edit with Lovable» se veía en 8 de los 19 sitios; desde el plan Pro puedes ocultarlo en Project settings → General → Publishing → Hide Lovable badge. Sobre la longitud del título, consulta nuestra guía del title SEO.

Sitios en varios idiomas: 2 de los 19 tenían etiquetas hreflang. Las reglas de Google también valen para Lovable: una URL por idioma, sin redirecciones automáticas según el idioma del navegador, y cada versión se cita a sí misma y a todas las demás. Nuestra guía de la etiqueta hreflang explica cómo hacerlo, con códigos como es-ES, es-MX o es-AR si te diriges a cada país por separado.

robots.txt y sitemap: qué crea Lovable y qué falta

Desde que reescribió su página de SEO en octubre de 2026, Lovable dice que crea un robots.txt con cada proyecto nuevo, pero no siempre un sitemap, y que los metadatos iniciales son genéricos. En nuestra prueba:

• robots.txt: 17 de 19 sitios, incluidas las 6 apps antiguas; 14 indicaban un sitemap con una línea Sitemap:.
• sitemap.xml: 16 de 19 sitios.
• Sitemaps con errores: uno solo tenía rutas relativas, sin dominio, y otro listaba las direcciones de otro proyecto en lovable.app.

Google pide URLs absolutas y completas en el sitemap, y la revisión de Lovable también avisa de las URLs relativas y de las direcciones en otro host. En la línea Sitemap:, indica el sitemap de tu dominio definitivo.

Dominio propio: el 302, la canonical y la dirección lovable.app

Los dominios propios requieren un plan de pago. Eliges un dominio principal y los demás dominios conectados redirigen a él con un 302, una redirección temporal. Lovable no admite redirecciones 301 entre los dominios de un proyecto, para que puedas cambiar de dominio principal más adelante. La dirección lovable.app del proyecto no se puede eliminar.

Google sigue un 302, pero no lo toma como una señal de que el destino es la URL canónica: la dirección antigua puede seguir en los resultados. Por eso las demás señales pesan más.

En nuestra muestra, ninguna dirección lovable.app redirigía a un dominio propio. Sin embargo, en 5 sitios la dirección lovable.app respondía con normalidad, sin redirección, aunque la canonical o el sitemap señalaban un dominio propio. En uno de ellos, además, la canonical apuntaba al dominio propio y el sitemap a lovable.app: dos señales que se contradicen. Según Lovable, si no hay dominio principal, todos los dominios conectados sirven el proyecto por igual. En la prueba alemana, en cambio, 2 de los 8 sitios con dominio propio sí redirigían, pero su canonical y su sitemap seguían señalando la dirección lovable.app.

La configuración correcta:

• define tu dominio como principal en Project → Settings → Domains;
• pon en cada página una canonical absoluta que apunte a sí misma, en ese dominio;
• incluye en el sitemap solo direcciones de ese dominio;
• verifica el dominio en Search Console y envía allí el sitemap; si cambias de dominio, Lovable pide verificarlo de nuevo.

Nuestra guía de la etiqueta canonical explica las reglas básicas, y la de migración web, las redirecciones 301, 302, 307 y 308.

Páginas legales y cookies: dos puntos que revisar

Esto no es asesoramiento jurídico: solo describimos lo que observamos.

Páginas legales. En una app antigua, cada dirección devuelve una página vacía, también el aviso legal y la política de privacidad; el texto solo llega con JavaScript o en la copia prerrenderizada. En nuestra prueba alemana, ninguna de las 8 páginas legales de apps antiguas que abrimos tenía su texto en el HTML. Enlaza estas páginas desde todas las demás con enlaces de verdad y no las bloquees en el robots.txt.

Cookies. La analítica integrada de Lovable (el script /~flock.js) funcionaba en los 19 sitios, y había una cookie session-id desde la primera carga, sin ningún clic; el alojamiento ponía además una cookie __dpl. En la prueba alemana vimos session-id en 41 de 43 sitios. Según Lovable, su analítica mide el tráfico, no a las personas, y no crea perfiles; las páginas de su documentación que leímos no mencionan cookies. Se desactiva en Project settings → General → Publishing → Visitor analytics. Además, 17 de los 19 sitios cargaban fuentes desde los servidores de Google en la primera visita, y solo 4 mostraban un aviso de cookies. Si necesitas consentimiento es una cuestión jurídica: consúltalo antes de publicar.

La revisión SEO de Lovable y Search Console

Desde octubre de 2026, las herramientas SEO están en More → Analytics, pestaña SEO & AI. Run SEO scan lanza la revisión, incluida en todos los planes; solo Try to fix y Try to fix all consumen créditos. Según la documentación consultada el 17 de octubre de 2026, revisa el código (viewport, atributo lang, metadatos, Open Graph, datos estructurados, encabezados, textos alternativos), la vista previa (portada, robots.txt, sitemap.xml) y, con la web publicada, el noindex y la versión en Markdown para los rastreadores de IA. No valora la calidad del contenido, la intención de búsqueda ni la velocidad: para esto último, Lovable remite a PageSpeed Insights.

Algunas cosas ya funcionaban bien en la prueba: las 589 imágenes de las portadas tenían todas atributo alt, 18 de las 19 portadas tenían exactamente un H1 tras cargar, y 14 sitios tenían datos estructurados.

Search Console: Lovable verifica tu web con la etiqueta HTML de Google y puede enviar el sitemap desde el chat. Publica antes, porque Google lee el sitemap de la web en línea. Los proyectos sin publicar o con acceso restringido nunca aparecen en los resultados. Desde el 14 de octubre de 2026, Lovable también se conecta con Bing Webmaster Tools, para ver clics y rastreo y enviar direcciones y sitemaps a Bing.

Lista de comprobación antes de publicar

1. Identifica el stack: código fuente y dirección inventada.
2. Migra una app antigua a TanStack Start, prueba cada página y publica.
3. Idioma: lang="es" en el elemento <html>, comprobado en el código fuente.
4. Título y descripción propios en cada página, y una imagen para compartir tuya.
5. robots.txt con una línea Sitemap: de tu dominio definitivo.
6. sitemap.xml con direcciones absolutas de ese dominio.
7. Canonical absoluta, una por página, en ese dominio.
8. Prueba del 404: una dirección inventada debe responder 404.
9. Enlaces como <a href> de verdad, también en el menú.
10. Páginas legales enlazadas desde todas las páginas, con su texto en el HTML.
11. Cookies y servicios externos revisados en la primera carga y, después, con un profesional del derecho.
12. Search Console: verificación, sitemap y «Probar URL publicada» en las páginas importantes.
13. Al final, la revisión SEO de Lovable: corrige, publica y vuelve a escanear.