Furgonetas.net: cuando el producto, el SEO y la arquitectura técnica son lo mismo
Hay proyectos donde el SEO se añade al final, como un parche. Donde el diseño ocurre en una reunión y la tecnología intenta seguirle la corriente. Donde la IA se integra "porque hay que estar en eso".
Furgonetas.net no es ninguno de esos proyectos.
Es un marketplace vertical para la compraventa de furgonetas de ocasión en España. Suena a nicho. Lo es. Y eso es exactamente lo que lo hace interesante: no había forma de resolverlo bien sin pensar el producto, el SEO y la arquitectura al mismo tiempo, como si fueran una sola cosa. Porque lo son.
El problema no era tecnológico. Era de modelo.
Antes de escribir una sola línea de código, había una pregunta que resolver: ¿qué es exactamente este producto?
La respuesta tiene dos capas. Por un lado, un marketplace público donde particulares y profesionales venden furgonetas. Por otro, un canal de captación de leads cualificados para concesionarios y gestores de flotas que quieren comprar furgonetas a particulares, pero sin que esa transacción sea visible en la web.
Dos flujos de negocio radicalmente distintos. Dos tipos de usuario con expectativas opuestas. Un solo producto que tiene que albergarlos a ambos sin que el usuario se confunda, sin que la lógica de uno contamine al otro, y sin que el código se convierta en un laberinto.
El formulario de "vender mi furgoneta" se bifurca en función de la intención: si el usuario quiere publicar un anuncio, entra en el flujo del marketplace. Si quiere vender directamente a un profesional, genera un lead interno que jamás aparece en la web pública. Mismo punto de entrada. Lógica completamente distinta detrás.
Eso no es un detalle de UX. Es una decisión de producto y arquitectura que condiciona absolutamente todo lo que viene después.
El SEO no se construyó encima de la aplicación. Está dentro de ella.
La mayoría de proyectos SEO de este tipo funcionan así: primero se construye la app, luego alguien pide "páginas de ciudad por marca" y el equipo técnico intenta generar algo a partir de lo que hay. El resultado suele ser páginas vacías, contenido repetido o URLs que Google ignora porque no tienen nada real detrás.
En furgonetas.net, el esquema de base de datos se diseñó desde el inicio para alimentar páginas transaccionales indexables. Los slugs, los campos de ubicación normalizados, las taxonomías filtradas —provincia, marca, modelo, tipo de combustible— no son metadatos añadidos después. Son la estructura sobre la que se levanta toda la lógica del producto.
Las landings programáticas por ciudad o por modelo solo se generan cuando hay inventario real detrás. No hay páginas vacías esperando que alguien publique algo. No hay contenido thin que Google penalice. La arquitectura de datos es, en sí misma, la estrategia SEO.
Y el contenido de esas páginas no se genera con IA. Se genera con plantillas condicionales en tres niveles —stock bajo, medio y alto— que adaptan el texto al volumen de anuncios reales en cada combinación. El resultado es lenguaje natural que nunca promete lo que no hay. Sin riesgo de alucinaciones, sin repetición, sin el riesgo reputacional de que una página afirme tener cien furgonetas cuando hay tres.
Tres tipos de usuario. Un solo sistema. Cero colisiones.
El producto no tiene "un usuario genérico". Tiene particulares que pueden ser compradores y vendedores a la vez. Tiene profesionales que operan como empresa —no como individuo—, con varios usuarios bajo una misma cuenta. Y tiene administradores con acceso total y trazabilidad de cada acción.
Cada rol tiene su propio espacio, sus propios permisos, sus propias pantallas. Diseñar esto con una sola base de código, sin que los permisos colisionen ni que la lógica de un rol afecte a otro, requiere un modelo de datos que esté bien pensado desde el minuto uno. No es algo que se pueda refactorizar después.
Un ejemplo concreto que ilustra hasta qué punto importa el modelo de datos: un anuncio en furgonetas.net no pertenece al usuario que lo publicó. Pertenece a la empresa. Si un comercial de un concesionario publica cuarenta anuncios y después abandona la empresa, esos anuncios tienen que seguir activos bajo la cuenta corporativa, seguir generando leads, seguir siendo gestionables por el resto del equipo. Resolver la relación usuario ↔ empresa ↔ anuncio ↔ leads con coherencia no es un problema de base de datos. Es un problema de negocio. Y tiene que estar resuelto en el modelo antes de empezar a construir pantallas.
La IA como pieza funcional, no como decoración
El módulo de tasación de furgonetas no es un chatbot. No es un campo donde el usuario pregunta "¿cuánto vale mi furgoneta?" y recibe una respuesta de texto.
Es un servicio construido con un prompt de sistema específico para el mercado de furgonetas en España, con campos diferenciales del sector —tipo de carrocería, carga útil en kilogramos— y con contextualización de IVA para empresas versus particulares. La temperatura del modelo está calibrada baja para conseguir rangos de precio consistentes. El resultado se almacena en base de datos, alimenta el lead que recibe el profesional, condiciona el CTA que ve el usuario y genera un email con la valoración.
La IA, aquí, es una pieza del flujo de negocio. No una feature aparte.
Y está desacoplada del proveedor: cambiar de OpenAI a Anthropic es cambiar un archivo de configuración, no reescribir lógica de negocio.
Porque en producción los casos de error también son parte del diseño: si la IA falla, hay fallback manual. Si dos solicitudes son prácticamente idénticas, se reutiliza la respuesta cacheada. Si una IP supera tres valoraciones en veinticuatro horas, se limita. En un modelo con costes por llamada a API, el control del gasto no es un detalle técnico. Es parte de la arquitectura.
Un backoffice que es un flujo de negocio
El área de administración de furgonetas.net no es una tabla con botones. Es el sistema operativo del negocio.
Cubre la revisión de solicitudes de registro de nuevos profesionales, la creación manual de empresas con datos prellenados, la verificación por pasos, la moderación de anuncios con historial completo, la asignación de leads de venta a una o varias empresas, la gestión de usuarios y la configuración global del sistema. Todo conectado. Todo con trazabilidad de quién hizo qué y cuándo.
El proceso de alta de un concesionario tiene cinco estados y sigue un flujo deliberadamente controlado: formulario de contacto → revisión del equipo → llamada → creación de empresa por el admin → envío de credenciales → verificación final. Cada paso tiene su estado, su email automático y su pantalla correspondiente. No es automatización sin más. Es una decisión de producto para garantizar la calidad de la oferta en el MVP, filtrando quién puede operar en la plataforma desde el inicio.
Un anuncio, por su parte, no está simplemente "publicado" o "no publicado". Tiene siete estados —borrador, pendiente de moderación, publicado, pausado, caducado, rechazado, vendido— con transiciones controladas: condiciones claras sobre quién puede ejecutar cada una, qué consecuencias genera en visibilidad, emails y notificaciones, y desactivación automática por inactividad con reactivación que vuelve a pasar por moderación.
Los leads tienen su propio ciclo de vida: nuevo → asignado → contactado → cita agendada → cerrado. Los leads de empresas se notifican a todos los usuarios de esa empresa, no solo a quien publicó el anuncio. Y cada lead de venta a profesional lleva información interna —justificación de la valoración, modelo de IA utilizado, respuesta raw— que el usuario nunca ve, pero que permite auditar el sistema y mejorarlo.
Lo que hace que esto sea difícil
No es la cantidad de funcionalidades. Es que todas las decisiones tienen que ser coherentes entre sí desde el primer día.
El modelo de datos que permite el SEO programático es el mismo que resuelve la propiedad de los anuncios por empresa. La arquitectura que desacopla la IA del proveedor es la misma que permite añadir caché y rate limiting sin tocar la lógica de negocio. El flujo de onboarding controlado condiciona cómo funciona el backoffice. El doble modelo de negocio afecta a cómo se diseñan las pantallas, cómo se generan los emails, cómo se almacenan los datos.
En este tipo de proyectos no hay decisiones técnicas menores. Hay decisiones que, tomadas bien desde el inicio, hacen que todo lo demás sea posible. Y tomadas mal, convierten cada nueva funcionalidad en una deuda que alguien tendrá que pagar más tarde.
Furgonetas.net es el resultado de tomar esas decisiones bien.
¿Tienes un proyecto con este nivel de complejidad? Cuéntanos qué necesitas.