Reconstruir nuestra web con Claude Design en vez de Lovable
Un relato honesto de mover la web de nuestro estudio fuera de Lovable: qué mejoró, qué aspecto tienen de verdad los archivos entregados, y el único punto en el que Lovable aún gana. Escrito para quien le importan los detalles técnicos.
Hemos pasado por unos cuantos stacks a lo largo de los años. Primero WordPress, luego Webflow, y desde hace un tiempo Lovable. Hace poco reconstruimos la web de Odysi con Claude Design y la desplegamos con Netlify. Aquí está el detalle de lo que cambió.
El resultado no parece generado
Lovable produce buenas webs rápido, pero después de usarlo un tiempo empiezas a reconocer la forma de una web hecha con Lovable. Hay una manera por defecto de ordenar las secciones, una dependencia de cajas y tarjetas apiladas, y una maquetación que se nota generada. Está bien, pero es reconocible, y cuesta escapar de ella.
Con Claude Design acabamos con algo específico de nosotros. La maquetación sigue nuestro propio lenguaje de diseño en vez de una disposición por defecto. Eso importa cuando todo el sentido de la web es parecer un estudio que cuida el detalle.
Previsualizaciones sociales que de verdad son correctas
Esto era una frustración recurrente con Lovable. Cada vez que compartíamos una página en WhatsApp o LinkedIn, la previsualización solía estar mal: el favicon en vez de una imagen decente, una tarjeta genérica que no coincidía con la página, o una imagen de un artículo completamente distinto. Las descripciones también fallaban a menudo.
En la web reconstruida, cada página lleva sus propios datos de Open Graph y de tarjeta de Twitter: un título único, una descripción única y una imagen de previsualización dedicada de 1200 por 630 por página. Pega un enlace en cualquier sitio y la tarjeta coincide con la página.
Cómo está estructurado el HTML, y por qué los rastreadores lo manejan bien
Por nuestra experiencia, Lovable se apoyaba mucho en sistemas de clases CSS, y vimos que algunos rastreadores, Bing en concreto, tenían problemas para extraer el contenido real del marcado. Las páginas reconstruidas están estructuradas de otra forma, y comprobé los detalles antes de escribir esto.
- Elementos semánticos reales: encabezados, section, article, nav y footer usados para lo que son, un solo h1 por página, y el texto visible viviendo en el documento como texto.
- Estilos aplicados en línea sobre los elementos en vez de a través de una gran hoja de estilos basada en clases, así que hay menos indirección entre el marcado y lo que se renderiza.
- Un conjunto completo de datos estructurados de schema.org en cada página: Organization y WebSite en la portada, Article en los artículos, FAQPage en la FAQ, Service en las páginas de servicio, y un BreadcrumbList en cada subpágina.
- Metadatos completos y únicos por página, y un robots.txt que da la bienvenida explícita a los rastreadores de IA por su nombre: GPTBot, ClaudeBot, PerplexityBot y el resto, apuntados al sitemap.
Para que quede claro, las páginas son HTML semántico simple con el contenido en el documento y datos estructurados exhaustivos, servidas como archivos estáticos en vez de renderizadas en servidor, lo que las hace fáciles de leer para los rastreadores de búsqueda y los modelos de lenguaje.
Despliegue a través de Netlify
El modelo de despliegue es sencillo, algo que agradezco. El proyecto produce una carpeta de archivos estáticos: las páginas HTML, los recursos y unos pocos archivos de configuración en texto plano. Esa carpeta es lo que va a Netlify, que la sirve desde su CDN en nuestro dominio propio. No hay un servidor de build aparte ni un runtime de framework que montar en el host; simplemente sirve los archivos.
Los archivos de configuración hacen las tareas de mantenimiento. Un archivo _redirects guarda las reglas 301, que importaron durante la migración: nuestras URLs antiguas eran completamente distintas, así que mapeamos cada ruta antigua a su nueva página y conservamos el posicionamiento que esas URLs habían construido. Un archivo _headers configura la caché. Un sitemap y un robots.txt gestionan el descubrimiento, y una clave de IndexNow nos permite avisar a Bing en el momento en que una página cambia.
Un solo proyecto para todo el sistema de diseño
Esta es la parte que cambió cómo trabajamos, y es fácil de subestimar. Claude Design no se limita a producir la web. Dentro del mismo proyecto también construimos nuestro brand book, y generamos publicaciones de LinkedIn con visuales a juego.
Como todo vive en un mismo sitio, el tono, la paleta, la tipografía y las decisiones de diseño se mantienen en cada pieza. Cuando queremos producir algo nuevo para promocionar la web, el contexto ya está ahí. Producir material consistente es mucho más rápido que empezar de un archivo en blanco cada vez.
La optimización para buscadores se resolvió dentro del propio trabajo
No tuvimos que hacer una pasada de SEO aparte. Como parte de construir la web, las imágenes de origen pesadas se convirtieron a formatos más ligeros, WebP y JPEG, se fijaron las dimensiones de imagen, y se pusieron en su sitio un sitemap, URLs limpias, datos estructurados y redirecciones. La web sacó un 100 en la auditoría de SEO de PageSpeed en unos pocos prompts.
Lovable ha ido mejorando su manejo del SEO, para ser justos. La diferencia es que aquí se hizo como parte normal de la construcción en vez de algo que tuviéramos que volver a añadir después.
Backend y base de datos: Lovable aún gana
Merece la pena decirlo sin rodeos. A través de su integración con Supabase, Lovable puede montarte un backend. Si estás construyendo algo que necesita una base de datos, conecta la base de datos con el front-end automáticamente, y eso es de verdad útil.
Claude Design es sobre todo una herramienta de diseño y front-end. No hay una integración de backend nativa de ese tipo. Puedes seguir sus indicaciones para conectar un servicio de terceros o construir tu propia base de datos, pero eso es más trabajo manual. Si tu proyecto es en el fondo una aplicación apoyada en datos y no una web o un front-end, la propuesta de backend de Lovable sigue siendo la más fuerte.
Dónde nos deja esto
Para lo nuestro, la web de un estudio más el contenido y los recursos alrededor, la reconstrucción fue la decisión acertada. El resultado es distintivo en vez de de plantilla, las previsualizaciones sociales son correctas, el marcado y los datos estructurados están lo bastante limpios como para que los rastreadores y los modelos de lenguaje los lean bien, el despliegue con Netlify es sencillo, y el trabajo de base de SEO se resolvió como parte de la construcción.
El sistema de diseño viviendo en un solo proyecto, reutilizable en la web, el brand book y las publicaciones sociales, es la parte que no esperaba y de la que ahora dependo.
Si estuviéramos construyendo un producto basado en base de datos en vez de una web, el cálculo sería distinto, y la integración de backend de Lovable pesaría. Para lo que necesitábamos, esto fue un salto claro hacia arriba.