Een SEO-audit van een webshop lijkt niet op die van een blog. De catalogus introduceert variabelen die een redactionele site niet heeft: productvarianten, facetfilters, wisselende voorraad en sorteeparameters die duizenden URL’s genereren. Daarom is mijn antwoord altijd hetzelfde wanneer iemand me vraagt waar te beginnen: open Search Console niet om grafieken te bekijken. Stel eerst een reproduceerbare omgeving in waarmee je zonder ruis kunt meten. Dit artikel beschrijft die exacte volgorde, in de volgorde waarin je die het beste kunt uitvoeren.
Stap 0: bereid de omgeving voor voordat je de winkel aanraakt
Voordat je iets auditeert, heb je drie dingen nodig. Als je die overslaat, neem je uiteindelijk beslissingen op basis van vervuilde data.
1. Een referentiecrawl met de user-agent van Googlebot
Stel Screaming Frog (of de tool die je gebruikt) in met de user-agent van Googlebot smartphone en schakel JavaScript-rendering in. In een ecommerce-omgeving met lazy loading van afbeeldingen en prijzen die via AJAX worden geladen, levert een crawl zonder rendering je lege templates en valse duplicaten op. Het is de meest voorkomende fout die ik zie: er wordt geaudit met de standaard desktopcrawl en er wordt geconcludeerd dat er duplicate content is waar alleen sprake is van onvolledige rendering.
2. Aparte properties in Search Console
Heb een domeinproperty en een URL-prefixproperty met de canonieke versie. Vergelijk beide. Als de data sterk verschillen, heb je een probleem met redirects of met parameters die je niet onder controle hebt.
3. Export van serverlogs
Vraag het infrastructuurteam om minstens 15 dagen logs met IP, user-agent, opgevraagde URL en statuscode. Zonder dit kun je niet weten wat Google daadwerkelijk crawlt, alleen wat je tool denkt dat er gecrawld wordt.
Stap 1: bevries de indexeerbaarheid en documenteer de beginsituatie
Voordat je canonicals wijzigt of noindex toevoegt, sla je een momentopname op van de huidige situatie: aantal geïndexeerde URL’s, ingediende sitemap, robots.txt en meta-directieven van de belangrijkste templates (categorie, product, filters).
Een detail dat je alleen in de praktijk leert: in PrestaShop en in sommige WooCommerce-configuraties met filterplugins blokkeert het robots.txt /*?orderby=, maar blijven interne links naar die URL’s wijzen. Resultaat: Google kan de pagina niet crawlen, maar ontdekt de link wel en verzamelt signalen op een geblokkeerde URL. Controleer altijd de consistentie tussen wat geblokkeerd is en wat gelinkt wordt.
Stap 2: breng de werkelijke architectuur van de catalogus in kaart
Niet die je hebt ontworpen, maar die bestaat. Exporteer alle gecrawlde URL’s en classificeer ze in vier categorieën:
- Canonieke producten
- Navigeerbare categorieën
- Facetten en parameters
- Systeem-URL’s (winkelwagen, checkout, account, interne zoekopdracht)
Tel hoeveel er van elk type zijn. In middelgrote winkels is het gebruikelijk dat de facetten in aantal groter zijn dan de producten. Daar zit het grootste deel van het crawlbudget.
Praktische beslissing over facetten
Er bestaat geen universele regel. Facetten met echt zoekvolume (bijvoorbeeld combinaties van kleur en maat in mode) verdienen indexering als landingspagina. Facetten die alleen voor navigatie dienen, moeten toegankelijk maar niet indexeerbaar blijven. Wat niet werkt: massaal noindex toepassen op alle facetten en vervolgens ontdekken dat sommige long-tailverkeer opleverden. Controleer Search Console voordat je beslist, door te filteren op URL’s met parameters en zoekopdrachten met vertoningen.
Stap 3: configureer canonicals, paginering en varianten
Dit is het punt waar de meeste winkels kracht verliezen. Drie concrete configuraties:
Productvarianten
Als elke maat of kleur een eigen URL genereert met bijna identieke content, kies dan een canonieke URL. In Shopify creëren de standaardvarianten geen afzonderlijke URL, maar veel thema’s genereren ze met parameters; in Magento is het wel gebruikelijk om URL’s per variant te hebben. Beslis of de variant een eigen pagina verdient (omdat er eigen vraag is) of naar het hoofdproduct moet verwijzen.
Paginering
Pagina 2 van een categorie moet indexeerbaar en zelfcanoniek zijn. Canonicaliseer die niet naar pagina 1: dan verlies je de crawl van producten die alleen daar verschijnen. En blokkeer die niet in robots.txt, want dan ziet Google de links op die pagina niet.
Sortering en weergave
Sorteerparameters (?orderby=price, ?view=grid) moeten met een canonical naar de schone categorie-URL verwijzen. Controleer dat de interne link ze niet doorgeeft.
Stap 4: gestructureerde productdata, met nuances
De implementatie van schema Product en Offer is verplicht als je rich results wilt, maar hier is het gepast eerlijk te zijn over de beperkingen. Volgens de officiële documentatie van Google garanderen gestructureerde data niet dat verbeteringen in de resultaten verschijnen; ze zijn een noodzakelijke, maar geen voldoende voorwaarde.
Fouten die steeds weer opduiken:
- availability die niet synchroon loopt met de werkelijke voorraad. Een product dat als InStock is gemarkeerd terwijl het in werkelijkheid is uitverkocht, leidt tot sancties in de verbeteringen en verwarring bij de gebruiker.
- price zonder valuta of met lokaal formaat (19,99 € in plaats van 19.99 met priceCurrency: EUR).
- Verzonnen of van een leverancier geïmporteerde geaggregeerde reviews. Google vraagt dat ze echte reviews van de site weerspiegelen.
Als je winkel duizenden referenties heeft en het ERP elk uur prijzen bijwerkt, is de synchronisatie van het schema een ontwikkelproject, geen template-aanpassing. Plan het als zodanig.
Stap 5: meet de prestaties met velddata, niet met laboratoriumdata
Core Web Vitals in ecommerce heeft een structureel probleem: zware producttemplates door afbeeldingen en scripts van derden. Lighthouse geeft je een laboratoriumfoto; wat telt is de velddata in Search Console, sectie Ervaring.
Controleer eerst welke templates de problemen concentreren. In veel winkels haalt de homepage de drempels en zijn het de productpagina’s met veel afbeeldingen die falen op LCP. De homepage optimaliseren verandert niets aan het resultaat. Prioriteer per template en per verkeer.
Belangrijke nuance: als je catalogus prijs en beschikbaarheid wijzigt via JavaScript van derden (aanbevelingsengines, chat, betaalproviders), kan de INP worden beïnvloed en die heb je niet altijd direct onder controle. Documenteer welke scripts onmisbaar zijn en welke niet voordat je iets verwijdert.
Controleer hoeveel klikken Googlebot nodig heeft om vanaf de homepage bij een product te komen. In diepe catalogi kunnen producten op pagina 5 van een categorie vier of vijf klikken verwijderd zijn. Voeg blokken met interne links toe (gerelateerde producten, zustercategorieën, uitgelichte items) die die afstand verkleinen.
En controleer het menu: links naar facetten vanuit het hoofdmenu zijn een sterk signaal voor indexering. Als je niet wilt dat een facet wordt geïndexeerd, zet het dan niet in het menu.
Stap 7: categoriecontent en thin content
Categorieën met alleen een productlijst presteren slecht in de competitie. Beschrijvende tekst toevoegen helpt, maar niet zomaar elke tekst. Generieke beschrijvingen die van de fabrikant zijn gekopieerd, zorgen voor duplicatie tussen winkels. Volgens sectorstudies behalen ecommerce-sites die eigen content op hoofdcategorieën ontwikkelen betere organische prestaties, hoewel correlatie geen causaliteit impliceert en het sterk afhangt van de niche.
Een concreet geval dat ik vaak tegenkom: categorieën met honderden producten waarbij de tekst onderaan wordt ingevoegd en identiek is in alle subcategorieën. Google detecteert dit als interne duplicate content. Oplossing: gedifferentieerde content per subcategorie, ten minste voor de subcategorieën met zoekvraag.
Stap 8: dashboard en verificatie
Sluit de audit af met een dashboard dat je elke maand kunt bekijken:
- Geïndexeerde URL’s versus in sitemap ingediende URL’s
- Verdeling van statuscodes in de crawl
- Zoekopdrachten met vertoningen maar zonder klikken (kansen voor titel en meta)
- Templates met de slechtste veld-LCP
- Uitverkochte producten en de behandeling daarvan (301, 410 of behouden met melding)
Over uitverkochte producten: er is geen eenduidig antwoord. Als het product terugkomt, behoud dan de URL met een melding en bijgewerkte beschikbaarheid. Als het definitief uit het assortiment is, redirect dan naar de categorie of naar een vervanger. Alles naar de homepage redirecten is een praktijk die signalen verwatert en de gebruiker in verwarring brengt.
Wat deze audit niet oplost
Transparantie is belangrijk. Een technische audit lost een catalogus zonder vraag niet op, vervangt geen prijsstrategie en garandeert geen posities. Ze kan ook geen gebrekkige winkelervaring compenseren: als de checkout faalt op mobiel, converteert organisch verkeer niet. En er zijn praktische grenzen: in winkels met duizenden SKU’s en een legacy-ERP kan de perfecte synchronisatie van gestructureerde data maanden duren, en het is verstandiger om referenties met het meeste verkeer prioriteit te geven dan om 100% dekking na te streven.
De audit is de diagnose. De gefaseerde uitvoering, met metrieken per template, is wat resultaten oplevert.