Ares

Ares es un especialista en identificación inteligente: lectores de código de barras, terminales, impresoras de etiquetas, RFID y consumibles con los que otras empresas controlan su almacén, su producción, su flota o su tienda. Combina software propio, hardware certificado de las marcas líderes del sector —Zebra, Honeywell, Datalogic— y servicio técnico oficial, todo bajo un único interlocutor. Trabaja para industria, logística, retail, sanidad y alimentación.

El sitio web vivía sobre WordPress y WooCommerce, y arrastraba tres problemas encadenados. El primero, de volumen: el catálogo había crecido hasta ocupar decenas de miles de URL indexables, en su mayoría fichas de accesorios sueltos —un cable, una funda, una batería— con una línea de texto y una referencia. Es el manual del thin content para cualquier amante del SEO: miles de páginas que no responden a ninguna búsqueda real, que se canibalizan entre sí y que consumen el presupuesto de rastreo que deberían recibir las páginas que sí generan negocio.

El segundo, de rendimiento: el sitio anterior era pesado y lento, muy lejos de lo que hoy exige Google. El tercero, de mantenimiento: el catálogo real de Ares no vive en la web, vive en su ERP, y todo lo que obligue a duplicar información a mano acaba desincronizado. Había que regirse por una filosofía SSOT, Single Source of Truth.

Un matiz que condiciona el proyecto entero: Ares no vende online. No hay pasarela de pago. La web es una herramienta de captación de leads cualificados en un ciclo B2B largo, donde el visitante es un director de operaciones o un jefe de almacén que necesita entender, comparar y pedir presupuesto.

Antes de escribir una línea de código auditamos el catálogo y analizamos a los competidores del sector para ver cómo resolvían la relación entre URL, jerarquía y variantes de producto. Los que mejor puntuaban compartían patrón: URL cortas y poco profundas, con la jerarquía viviendo en el breadcrumb y en los datos estructurados, no en la ruta.

De ahí sale la decisión que vertebra el proyecto: la unidad de contenido es la familia, no la referencia. Un terminal no necesita cien páginas —una por cada combinación de memoria, lector, teclado o conectividad—: necesita una página de modelo sólida, con su configurador de variantes, sus especificaciones y sus accesorios compatibles integrados dentro. El accesorio deja de ser una página huérfana y pasa a vivir donde tiene sentido: en la ficha del producto al que acompaña.

El catálogo queda así en dos niveles: más de 700 fichas de familia que concentran el contenido y la autoridad, y los miles de artículos que hay detrás, accesibles y buscables. Las fichas cuelgan de la raíz del dominio —URL cortas, máxima autoridad—, mientras que el árbol de categorías y subcategorías se reserva para navegar y filtrar.

Sobre esa base reordenamos la arquitectura entera: catálogo, un área de soluciones por sector y necesidad (retail, sanidad, industrial, almacenaje, RFID…) que es donde de verdad se capta al cliente B2B, servicios, marcas, blog y soporte.

Ares no necesitaba una identidad nueva: necesitaba afinar la que tenía para que dijera lo que la compañía es hoy. El posicionamiento no es el de una tienda de hardware, sino el de un socio tecnológico B2B que asesora, implanta y da soporte. La marca tenía que sostener esa conversación.

Hicimos un rediseño ligero del logotipo —limpiando el trazo y ganando legibilidad en tamaños pequeños y en fondos oscuros, que es donde más se usa— y construimos alrededor un sistema visual sobrio y de contraste alto: un azul navy como color corporativo, con la seriedad institucional que el sector espera, y un amarillo vibrante reservado para lo que debe destacar, llamadas a la acción, acentos y datos. Poco color, pero muy decidido.

La tipografía se resolvió con una sans neutra y muy legible, pensada para lo que de verdad se lee en esta web: tablas de especificaciones, referencias técnicas y comparativas de variantes. En un catálogo así, la tipografía no decora: tiene que aguantar densidad de dato sin cansar.

Todo el sistema se bajó a tokens de diseño —color, tipografía, espaciado— con escalas fluidas que interpolan de forma continua del móvil al 4K, sin saltos entre breakpoints. No es un capricho técnico: es lo que garantiza que las más de setecientas fichas se vean coherentes sin que nadie las revise una a una.

El catálogo se alimenta directamente del ERP mediante un pipeline de sincronización que descarga los medios, crea las familias, actualiza los artículos y reindexa el buscador. Nadie sube una ficha a mano.

La decisión de fondo fue separar el dato del contenido. Las referencias, especificaciones y variantes vienen del ERP y se actualizan solas. Los textos que posicionan y persuaden —soluciones, sectores, marcas, blog, landings— se gestionan desde un CMS de tipo headless, con un sistema de bloques que permite al equipo de Ares componer páginas nuevas sin tocar código ni depender de nadie.

Trabajar con datos reales de un ERP obliga a asumir algo que casi nunca se cuenta: el dato llega sucio. Los campos de texto tienen una calidad muy desigual —muchos artículos vienen sin descripción, o con el nombre repetido, o con la codificación rota—. Construimos una capa de saneamiento que repara el texto corrupto y detecta los valores basura en categorías y descripciones antes de que lleguen a publicarse, además de reglas de visibilidad que ocultan las referencias sin imagen ni contenido. Sin esa capa, la calidad del catálogo se degrada sola en cuestión de semanas.

En un sector donde se vende fiabilidad industrial, una web lenta o desfasada contradice el mensaje. Reemplazamos el sistema anterior por una plataforma moderna en la que el dato del ERP se sincroniza automáticamente, los contenidos se publican sin fricción y la búsqueda devuelve resultados mientras se escribe. El objetivo no era solo migrar: era que cualquier visitante, desde un móvil en un almacén hasta un escritorio en una oficina, tuviera la sensación de estar ante un socio tecnológico, no ante un catálogo.

El buscador es probablemente lo que más fricción elimina del sitio. En un catálogo técnico el visitante no navega: busca por referencia —«DS3608», «GK420»— o por necesidad. La búsqueda es instantánea y tolerante a erratas, con resultados que aparecen según se teclea y facetas por marca y categoría.

El configurador de variantes fue el componente más difícil de todo el proyecto: hay modelos con hasta seis dimensiones de configuración —motor de escaneo, teclado, sistema operativo, memoria, conectividad, batería— y algún caso extremo que supera el centenar de combinaciones. Resolverlo bien es exactamente lo que permite tener una sola página por modelo en lugar de cien.

Como Ares no vende online, la conversión se articula con un carrito de presupuesto: el usuario acumula los productos que le interesan y solicita una oferta, que aterriza en el CMS junto al resto de formularios —contacto, RMA de reparaciones y candidaturas de empleo—. La velocidad se cuidó con un servicio propio de imágenes que redimensiona y optimiza bajo demanda, precarga de caché al arrancar el servidor y CSS crítico en línea.

El SEO no fue una capa que se añade al final: fue el criterio que ordenó la arquitectura desde el primer día. URL cortas, jerarquía viva en el breadcrumb y en los datos estructurados, sitemaps segmentados por tipo de contenido y canonicals resueltos con criterio para que las variantes y los filtros no compitan entre sí.

La pieza más interesante es la generación programática de títulos y metadescripciones. Con miles de fichas alimentadas por un ERP cuyos textos se repiten, publicar sin más habría condenado al catálogo a la canibalización: cientos de fichas compartiendo título y metadescripciones calcadas del propio título. Diseñamos un algoritmo que compone ambos por cascada, dentro de la longitud óptima y cerrando siempre con la referencia única del artículo, de modo que ninguna ficha canibaliza a otra.

Lo completamos con datos estructurados (organización, producto, breadcrumbs, FAQ, artículos) y con decisiones de higiene poco glamurosas pero decisivas: si el CMS no responde, la ficha devuelve un 503 y no un 404, para que Google no desindexe un producto que sí existe.

Un apunte que dice mucho del enfoque: el schema de producto se emite deliberadamente sin precio. Ares trabaja por presupuesto y no publica precios; inventar uno para ganar un adorno en el resultado de búsqueda sería publicar datos falsos, además de sancionable.

Una web B2B sin carrito de compra no se mide con las métricas de una tienda. No hay purchase que contar, y sin embargo el negocio pasa por ahí: hay que saber qué canales traen contactos —no visitas—, qué familias de producto despiertan interés real y en qué punto del recorrido se cae la gente. Así que antes de tocar código escribimos un plan de medición que fija la taxonomía completa de eventos y parámetros, y que funciona como contrato entre desarrollo y marketing.

La implantación es Google Analytics 4 a través de Google Tag Manager, con una regla estricta: el código no llama a GA4, solo publica eventos en el dataLayer desde un único módulo centralizado. Nada de pushes sueltos repartidos por los componentes. Esa disciplina es lo que permite que el equipo de marketing cree o ajuste etiquetas —y mañana añada Google Ads o LinkedIn— sin pedir un despliegue.

La decisión más fina fue reservar los nombres de evento estándar del comercio electrónico —add_to_cart, begin_checkout, purchase— para la venta online que Ares planea a futuro, y medir el carrito de presupuesto con eventos propios. GA4 no permite renombrar eventos históricos: si el presupuesto hubiera ocupado esos nombres, el día que exista una compra real los dos embudos quedarían mezclados para siempre.

Medimos también los leads invisibles del B2B: en un ciclo largo, buena parte de las conversiones acaban en una llamada o un correo, no en un formulario, así que los clics en teléfono y email se tratan como conversiones de pleno derecho. Y una fuente de valor que casi nadie explota: las búsquedas internas sin resultados. Cada término que un cliente teclea y el catálogo no sabe responder es una decisión de compras esperando a que alguien la lea.

Todo ello sobre Consent Mode v2 y un gestor de consentimiento: por defecto, sin cookies; el usuario decide. Y una regla que no se negocia: en los eventos nunca viaja un dato personal —de los formularios solo salen el identificador y, si falla, qué campos fallaron; jamás su contenido—.

El instinto ante un catálogo grande es proteger el volumen: cuantas más páginas, mejor. Este proyecto demuestra lo contrario. Miles de fichas de accesorios no eran un activo, eran un lastre: se canibalizaban entre sí, consumían el rastreo y no respondían a ninguna búsqueda real.

Reordenar el catálogo alrededor de la familia de producto concentra la autoridad donde puede competir. Conectarlo al ERP impide que el dato se degrade. Y separar el dato del contenido devuelve al equipo de Ares el control editorial sin tocar el sistema que gobierna su negocio.

Es la diferencia entre tener el catálogo publicado y tenerlo trabajando.