Een webshop met 2.200 producten van 132 merken heeft een probleem dat je van buitenaf niet ziet. De etalage oogt verzorgd, de productpagina's staan vol, en tóch zakt zo'n catalogus langzaam weg. Niet door te weinig producten, maar omdat niemand ze allemaal actueel, kloppend én vindbaar houdt.
Voor The Alpha Men, een webshop in mannenverzorging, was dat precies de kern. Dit stuk gaat over de machine die we eronder bouwden: een engine die de catalogus bijhoudt zonder dat het handwerk wordt.
Het verleidelijke aan generatieve AI is de belofte dat je een model één prompt geeft en dat er 2.200 mooie teksten uit rollen. In de praktijk is dat de snelste manier om een catalogus onbetrouwbaar te maken. Een model dat zonder bron schrijft, verzint specificaties die nét verkeerd zijn: een verpakkingsmaat die niet klopt, een ingrediënt dat er niet in zit, een claim die je niet mág maken. Bij tien producten valt dat op, bij 2.200 niet.
De vraag was dus niet "hoe schrijven we teksten", maar "hoe bouwen we een proces dat op schaal klopt, controleerbaar is en zichzelf blijft bewijzen".
Van losse flows naar een engine in code
De uitgangssituatie was een reeks n8n-workflows op GPT. Dat werkt om mee te beginnen, maar het schaalt slecht. De logica ligt versnipperd over losse flows, versiebeheer ontbreekt, prompts driften uiteen, en als er iets misgaat, lees je nergens terug wát er veranderde en waarom.
Voor een catalogus die continu beweegt, met nieuwe merken, nieuwe varianten en producten die uitverkopen, wil je geen verzameling losse knoppen. Je wilt één reproduceerbare pijplijn.
Daarom brachten we de hele productie onder in een versiebeheerde repository op GitHub, in twee delen: een engine die content genereert, en een engine die de catalogus meet en auditeert. Elke run is code, elke wijziging een commit. De volledige geschiedenis van de catalogus, mét de reden achter iedere ingreep, ligt vast. Dat lijkt een technisch detail, maar het is het fundament: pas als je weet wat er is gebeurd, kun je iets beloven over kwaliteit.
De bron als grondstof, het juiste model per taak
De pijplijn begint niet bij het model, maar bij de bron. Per merk halen we via ScraperAPI de officiële productinformatie op, met een configuratie die weet waar de specs van dat merk staan en hoe ze eruitzien. Het model krijgt dus echte fabrikantdata als grondstof en hoeft niets te gokken. Zo krijg je een tekst die klopt en niet alleen overtuigend klinkt. En bij verzorging, waar ingrediënten en claims tellen, is dat geen luxe maar een voorwaarde.
Vervolgens kiezen we per taak bewust een model. Voor beschrijvende copy, waar toon en overtuiging tellen, pakken we Claude Sonnet. Voor het volumewerk en de korte, feitelijke velden zetten we Haiku in: sneller, fors goedkoper, en ruim voldoende voor tekst die vooral correct moet zijn. Zo houden we de kwaliteit hoog waar de klant het merkt, en de kosten laag waar niemand het merkt.
Dat je zo van model kunt wisselen zonder je opzet te herbouwen, is geen toeval maar een ontwerpkeuze. Die werkte ik uit in wat je zelf bezit en wat je huurt.
Wat de generatie oplevert, gaat niet zomaar de winkel in. Elke tekst loopt eerst langs Google Cloud Natural Language, dat entiteiten, categorieën en sentiment bepaalt. Zo checken we of een tekst écht over het juiste product gaat, in de juiste categorie valt en de juiste toon houdt. Alleen wat die controle doorstaat, mag gepubliceerd worden. Een simpele regel met grote gevolgen: de machine mag alles genereren, maar niets ongezien publiceren.
Een audit die de volgorde bepaalt
De tweede engine kijkt naar de hele catalogus tegelijk in plaats van naar losse teksten. Elk product krijgt een hygiënescore op meerdere punten: titel, beschrijving, aantal afbeeldingen, Google-productcategorie en de metafields, waaronder het veld dat producten voor cross-sell aan elkaar knoopt. De score is gewogen, dus de audit zegt niet alleen wát ontbreekt, maar ook wat als eerste moet.
En dat rapport was direct verhelderend. Over de hele catalogus kwam de gemiddelde hygiënescore uit op 86,9 van de 100. Het SEO-fundament bleek sterk: 95% van de producten had een SEO-titel, 92% een SEO-beschrijving.
De grootste winst zat dus niet in de tekst, maar eromheen. 78% van de producten had minder dan drie afbeeldingen, veruit de grootste hefboom voor conversie en Shopping. 64% miste een Google-productcategorie, wat de vindbaarheid in Shopping direct afknijpt. En 41% miste het koppelveld tussen producten. Dat zijn geen aannames maar meetwaarden, en omdat de meting code is, kun je hem elke run opnieuw langs de catalogus leggen. Zo toon je vooruitgang aan in plaats van erop te hopen.
Belangrijker dan de cijfers is wat je ermee doet. De audit is een werklijst. De 78% zonder genoeg afbeeldingen werd meteen de eerste prioriteit, de ontbrekende Google-categorieën de tweede, de koppelvelden de derde. Zo verschuift het gesprek van "de content kan beter" naar "dit zijn de producten die als eerste aandacht verdienen, in deze volgorde, om deze reden". Een catalogus van 2.200 producten wordt daarmee behapbaar: niet alles tegelijk oppakken, maar eerst wat het meeste oplevert. En omdat elke verbetering opnieuw wordt gemeten, zie je de score na elke ronde bewegen. De audit sluit het werk dus niet af, hij bepaalt wat er als volgende gebeurt.
Goedgekeurde content en verbeterde velden gaan tot slot via de Shopify Admin API terug de winkel in, metafields incluis. Eén verbetering werkt zo door op de productpagina én in de feed, en daarmee in SEO en Shopping tegelijk.
De winst zit niet in "AI die teksten schrijft". Dat is het makkelijke deel, en dat kan inmiddels iedereen. De echte winst zit in de poorten eromheen: de bron als grondstof, het juiste model per taak, een controle vóór publicatie, en een auditscore die de volgorde bepaalt. De engine schrijft niet zomaar 2.200 teksten weg. Alleen wat de controle doorstaat gaat live, alles is terug te lezen, en de catalogus houdt zichzelf meetbaar op orde. Daar draait een winkel elke dag op, en op een demo niet.