Stel je een winkel voor waar elk dashboard er goed uitziet. De homepage is geïndexeerd, Lighthouse is groen en de structured-data-validator toont geen fouten. Maar op precies hetzelfde moment komt de prijs in Google Shopping niet overeen met de prijs in de winkelwagen, houdt de mobiele filterlade toetsenbordgebruikers gevangen, en wordt elke aankoop twee keer geregistreerd.
Niets hiervan komt naar boven bij een snelle gezondheidscheck. Dat komt doordat een online winkel een verbonden systeem is, niet zomaar een verzameling pagina’s. Productdata stromen door naar de pagina, de gestructureerde data en de shoppingfeeds. Scripts en third-party tags bepalen hoe snel alles laadt. De checkout zet interesse om in omzet, en analytics hoort de hele reis nauwkeurig vast te leggen. Wanneer één onderdeel kapotgaat, kan het stilletjes al het andere vertekenen.
Daarom volgt een nuttige e-commerce audit de shopper, niet de sitemap. De checklist hieronder begint bij het ontdekken van de winkel en eindigt bij een afgeronde bestelling. Hij geeft je een gerangschikte lijst van echte problemen, elk met bewijs, een eigenaar en een duidelijke test voor wanneer het opgelost is.
Wanneer je deze audit uitvoert, en waarom de volgorde belangrijk is
Voer de volledige audit uit wanneer je een nieuwe e-commerceklant aanneemt, na een redesign of platformmigratie, vóór een grote groeipush, of wanneer een routinecheck een winkelbrede regressie aan het licht brengt. Reserveer drie tot zes uur voor een lichte pass, of één tot twee dagen voor een standaardaudit die elk belangrijk template goed test. Diepgaand onderzoek naar logs, feeds of analytics vraagt meestal aparte tijd.
De volgorde is bewust gekozen. Het heeft geen zin om conversiefrictie te beoordelen als Google de categoriepagina’s niet kan indexeren, en het heeft geen zin om het funnelrapport te vertrouwen als de aankooptag twee keer afgaat.
Een gedupliceerd aankoopgebeurtenis is geen bewijs van meer verkopen, en een snelle productpagina is niet gezond als de prijs die Google ziet verschilt van de prijs in de winkelwagen. Daarom verloopt de audit in fasen. Hij begint bij de eerste ontdekking, gaat dan verder naar de productwaarheid, snelheid en de aankoop zelf, en pas daarna naar de meting.
Voordat je begint, verzamel je wat je nodig hebt. Dat betekent toegang tot:
- Search Console,
- Analytics,
- Tagmanager,
- Catalogus- of feedbron,
- Merchant Center,
- een lijst met recente wijzigingen aan de site.
Fase 1: Kunnen zoekmachines de catalogus vinden?
1. Bouw een steekproef die de hele winkel vertegenwoordigt
De meeste e-commercebugs zitten in gedeelde templates en ongebruikelijke productstatussen. Een schone homepage zegt niets over gefilterde categorieën, variantlogica, uitverkochte artikelen of de checkout. Daarom moet je beginnen met bevestigen dat je de live productiesite test in de juiste markt, valuta en taal. Kies daarna minstens één URL voor elk van deze:
- de homepage
- een prioriteitscategorie
- een diepere categorie of een goedgekeurde filterpagina
- een typisch product
- een product met varianten
- een out-of-stock of stopgezet product
- een pagina met interne zoekresultaten, inclusief een die geen resultaten oplevert
- de winkelwagen, de checkout en de pagina met de orderbevestiging
Voeg een lastig of ongebruikelijk voorbeeld toe voor elk template dat riskant lijkt. Je analyticsrapport over landingspagina’s en een catalogusexport helpen je kiezen.
Je bent klaar wanneer elk belangrijk template en elke checkoutstatus een benoemde test-URL heeft, en alles wat je niet kon testen als “niet getest” is gemarkeerd.
2. Controleer crawlbaarheid, indexering, canonicals en sitemaps
Als het crawlpad kapot is, zal het publiceren van meer producten alleen maar het aantal getroffen URL’s vermenigvuldigen. Tegenstrijdige signalen maken problemen ook moeilijker te diagnosticeren. Robots-regels zeggen misschien het ene, terwijl canonical tags en de sitemap iets heel anders zeggen.
Bekijk robots.txt, de XML-sitemaps, responsecodes, robots-metatags en -headers, canonical tags, paginering en interne links. Gebruik URL-inspectie in Search Console om te zien welke canonical Google daadwerkelijk heeft gekozen voor je steekproefpagina’s. Vergelijk daarna de sitemap met de werkelijkheid. Die hoort live, indexeerbare pagina’s te bevatten die een 200-status teruggeven, geen redirects, fouten, noindex-pagina’s of duplicaten.
Je bent klaar wanneer je beoogde landingspagina’s 200 teruggeven, gecrawld kunnen worden, een consistent canonical- en indexeringsbeleid volgen en in de sitemap staan. Elke belangrijke uitsluiting hoort een verklaring of een eigenaar te hebben.
3. Volg de links: redirects, fouten en JavaScript
Een winkel kan er compleet uitzien in een browser, terwijl crawlers en hulptechnologie een veel dunnere versie zien. Laat een crawler draaien om gebroken interne links, redirectketens, loops en soft 404’s te vinden. Vergelijk daarna de gerenderde pagina met de ruwe HTML. Productkaarten, paginering, breadcrumbs en categorielinks horen echt en crawlbaar te zijn, en belangrijke content mag niet alleen van JavaScript afhangen.
Je bent klaar wanneer interne links rechtstreeks naar hun eindbestemming wijzen, foutpagina’s de juiste statuscode teruggeven en prioriteitsproducten vindbaar zijn zonder afhankelijk te zijn van infinite scroll.
4. Test categorieën, filters, paginering en sitezoekopdracht
Categorie- en filtersystemen kunnen tegelijk crawl traps creëren voor zoekmachines en frustratie bij shoppers. Een pagina kan technisch indexeerbaar zijn en toch een zwakke landingspagina zijn als de helft van de producten er niet relevant is.
Probeer de filters op desktop en mobiel. Controleer multi-select, “alles wissen”, resultaattellingen, sorteren, paginering of “meer laden”, en filtercombinaties die niets opleveren. Bekijk de URL’s die de filters genereren en vergelijk ze met het indexeringsbeleid van de winkel. Let ook op of een lang blok categoriekopie het productraster onder de vouw duwt.
Je bent klaar wanneer de bedieningselementen consistent werken, willekeurige filtercombinaties niet per ongeluk landingspagina’s worden, en shoppers een filter kunnen ongedaan maken zonder hun plek te verliezen.
Klaar om uw bedrijf te laten groeien?
Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.
Fase 2: Vertellen de productdata de waarheid?
5. Stem productidentiteit, prijs, voorraad en varianten op elkaar af
Eén verkeerd veld kan een shopper niet alleen misleiden, maar zelfs tot een mismatch bij de checkout leiden. Tegelijk kunnen de data perfect geformatteerd en toch fout zijn.
Vergelijk voor een handvol representatieve producten de naam, het merk, de SKU, GTIN of EAN, de gekozen variant, prijs, valuta, beschikbaarheid, afbeeldingen en belangrijke specificaties op elke plek waar ze voorkomen. Controleer wat er op de pagina staat, in de gestructureerde data, in de merchant feed, in de winkelwagen en bij de checkout. Neem afgeprijsde artikelen, varianten, uitverkochte artikelen, pre-orders en stopgezette producten mee.
Je bent klaar wanneer de feiten uit de steekproef op elk oppervlak overeenkomen, en elk bewust verschil, zoals merk versus fabrikant, expliciet in het datamodel staat.
6. Valideer gestructureerde data tegen wat shoppers zien
Gestructureerde data helpen alleen als ze de pagina nauwkeurig beschrijven. Een validator accepteert met plezier “InStock” terwijl de pagina en de checkout beide zeggen dat het product niet beschikbaar is. Daarom moet je elke productstatus door de Google Rich Results Test of de Schema.org Validator halen. Vergelijk daarna de gemarkeerde waarden met de zichtbare content en de bronfeed. Controleer voor producten met varianten of je markup-aanpak en canonical-opzet overeenkomen met hoe de pagina’s daadwerkelijk zijn gebouwd.
Je bent klaar wanneer steekproefpagina’s die in aanmerking komen geen ontbrekende verplichte eigenschappen hebben, de markup overeenkomt met wat zichtbaar is, en reviews en beoordelingen alleen worden gemarkeerd wanneer shoppers ze op dat product kunnen zien.
Fase 3: Is de winkel snel voor echte shoppers?
7. Meet Core Web Vitals eerst met velddata
Data van echte gebruikers en één enkele Lighthouse-run beantwoorden verschillende vragen. Lighthouse helpt je een probleem te reproduceren, maar kan niet zeggen of echte shoppers slagen of zakken.
Begin met PageSpeed Insights en het Core Web Vitals-rapport in Search Console. Noteer of er velddata bestaat voor de exacte URL of alleen voor de hele site. De “goede” drempels van Google, gemeten op het 75e percentiel, zijn:
- LCP (laden): 2,5 seconden of minder
- INP (responsiviteit): 200 milliseconden of minder
- CLS (visuele stabiliteit): 0,1 of minder
Bekijk mobiel en desktop apart. Als er geen velddata is, registreer het resultaat dan als onbekend en behandel labresultaten als voorlopig. Onbekend is niet hetzelfde als groen.
Je bent klaar wanneer elk prioriteitstemplate een veldveroordeling per apparaat heeft, of een duidelijk vermeld gebrek aan data, met de bron en de periode vastgelegd.
8. Vind de oorzaak, niet alleen de score
Algemeen advies zoals “comprimeer je afbeeldingen” of “verminder JavaScript” mist vaak de echte bottleneck en creëert werk dat de falende metriek niet vooruit helpt. Vind het specifieke element, verzoek of script dat verantwoordelijk is.
Identificeer het LCP-element en wat het vertraagt. Controleer daarna de gebruikelijke verdachten, zoals afbeeldingsformaten, lazy-loading op afbeeldingen boven de vouw, render-blokkerende CSS, het laden van lettertypen, third-party scripts, lange taken, caching, serverresponstijd, bronnen van layout shifts en tags die twee keer laden.
Draai herhaalde tests onder dezelfde omstandigheden en vergelijk een consistente statistiek, niet je beste run. Onthoud dat Total Blocking Time een nuttig labsignaal is, maar niet hetzelfde is als INP.
Je bent klaar wanneer elke belangrijke prestatiebevinding de falende metriek, het getroffen template, een reproduceerbare oorzaak en een eigenaar benoemt.
Schrijf u in voor onze nieuwsbrief
Ontvang gratis de nieuwste tips, trends en aanbiedingen.
Fase 4: Kunnen mensen daadwerkelijk iets kopen?
9. Test mobiele bruikbaarheid en toegankelijkheid op echte winkelbediening
Geautomatiseerde scores dekken niet elke interactie. Een winkel kan een scan doorstaan terwijl de filterlade de toetsenbordfocus gevangen houdt, de cookiebanner de knop ‘In winkelwagen’ bedekt of de maatkeuze geen toegankelijk label heeft.
Test op telefoonbreedtes van 360 tot 390 pixels, zoom de tekst in en probeer de hele reis met alleen een toetsenbord. Let op focusvolgorde en zichtbaarheid in menu’s, laden en dialoogvensters. Controleer of labels, knoppen, formulierfouten en aanraakdoelen nog steeds logisch zijn.
Je bent klaar wanneer een shopper de hoofdreis kan doorlopen zonder verborgen bedieningselementen of focus traps, en niets op mobiel de prijs, beschikbaarheid, variantkeuze, de knop ‘In winkelwagen’ of de checkout verbergt.
10. Voer de winkelwagen en checkout uit als een gecontroleerde test
Een zichtbare checkoutknop bewijst niet dat de checkout werkt. Checkoutbugs zijn commerciële incidenten, en ze ondermijnen ook je analytics.
Voeg hiervoor een normaal product en een variant toe aan de winkelwagen. Wijzig de hoeveelheid, verwijder een artikel en pas een coupon toe (of een bewust ongeldige) als je die hebt. Test daarna gast- en accountcheckout, verzendopties, betaalkeuze, validatiefouten, de terugknop en de mobiele layout. Gebruik een testbestelling of een goedgekeurd niet-belastend traject. Plaats nooit een echte bestelling zonder toestemming.
Je bent klaar wanneer de aankoop wordt afgerond of de afgesproken testgrens bereikt, totalen correct blijven, foutmeldingen mensen vertellen wat ze moeten doen, en elk geblokkeerd traject is gedocumenteerd met bewijs en zakelijke impact.
Fase 5: Meet je de reis correct?
11. Verifieer analytics, dubbele tags en consent
Dubbele tags blazen paginaweergaven, add-to-cart-gebeurtenissen en aankopen op. Ontbrekende of misvormde waarden maken omzetrapporten onveilig om beslissingen op te baseren. Het doel is simpel: één actie van een shopper moet één gebeurtenis opleveren, met het juiste product, de juiste waarde, valuta, transactie-ID en consent-status.
Maak een lijst van elke tagmanager-container, Google-tag, advertentiepixel, affiliatescript en server-side integratie. Volg daarna in een gecontroleerde sessie view_item, add_to_cart, begin_checkout en purchase. Vergelijk wat de browser verstuurt met GA4 DebugView en het orderrecord in de backend. Test voor en nadat de shopper een consentkeuze maakt.
Je bent klaar wanneer elke actie zijn gebeurtenis precies één keer afvuurt, aankopen een stabiele transactie-ID hebben, waarden en valuta overeenkomen met de backend, en niet-essentiële tags het consentbeleid respecteren.
12. Stem Search Console en Merchant Center af op wat je hebt gevonden
Een lokale paginatest kan je niet elke geïndexeerde canonical, sitemapwaarschuwing, productafkeuring of verloren zoekopdracht laten zien. Een dashboardmelding kan daarentegen een probleem beschrijven dat al is opgelost.
Inspecteer je prioriteits-URL’s in Search Console, bekijk de product- en merchant listing-rapporten en controleer de Merchant Center-diagnostiek tegen wat je op de live site zag. Noteer de datums, want hercrawling en feedverwerking lopen achter op deployments.
Je bent klaar wanneer elk belangrijk dashboardprobleem overeenkomt met live bewijs of is gemarkeerd als wachtend op propagatie, en elk open probleem een eigenaar heeft.
Fase 6: Zou een shopper deze winkel vertrouwen?
13. Controleer vertrouwenssignalen, contactgegevens, verzending en retourneren
Verborgen of tegenstrijdige commerciële informatie laat shoppers twijfelen en jaagt supporttickets op. Vergelijk de header en footer, de contactpagina, de checkout en de beleidspagina’s.
Je bent klaar wanneer de bedrijfsidentiteit duidelijk is, claims over verzending, retourneren en betaling door de hele reis overeenkomen, en geen enkel vertrouwensbadge onverifieerbaar is.
14. Controleer HTTPS, mixed content en front-end-hygiëne
Dit is geen penetratietest, maar een kwestie van basisdatahygiëne. Bevestig dat HTTP in één hop doorverwijst naar HTTPS, het certificaat geldig is, er geen mixed content is en formulieren correct worden verzonden. Controleer de console op ernstige fouten. Als iets op een echte kwetsbaarheid lijkt, geef het dan door aan een specialist in plaats van het te diagnosticeren op basis van een generieke waarschuwing.
Je bent klaar wanneer prioriteitspagina’s en de checkout veilig laden, redirects één hop kosten en formulieren zich gedragen zoals verwacht.
Van bevindingen naar oplossingen
15. Zet bevindingen om in een toegewezen herstelwachtrij
Een audit die eindigt in screenshots of een score verlaagt het risico niet. Vijftig symptomen door één kapot template mogen geen vijftig losse tickets worden. Groepeer bevindingen op hun grondoorzaak. Noteer of het de component, het template, de feedregel of de trackingopzet is. Bewaar de getroffen URL’s als bewijs. Prioriteer daarna:
- P0: een actieve storing die het bedrijf blokkeert, of een kritiek sitebreed probleem
- P1: een significant defect waar je zeker van bent
- P2: een belangrijk probleem met beperkte scope
- P3: een verbetering om te monitoren
Je bent klaar wanneer elke belangrijke bevinding één eigenaar heeft, een deadline, een test voor “opgelost” en een datum om het na de release opnieuw te controleren.
Het eindproduct
Lever een geversioneerd document of spreadsheet op met één rij per bevinding en een korte samenvatting bovenaan. Elke rij hoort het volgende te dekken:
- Het gedrag,
- het verwachte gedrag,
- de getroffen URL’s,
- het bewijs en wanneer je het hebt verzameld,
- ernst en zekerheid,
- de waarschijnlijke oorzaak,
- de aanbevolen oplossing,
- de eigenaar en de test die bewijst dat het klaar is.
Maar onthoud: je moet een probleem niet als opgelost markeren omdat iemand het ticket heeft gesloten. Markeer het als geverifieerd wanneer de test in productie slaagt.
Tools voor de klus
Je hebt geen abonnementen nodig om een sterke eerste pass te doen. Je hebt alleen deze gratis tools nodig:
- Google PageSpeed Insights voor velddata (waar beschikbaar) en Lighthouse-diagnostiek
- Google Search Console voor indexering, sitemaps, URL-inspectie, Core Web Vitals en rapporten over gestructureerde data
- Google Rich Results Test en de Schema.org Validator voor gestructureerde data
- Chrome DevTools en Lighthouse voor netwerk-, prestatie-, layout shift-, toegankelijkheids- en consolecontroles
- Google Tag Assistant en GA4 DebugView voor het volgen van gebeurtenissen
- SSL Labs Server Test voor TLS-configuratie
Als je een shortcut wilt, laat AmICited je al dat bewijs samenbrengen en de baseline bewaren voor later. De weergave Performance Impact vergelijkt templates op LCP, INP, CLS en serverresponstijd. URL Inspection en Sitemaps and Indexing volgen indexering voor prioriteits-URL’s. Products en Assortment tonen welke delen van de catalogus het meeste commerciële gewicht dragen. Annotations in the Reports Hub koppelen elke release aan wat er daarna gebeurde. De tools leveren het bewijs. De winkeleigenaar, developer of analist beslist nog steeds wat correct is en welke afwegingen acceptabel zijn.
Na de audit
Stuur elk bevestigd probleem naar de specialistische workflow die het kan sluiten: crawl- en renderingproblemen naar een technische SEO-audit , veldprestatiefouten naar Core Web Vitals-remediatie , facet- en voorraadstatusproblemen naar een categorie- en productreview , en trackingproblemen naar wie analytics beheert.
Er is geen noodzaak om de hele audit opnieuw te draaien na elke fix. Test het getroffen gebied opnieuw, annoteer de release zodat je kunt zien wat er daarna veranderde, en laat de reguliere gezondheidscheck de volgende regressie opvangen.
Terug naar de winkel waar alles er goed uitzag
Herinner je je de winkel van het begin nog? De homepage was geïndexeerd, Lighthouse was groen en de validator was schoon. Toch toonde Google Shopping de verkeerde prijs, hield de filterlade toetsenbordgebruikers gevangen en werd elke verkoop twee keer geteld.
Geen enkel dashboard markeerde iets daarvan. Deze checklist zou alle drie hebben gevangen: de prijsmismatch in stap 5, de focus trap in stap 9 en de dubbel getelde aankoop in stap 11. Elk daarvan breekt ergens langs het pad van de shopper, en dat is precies waar de audit kijkt.
Dat is wat je krijgt als je de shopper volgt in plaats van de sitemap. Je stopt met vragen “ziet de site er gezond uit?” en begint vier moeilijkere vragen te stellen. Kunnen mensen het product vinden? Is wat de winkel erover zegt waar? Kunnen ze het daadwerkelijk kopen? En kun je zien dat ze dat deden? Een winkel die alle vier met ja kan beantwoorden, is in betere vorm dan een met een perfecte score.
Dus kies je steekproef-URL’s, blokkeer de tijd en begin met fase 1. De eerste pass is de langzaamste. Daarna bestaat het werk vooral uit ervoor zorgen dat wat je hebt opgelost, opgelost blijft.
