Wat een eerlijke SEO-audit van een Magento-shop écht boven water haalt

De meeste Magento-shops die ik open in Search Console hebben hetzelfde verhaal: vijf jaar geleden ingericht door iemand die sindsdien weg is, een opeenstapeling van modules, en een eigenaar die "denkt dat de SEO wel okay is, want we zien wat verkeer binnenkomen". Vaak draait dat verkeer op merkkennis. De brand wordt ingetypt door bestaande klanten, niet door zoekers die op zoek zijn naar een product.

Toen ik een SEO-audit deed op een shop met 13.600 productpagina's in vier talen kwam ik dingen tegen die ik in tien jaar webwerk niet meer voor ogen had. Hieronder zet ik op een rij wat ik vond, hoe ik wist dat het kapot was, en wat we deden om het te repareren zonder de hele site te verbouwen.

Wat ik vond toen ik echt ging kijken

Een SEO-audit die alleen Lighthouse en een crawl draait, mist 90 procent. Ik open altijd zelf twintig productpagina's in elke taal, kopieer de gerenderde HTML, valideer de JSON-LD apart, en vergelijk de hreflang-uitvoer tussen taalvarianten. Daar kwam dit uit:

Product JSON-LD was op 97 procent van de PDP's invalide. Niet "een veld vergeten", maar daadwerkelijk kapot. De responsible module had nl2br() op de productdescription gedraaid voordat het in een JSON-string werd gestopt. Dat liet rauwe \r\n staan in de output. Google's Rich Results Test zag een ongeldige JSON en gooide de hele structured data weg. Resultaat: nul productfragmenten in de zoekresultaten, terwijl elke concurrent met sterren en prijzen werd getoond.

Geen enkele productpagina had het brand-veld ingevuld. Magento had een attribuut manufacturer maar de JSON-LD-template las daar niets uit. Dat is een vinkje van twintig minuten in het admin, en het was over alle vijfduizend producten verzaakt.

GTIN, EAN en MPN ontbraken volledig. Op alle 13.600 PDP's. Voor een shop die producten van bekende merken doorverkoopt, is dit het verschil tussen wel of niet meegenomen worden in Google's Shopping-knooppunt. Het EAN-attribuut stond gewoon in de database, alleen niet doorgegeven aan de structured data.

96 procent van de meta-titels stond in ALL-CAPS. Iedere pagina. In vier talen. Iemand had ooit een import-script gedraaid met strtoupper() over de productnamen, en daarna is dat nooit teruggedraaid. Vanuit Google's oogpunt was elke titel een schreeuw, wat in 2026 een zachte ranking-penalty oplevert maar vooral een click-through-rate-probleem is. Mensen klikken niet op MERKNAAM PRODUCTLIJN MODELCODE BESCHRIJVING ACCESSOIRE.

De BreadcrumbList-JSON-LD was leeg voor crawlers. De zichtbare breadcrumb op de pagina werkte alleen client-side, maar de JSON-LD-module probeerde dezelfde catalog-sessie te lezen vóórdat die door Magento was gevuld. Een race condition tussen twee modules waar de breadcrumb-schema-output bij de loser eindigde. Crawlers zagen dus geen hiërarchie.

Het is geen lijstje obscure dingen. Dit zijn de fundamenten waar Google productfragmenten op baseert.

Hoe ik dit op één plek bij elkaar kreeg

Voor een audit als deze gebruik ik geen tool. Tools laten me niet op de juiste manier zoeken. Concreet werkproces:

1. Sitemap downloaden en de eerste 48 PDP's open trekken met curl --silent. Niet de homepage van elke categorie, maar de echte productpagina's. Dat is waar het geld zit en waar 95 procent van de SEO-problemen zich verstopt.
2. De JSON-LD eruit grep'pen met een korte regex, opslaan in losse bestanden, en door schema.org Validator halen. Hoeveel valide, hoeveel niet, en als ze niet valide zijn: welke veldcombinatie ontbreekt structureel?
3. Headers, hreflang en canonical vergelijken tussen de vier talen. Niet via een crawl-tool maar handmatig op tien pagina's. Een mismatch in één lang-attribuut maakt drie van de vier hreflang-tags ongeldig in Google's ogen.
4. Search Console openen en kijken hoeveel rich results geldig waren. Dat is je eindscore. Bij deze shop: nul. Vergelijk dat met je concurrenten en het wordt pijnlijk.

Het hele proces duurt geen middag, en alles wat ik vind onderbouw ik met een directe URL en de output van een validator. Een audit zonder verifieerbare nummers is een onderbuikgevoel, en je klant kan er niets mee.

Wat ik vervolgens deed

Geen herbouw. Geen "we doen Magento 2.4.7 met een PWA frontend en alles wordt anders". Dat soort projecten faalt omdat de opdrachtgever zich niet kan veroorloven dat de shop weken stilstaat terwijl er een nieuw platform ingedoken wordt.

Concreet, gerangschikt naar impact-per-werkuur:

• Product-JSON-LD-template herschreven. De rauwe-\r\n-bug was te repareren door de bestaande string-concatenatie te vervangen door één json_encode() over een PHP-array. Dat garandeert valide output, ook bij rommelige bron-data. Eenmaal gedeployd: 100 procent valide, in alle vier talen. 654 geldige rich results binnen drie crawls van Google.
• Brand- en GTIN-attribuut gemapt. In Magento's website-scope-config: brand mapt naar manufacturer, gtin mapt naar ean. Tien minuten werk, instant zichtbaar in Search Console na herindexering.
• ALL-CAPS-titels in Title Case via een hybride aanpak. Niet domweg ucfirst() over alles, want je verliest dan modelnummers en merkcodes (R1, TST, FM10). Ik gebruikte twee Sonnet-agents om elk woord in onze 16.000 titels te classificeren als KEEP, LOWER of TITLE, gevolgd door een deterministische PHP-functie die de transformatie toepaste met merk-dictionary en minor-words per taal. Harde guardrail: lower(before) == lower(after) per rij. Dat garandeert dat er niets aan de content is veranderd, alleen aan de casing. Bewijsbaar voor de klant.
• BreadcrumbList-schema server-side. Een eigen ViewModel die Home > [deepest non-brand category] > Product bouwt vanuit de catalog-tree zonder afhankelijkheid van de body-sessie. Een race condition los je niet op door wachten in te bouwen, maar door de afhankelijkheid weg te halen.

Voor elke fix had ik een live diff. Dezelfde 48 PDP's voor en na, zelfde validators, zelfde Search Console-views. Geen "trust me bro": als de validator vóór de fix een fout gaf en daarna groen werd, kan ik het laten zien.

Wat ik wel geleerd heb tijdens de uitvoering

Een paar dingen die ik op verzoek zal herhalen voor de volgende Magento-audit:

• Production-mode serveert geminificeerde view_preprocessed-kopieën. Een cache:flush raakt die niet. Je moet setup:static-content:deploy draaien en de Varnish-cache purgen, anders zie je je oude template gewoon terug. Dit kost je vier deploys voordat je doorhebt waarom je fix niet zichtbaar wordt. Verifieer altijd backend-direct via poort 8080.
• Module-layout geldt voor élke store-view. Als je in app/code/Vendor/Module/view/frontend/layout/ iets toevoegt, raakt het ook de zeventien shops die je niet bedoelt. Een website-scope-guard in de ViewModel is geen luxe maar verplicht.
• Search Console's "niet-geïndexeerd" telt mee. Bij deze shop: 366.000 niet-geïndexeerde URLs versus 14.000 geïndexeerd. Een verhouding van 25 op 1. Dat zijn vaak facet-URL-explosies die crawlbudget opvreten en geen waarde toevoegen. Zet ze op noindex en sluit ze uit van de sitemap.

Wanneer je een audit zoals deze nodig hebt

Vaak hoor ik "we doen SEO al via een specialist". Vraag dan eens dit: laat me twintig productpagina's zien waarvan jouw structured data valide is in de Rich Results Test. Als die niet binnen een dag op tafel ligt, zit er meer kapot dan je denkt.

Een SEO-audit is geen luxe-product. Het is een fact-finding-ronde die je laat zien waar je staat versus je concurrenten in de zoekresultaten. Vraagprijs ligt bij mij op een paar honderd euro voor een shop met enkele duizenden producten, en je krijgt een lijst met prioriteiten gerangschikt naar impact per werkuur. Geen "we kunnen er nog tien dingen bij doen". Geen retainer-as-a-trojan-horse.

Rechtstreeks praten?

Twijfel je of jouw shop technisch op orde is voor Google's productknooppunt, of wil je een second opinion op een lopend SEO-traject? Stuur me een bericht. Ik kijk binnen één werkdag mee.