Reconstruir nuestra web con Claude Design en vez de Lovable
Cómo sacamos de Lovable la web de nuestro estudio, contado sin adornos: qué mejoró, qué aspecto tienen de verdad los archivos entregados, y el único punto en el que Lovable aún gana. Escrito para quienes se fijan en 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. Esto es lo que cambió, con detalle.
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 que es claramente nuestro. La maquetación sigue nuestro propio lenguaje de diseño en vez de una disposición por defecto. Eso importa cuando la razón de ser de la web es transmitir que somos un estudio que cuida el detalle.
Vistas previas en redes que por fin salen bien
Con Lovable, esto nos frustraba una y otra vez. 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 presente en el documento como texto real.
- 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.
En resumen, las páginas son HTML semántico sencillo 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 se encargan del 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 se habían ganado. 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ó nuestra forma de trabajar, y es fácil subestimarla. 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 coherente es mucho más rápido que partir cada vez de un archivo en blanco.
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 consiguió un 100 en la auditoría de SEO de PageSpeed con unos pocos prompts.
Para ser justos, Lovable ha ido mejorando en SEO. La diferencia es que aquí se hizo como parte normal de la construcción en vez de ser algo que tuviéramos que añadir a posteriori.
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 muy ú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 sólida.
Dónde nos deja esto
En nuestro caso, la web de un estudio con su contenido y sus recursos, la reconstrucción fue la decisión acertada. El resultado tiene personalidad propia en vez de parecer una plantilla, las vistas previas en redes salen bien, 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.
Tener el sistema de diseño en un solo proyecto, reutilizable en la web, el brand book y las publicaciones sociales, es lo que no esperaba y de lo que ahora dependo.
Si estuviéramos construyendo un producto que gira en torno a una base de datos en vez de una web, el cálculo sería distinto, y la integración de backend de Lovable pesaría más. Para lo que necesitábamos, esto ha sido un salto de calidad claro.