Ares

Ares és un especialista en identificació intel·ligent: lectors de codi de barres, terminals, impressores d'etiquetes, RFID i consumibles amb què altres empreses controlen el seu magatzem, la seva producció, la seva flota o la seva botiga. Combina programari propi, maquinari certificat de les marques líders del sector (Zebra, Honeywell, Datalogic) i servei tècnic oficial, tot sota un únic interlocutor. Treballa per a indústria, logística, retail, sanitat i alimentació.

El lloc web vivia sobre WordPress i WooCommerce, i arrossegava tres problemes encadenats. El primer, de volum: el catàleg havia crescut fins a ocupar desenes de milers d'URL indexables, majoritàriament fitxes d'accessoris solts (un cable, una funda, una bateria) amb una línia de text i una referència. És el manual del thin content per a qualsevol amant del SEO: milers de pàgines que no responen a cap cerca real, que es canibalitzen entre si i que consumeixen el pressupost de rastreig que haurien de rebre les pàgines que sí que generen negoci.

El segon, de rendiment: el lloc anterior era pesat i lent, molt lluny del que avui exigeix Google. El tercer, de manteniment: el catàleg real d'Ares no viu a la web, viu al seu ERP, i tot allò que obligui a duplicar informació a mà acaba desincronitzat. Calia regir-se per una filosofia SSOT, Single Source of Truth.

Un matís que condiciona el projecte sencer: Ares no ven en línia. No hi ha passarel·la de pagament. La web és una eina de captació de leads qualificats en un cicle B2B llarg, on el visitant és un director d'operacions o un cap de magatzem que necessita entendre, comparar i demanar pressupost.

Abans d'escriure una línia de codi vam auditar el catàleg i vam analitzar els competidors del sector per veure com resolien la relació entre URL, jerarquia i variants de producte. Els que millor puntuaven compartien patró: URL curtes i poc profundes, amb la jerarquia vivint al breadcrumb i a les dades estructurades, no a la ruta.

D'aquí surt la decisió que vertebra el projecte: la unitat de contingut és la família, no la referència. Un terminal no necessita cent pàgines, una per cada combinació de memòria, lector, teclat o connectivitat: necessita una pàgina de model sòlida, amb el seu configurador de variants, les seves especificacions i els seus accessoris compatibles integrats a dins. L'accessori deixa de ser una pàgina òrfena i passa a viure on té sentit: a la fitxa del producte que acompanya.

El catàleg queda així en dos nivells: més de 700 fitxes de família que concentren el contingut i l'autoritat, i els milers d'articles que hi ha al darrere, accessibles i cercables. Les fitxes pengen de l'arrel del domini (URL curtes, autoritat màxima), mentre que l'arbre de categories i subcategories es reserva per navegar i filtrar.

Sobre aquesta base vam reordenar l'arquitectura sencera: catàleg, una àrea de solucions per sector i necessitat (retail, sanitat, industrial, emmagatzematge, RFID…) que és on de debò es capta el client B2B, serveis, marques, blog i suport.

Ares no necessitava una identitat nova: necessitava afinar la que tenia perquè digués el que la companyia és avui. El posicionament no és el d'una botiga de maquinari, sinó el d'un soci tecnològic B2B que assessora, implanta i dona suport. La marca havia de sostenir aquesta conversa.

Vam fer un redisseny lleuger del logotip (netejant el traç i guanyant llegibilitat en mides petites i en fons foscos, que és on més s'utilitza) i vam construir al voltant un sistema visual sobri i de contrast alt: un blau navy com a color corporatiu, amb la serietat institucional que el sector espera, i un groc vibrant reservat per al que ha de destacar, crides a l'acció, accents i dades. Poc color, però molt decidit.

La tipografia es va resoldre amb una sans neutra i molt llegible, pensada per al que de debò es llegeix en aquesta web: taules d'especificacions, referències tècniques i comparatives de variants. En un catàleg així, la tipografia no decora: ha d'aguantar densitat de dada sense cansar.

Tot el sistema es va baixar a tokens de disseny (color, tipografia, espaiat) amb escales fluides que interpolen de manera contínua del mòbil al 4K, sense salts entre breakpoints. No és un caprici tècnic: és el que garanteix que les més de set-centes fitxes es vegin coherents sense que ningú les revisi una a una.

El catàleg s'alimenta directament de l'ERP mitjançant un pipeline de sincronització que descarrega els mitjans, crea les famílies, actualitza els articles i reindexa el cercador. Ningú puja una fitxa a mà.

La decisió de fons va ser separar la dada del contingut. Les referències, especificacions i variants venen de l'ERP i s'actualitzen soles. Els textos que posicionen i persuadeixen (solucions, sectors, marques, blog, landings) es gestionen des d'un CMS de tipus headless, amb un sistema de blocs que permet a l'equip d'Ares compondre pàgines noves sense tocar codi ni dependre de ningú.

Treballar amb dades reals d'un ERP obliga a assumir una cosa que gairebé mai s'explica: la dada arriba bruta. Els camps de text tenen una qualitat molt desigual: molts articles venen sense descripció, o amb el nom repetit, o amb la codificació trencada. Vam construir una capa de sanejament que repara el text corromput i detecta els valors escombraria en categories i descripcions abans que arribin a publicar-se, a més de regles de visibilitat que amaguen les referències sense imatge ni contingut. Sense aquesta capa, la qualitat del catàleg es degrada sola en qüestió de setmanes.

En un sector on es ven fiabilitat industrial, una web lenta o desfasada contradiu el missatge. Vam substituir el sistema anterior per una plataforma moderna en què la dada de l'ERP se sincronitza automàticament, els continguts es publiquen sense fricció i la cerca retorna resultats mentre s'escriu. L'objectiu no era només migrar: era que qualsevol visitant, des d'un mòbil en un magatzem fins a un escriptori en una oficina, tingués la sensació de ser davant d'un soci tecnològic, no davant d'un catàleg.

El cercador és probablement el que més fricció elimina del lloc. En un catàleg tècnic el visitant no navega: busca per referència («DS3608», «GK420») o per necessitat. La cerca és instantània i tolerant a errades, amb resultats que apareixen a mesura que es teclegen i facetes per marca i categoria.

El configurador de variants va ser el component més difícil de tot el projecte: hi ha models amb fins a sis dimensions de configuració (motor d'escaneig, teclat, sistema operatiu, memòria, connectivitat, bateria) i algun cas extrem que supera el centenar de combinacions. Resoldre-ho bé és exactament el que permet tenir una sola pàgina per model en lloc de cent.

Com que Ares no ven en línia, la conversió s'articula amb un carret de pressupost: l'usuari acumula els productes que li interessen i sol·licita una oferta, que aterra al CMS al costat de la resta de formularis (contacte, RMA de reparacions i candidatures de feina). La velocitat es va cuidar amb un servei propi d'imatges que redimensiona i optimitza sota demanda, precàrrega de memòria cau en arrencar el servidor i CSS crític en línia.

El SEO no va ser una capa que s'afegeix al final: va ser el criteri que va ordenar l'arquitectura des del primer dia. URL curtes, jerarquia viva al breadcrumb i a les dades estructurades, sitemaps segmentats per tipus de contingut i canonicals resolts amb criteri perquè les variants i els filtres no competeixin entre si.

La peça més interessant és la generació programàtica de títols i metadescripcions. Amb milers de fitxes alimentades per un ERP amb textos que es repeteixen, publicar sense més hauria condemnat el catàleg a la canibalització: centenars de fitxes compartint títol i metadescripcions calcades del mateix títol. Vam dissenyar un algorisme que compon tots dos per cascada, dins de la longitud òptima i tancant sempre amb la referència única de l'article, de manera que cap fitxa no canibalitza una altra.

Ho vam completar amb dades estructurades (organització, producte, breadcrumbs, FAQ, articles) i amb decisions d'higiene poc glamuroses però decisives: si el CMS no respon, la fitxa retorna un 503 i no un 404, perquè Google no desindexi un producte que sí que existeix.

Un apunt que diu molt de l'enfocament: l'schema de producte s'emet deliberadament sense preu. Ares treballa per pressupost i no publica preus; inventar-ne un per guanyar un adorn al resultat de cerca seria publicar dades falses, a més de sancionable.

Una web B2B sense carret de compra no es mesura amb les mètriques d'una botiga. No hi ha purchase per comptar, i tanmateix el negoci hi passa: cal saber quins canals porten contactes (no visites), quines famílies de producte desperten interès real i en quin punt del recorregut cau la gent. Així que abans de tocar codi vam escriure un pla de mesurament que fixa la taxonomia completa d'esdeveniments i paràmetres, i que funciona com a contracte entre desenvolupament i màrqueting.

La implantació és Google Analytics 4 a través de Google Tag Manager, amb una regla estricta: el codi no crida GA4, només publica esdeveniments al dataLayer des d'un únic mòdul centralitzat. Res de pushes solts repartits pels components. Aquesta disciplina és el que permet que l'equip de màrqueting creï o ajusti etiquetes (i demà afegeixi Google Ads o LinkedIn) sense demanar un desplegament.

La decisió més fina va ser reservar els noms d'esdeveniment estàndard del comerç electrònic (add_to_cart, begin_checkout, purchase) per a la venda en línia que Ares planeja de cara al futur, i mesurar el carret de pressupost amb esdeveniments propis. GA4 no permet reanomenar esdeveniments històrics: si el pressupost hagués ocupat aquests noms, el dia que existeixi una compra real els dos embuts quedarien barrejats per sempre.

Mesurem també els leads invisibles del B2B: en un cicle llarg, bona part de les conversions acaben en una trucada o un correu, no en un formulari, així que els clics en telèfon i correu es tracten com a conversions de ple dret. I una font de valor que gairebé ningú explota: les cerques internes sense resultats. Cada terme que un client teclega i el catàleg no sap respondre és una decisió de compres esperant que algú la llegeixi.

Tot això sobre Consent Mode v2 i un gestor de consentiment: per defecte, sense galetes; l'usuari decideix. I una regla que no es negocia: als esdeveniments mai no hi viatja una dada personal (dels formularis només en surten l'identificador i, si falla, quins camps van fallar; mai el seu contingut).

L'instint davant d'un catàleg gran és protegir el volum: com més pàgines, millor. Aquest projecte demostra el contrari. Milers de fitxes d'accessoris no eren un actiu, eren un llast: es canibalitzaven entre si, consumien el rastreig i no responien a cap cerca real.

Reordenar el catàleg al voltant de la família de producte concentra l'autoritat on pot competir. Connectar-lo a l'ERP impedeix que la dada es degradi. I separar la dada del contingut retorna a l'equip d'Ares el control editorial sense tocar el sistema que governa el seu negoci.

És la diferència entre tenir el catàleg publicat i tenir-lo treballant.