Technische SEO voor ecommerce: los belangrijke problemen op

Technische SEO is het fundament dat je niet kunt overslaan

Je kunt de beste productbeschrijvingen in je branche schrijven en links bouwen vanuit elke grote publicatie. Niets ervan maakt uit als Google je pagina's niet goed kan crawlen en indexeren. Technische SEO is het fundament waar al het andere van afhangt, en webwinkels hebben meer technische complexiteit dan bijna elk ander type website.

Een typische contentsite heeft een paar honderd pagina's met een eenvoudige structuur. Een webwinkel kan 50.000 URL's hebben verdeeld over producten, categorieen, filtercombinaties, paginering en interne zoekresultaten. Elk van die URL's is een potentieel probleem als het niet correct wordt afgehandeld. Crawl budget wordt verspild aan onzin-URL's. Dubbele content verwart Google over welke pagina moet ranken. Trage paginasnelheden jagen klanten weg voordat ze zelfs je producten zien.

We auditen tientallen webwinkels per jaar, en technische problemen zijn de nummer een reden waarom winkels onderpresteren in organische zoekresultaten. Niet zwakke content. Niet onvoldoende links. Technische problemen die Google verhinderen zijn werk te doen. Het goede nieuws is dat het oplossen van technische problemen vaak de snelste en meest meetbare SEO-winsten oplevert. We hebben winkels 20-40% organisch verkeer zien winnen binnen 6 weken na het oplossen van grote technische schuld. Onze ecommerce SEO audit gids loopt precies door hoe je deze problemen kunt vinden.

Crawl budget beheer voor grote catalogi

Google wijst een crawl budget toe aan elke site. Dit is het aantal pagina's dat Googlebot in een bepaalde periode crawlt. Voor kleine sites met een paar honderd pagina's maakt crawl budget niet uit. Voor webwinkels met tienduizenden URL's is het een echte beperking.

Het probleem is niet dat Google je site niet crawlt. Het probleem is wat Google kiest om te crawlen. Als je site 50.000 URL's heeft maar er slechts 5.000 waardevol zijn (producten en categorieen), en de andere 45.000 filtercombinaties zijn, interne zoekresultaten en parametervariaties, dan besteedt Google mogelijk het meeste crawl budget aan de onzin-URL's. Je daadwerkelijke productpagina's worden minder frequent gecrawld, wat betekent dat ze langzamer geindexeerd worden en updates langer duren om in zoekresultaten te verschijnen.

Begin met het auditen van wat Google daadwerkelijk crawlt. In Google Search Console, controleer het Crawl Stats rapport onder Instellingen. Kijk naar de gecrawlde pagina's per dag en de responscodes. Als je een hoog percentage gecrawlde URL's ziet die 404's of redirects retourneren, is dat verspild budget. Controleer daarna je serverlogs als je er toegang toe hebt. Serverlogs tonen je elke URL die Googlebot aanvraagt, wat het meest nauwkeurige beeld van crawlgedrag is.

Blokkeer verspillende URL's van crawling via robots.txt. Veelvoorkomende URL's om te blokkeren op webwinkels zijn: interne zoekresultatenpagina's (/search?q=), winkelwagen- en afrekenpagina's (/cart, /checkout), accountpagina's (/account, /login) en filterparametercombinaties (/category?color=rood&size=m). Wees voorzichtig dat je geen CSS-, JavaScript- of afbeeldingsbestanden blokkeert die Googlebot nodig heeft voor rendering.

Ruim je URL-ruimte op. Als gefacetteerde navigatie 200.000 parameter-URL's heeft gecreeerd, moeten deze ofwel geblokkeerd worden in robots.txt of voorzien worden van noindex tags. Als je platform sessie-ID's in URL's genereert, moeten die verwijderd of gecanoniseerd worden. Het doel is om de totale crawlbare URL-ruimte te reduceren tot alleen de pagina's die je daadwerkelijk geindexeerd wilt hebben. Onze indexeerbaarheidscontrole helpt je te verifieren welke pagina's Google daadwerkelijk kan zien. Bij een recente audit vonden we een moderetailer met 380.000 geindexeerde URL's voor een winkel met 4.200 producten. Na het opruimen van filter-URL's, sessieparameters en verweesde pagina's, reduceerden we de index tot 12.000 URL's. Organisch verkeer steeg met 28% in zes weken omdat Googlebot eindelijk zijn crawl budget aan de juiste pagina's besteedde.

Sitesnelheidsoptimalisatie voor ecommerce

Paginasnelheid is een directe rankingfactor en een indirecte. Google gebruikt Core Web Vitals als rankingsignaal. Maar snelheid beinvloedt ook bouncepercentage en conversieratio, die rankings beinvloeden via gebruikersgedragsignalen. Een vertraging van 1 seconde in paginalaadtijd kan conversies met 7% verminderen, volgens data van Akamai.

Begin met de grote winsten. Beeldoptimalisatie is bijna altijd de grootste snelheidsverbetering voor webwinkels. Converteer afbeeldingen naar WebP, comprimeer ze en serveer ze op de juiste afmetingen voor elk apparaat. Als je productafbeeldingen gemiddeld 500KB zijn en je reduceert ze tot 80KB, is dat een reductie van 84% in beeldpayload over de hele site.

Schakel browsercaching en CDN-levering in. Een content delivery network serveert je statische assets (afbeeldingen, CSS, JavaScript) vanuit servers die fysiek dicht bij de gebruiker staan. Dit vermindert latentie van 200-500ms op een enkele oorsprongserver naar 20-50ms vanuit een CDN edge node. Cloudflare, Fastly en AWS CloudFront werken allemaal goed voor ecommerce.

Minimaliseer render-blokkerende resources. Als je pagina 15 JavaScript-bestanden en 8 CSS-bestanden laadt voordat het enige content kan renderen, staart de gebruiker 3-5 seconden naar een leeg scherm. Stel niet-kritiek JavaScript uit. Inline kritieke CSS (de stijlen nodig voor above-the-fold content) en laad de rest asynchroon. Verwijder ongebruikte CSS en JavaScript volledig indien mogelijk.

Third-party scripts zijn een veelvoorkomende snelheidskiller op webwinkels. Chatwidgets, analysetools, retargetingpixels, social share buttons en reviewwidgets voegen elk 100-500ms toe aan de paginalaadtijd. Audit elk third-party script. Verwijder alles dat niet actief waarde biedt. Laad de overgebleven asynchroon of nadat de hoofdcontent is gerenderd. We auditeerden een Shopify winkel die 23 third-party scripts laadde op elke pagina. Na het verwijderen van 9 ongebruikte scripts en het uitstellen van 8 andere, daalde hun LCP van 4,8 seconden naar 2,1 seconden op mobiel. Onze Shopify SEO gids behandelt platformspecifieke snelheidsoptimalisatie in detail.

Test je werkelijke gebruikerservaring, niet alleen labscores. PageSpeed Insights toont labdata (gesimuleerd) en velddata (echte gebruikersmetingen uit CrUX). Velddata is wat Google gebruikt voor rankingbeslissingen. Een pagina kan 90 scoren in labtests maar een LCP van 4 seconden hebben in de echte wereld vanwege netwerkomstandigheden en apparaatcapaciteiten. Focus op de velddata en test op mobiel, want dat is wat de meeste van je klanten gebruiken.

Mobile-first indexering: wat webwinkels fout doen

Google gebruikt mobile-first indexering sinds 2023. Dit betekent dat Google de mobiele versie van je site crawlt en indexeert, niet de desktopversie. Als je mobiele site content, links of structured data mist die op de desktopversie bestaan, ziet Google het niet.

Het meest voorkomende mobile-first probleem dat we vinden op webwinkels is verborgen content. Desktopversies tonen volledige productbeschrijvingen, specificaties en reviews in het zichtbare paginagebied. Mobiele versies verbergen ze achter tabs, accordeons of 'lees meer' toggles om schermruimte te besparen. Google heeft gezegd dat het content in tabs en accordeons normaal behandelt, maar onze tests tonen aan dat content in het primaire zichtbare gebied beter presteert dan content die interactie vereist om te onthullen.

Controleer of je mobiele site alle content van je desktopsite bevat. Voer een zij-aan-zij vergelijking uit met Chrome DevTools apparaatemulatie. Verifieer dat structured data, canonical tags en meta tags identiek zijn op mobiel en desktop. Als je een aparte mobiele site gebruikt (m.jouwwinkel.nl), overweeg dan om te migreren naar een responsief ontwerp, omdat aparte mobiele sites onderhouds- en pariteitsproblemen veroorzaken.

Mobiele bruikbaarheidsproblemen schaden rankings direct. Controleer het rapport Mobiele Bruikbaarheid in Google Search Console op fouten. Veelvoorkomende problemen zijn tekst die te klein is om te lezen (onder 16px), klikbare elementen die te dicht bij elkaar staan (knoppen hebben minstens 48px taptargets nodig met 8px tussenruimte), en content die breder is dan het scherm (wat horizontaal scrollen veroorzaakt). Los elke fout op die in dit rapport wordt gesignaleerd.

Test je afrekenproces op mobiel. Als het mobiele afrekenproces bruikbaarheidsproblemen heeft (kleine formuliervelden, verwarrende layouts, trage laadtijden), lijdt je mobiele conversieratio eronder. Google merkt het wanneer gebruikers consequent wegbounsen van je pagina's op mobiel, en het beinvloedt je rankings voor mobiele zoekopdrachten, die 60-70% van het ecommerce-verkeer uitmaken.

Canonical tags en dubbele content

Dubbele content is het meest voorkomende technische SEO-probleem in ecommerce. Producten die in meerdere categorieen verschijnen. Filter-URL's die variaties van dezelfde pagina creeren. Productvarianten met aparte URL's. Paginering die vergelijkbare pagina's maakt. HTTP- en HTTPS-versies. WWW- en niet-WWW-versies. Het oppervlak voor dubbele content op een webwinkel is enorm.

Canonical tags zijn je primaire verdediging. Elke indexeerbare pagina moet een zelfverwijzende canonical tag in de head-sectie hebben. Voor pagina's met meerdere URL-variaties (zoals filter-URL's of variant-URL's) moet de canonical verwijzen naar de voorkeursversie. Als /schoenen?kleur=blauw en /schoenen?kleur=rood beide bestaan maar je wilt dat /schoenen de geindexeerde versie is, krijgen beide parameter-URL's een canonical die verwijst naar /schoenen.

Veelvoorkomende canonical fouten die we regelmatig oplossen. Relatieve URL's gebruiken in plaats van absolute URL's in canonical tags (gebruik https://jouwwinkel.nl/pagina niet /pagina). Alle gepagineerde pagina's canonical instellen naar pagina 1 (pagina 2 moet canonical zijn naar pagina 2, niet naar pagina 1, omdat ze verschillende producten tonen). Pagina's canoniseren naar URL's die zelf noindex hebben of redirecten (wat canonical chains creert). Conflicterende signalen hebben waarbij de canonical het ene zegt maar de sitemap een andere URL bevat.

Voor productvarianten, beslis over een canonical strategie en pas deze consistent toe. Als elke kleurvariant een aparte URL heeft, kies dan de populairste kleur als canonical. Of canoniseer alle varianten naar de hoofd-product-URL zonder kleurparameter. Beide benaderingen werken, maar het mixen van strategieen door de catalogus heen veroorzaakt verwarring.

Audit je canonicals elk kwartaal met een crawler of onze canonical tag checker. Zoek naar pagina's zonder canonical, pagina's met incorrecte canonicals en pagina's waarvan de canonical URL een niet-200 statuscode retourneert. Bij een recente klantaudit vonden we 1.200 productpagina's waarvan canonicals verwezen naar verwijderde producten. Elk van die 1.200 pagina's vertelde Google effectief om ze te negeren. Het oplossen van die canonicals herstelde rankings voor honderden long-tail productzoekwoorden.

XML sitemaps voor grote ecommerce catalogi

Een XML sitemap is een routekaart die Google vertelt welke pagina's er op je site bestaan en welke het belangrijkst zijn. Voor webwinkels met duizenden pagina's kan een goed gestructureerde sitemap aanzienlijk verbeteren hoe snel nieuwe producten worden ontdekt en geindexeerd.

Splits je sitemap op in meerdere bestanden per paginatype. Maak aparte sitemaps voor productpagina's, categoriepagina's, blogposts en andere contentpagina's. Dit maakt het gemakkelijker om indexeringsproblemen te diagnosticeren (als producten niet geindexeerd worden, kun je specifiek de productsitemap controleren) en houdt elk bestand onder de 50.000 URL / 50MB limiet.

Neem alleen indexeerbare, canonieke URL's op in je sitemap. Neem geen URL's op die noindex tags hebben, URL's die redirecten, URL's die geblokkeerd worden door robots.txt, of niet-canonieke URL's. Je sitemap moet een schone lijst zijn van elke pagina die je wilt dat Google indexeert. Als je sitemap 80.000 URL's heeft maar slechts 15.000 indexeerbaar zijn, verliest Google vertrouwen in de nauwkeurigheid van je sitemap en kan het crawlen ervan deprioriteren.

Gebruik de lastmod tag nauwkeurig. Als je productprijzen of beschikbaarheid dagelijks bijwerkt, moeten de lastmod datums daadwerkelijke wijzigingen weerspiegelen. Stel niet alle lastmod datums in op de datum van vandaag om freshness-signalen te manipuleren. Google heeft bevestigd dat ze lastmod negeren als de data onbetrouwbaar zijn. Maar nauwkeurige lastmod datums helpen Google prioriteit te geven aan het crawlen van recent gewijzigde pagina's.

Dien je sitemap in bij Google Search Console en monitor de indexdekking. Het Sitemaps-rapport toont hoeveel ingediende URL's geindexeerd zijn. Als je 10.000 product-URL's hebt ingediend en slechts 6.000 geindexeerd zijn, onderzoek dan de ontbrekende 4.000. Ze hebben mogelijk dunne content, canonical problemen of kwaliteitsproblemen die indexering verhinderen.

Voor zeer grote winkels (100.000+ producten), overweeg het gebruik van sitemap-indexbestanden en dynamisch gegenereerde sitemaps. Statische sitemaps die handmatig opnieuw gegenereerd moeten worden telkens wanneer een product wordt toegevoegd of verwijderd, raken altijd verouderd. De meeste ecommerce platformen hebben plugins of ingebouwde functies voor dynamische sitemapgeneratie. Verifieer dat de jouwe daadwerkelijk nieuwe producten opneemt binnen 24 uur na publicatie.

Robots.txt configuratie voor ecommerce

Je robots.txt bestand is een bot instrument, maar het is een belangrijk instrument. Het vertelt crawlers welke delen van je site ze moeten vermijden, en het verkeerd instellen kan ofwel crawl budget verspillen (te permissief) of belangrijke pagina's blokkeren (te restrictief).

Een goede ecommerce robots.txt blokkeert: interne zoekresultaten (/search), winkelwagen- en afrekenpagina's (/cart, /checkout, /account), admin- en staginggebieden, tagpagina's die categoriefunctionaliteit dupliceren, en veelvoorkomende parameterpatronen die onzin-URL's genereren. Het staat toe: alle productpagina's, categoriepagina's, contentpagina's, CSS- en JavaScript-bestanden (Google heeft deze nodig om je pagina's te renderen), en afbeeldingen.

Hier is een fout die winkels duur komt te staan: JavaScript- of CSS-bestanden blokkeren in robots.txt. Sommige ontwikkelaars blokkeren /assets/ of /static/ directories om crawlers weg te houden van templatebestanden. Maar Google moet je CSS en JavaScript laden om je pagina's te renderen. Als Googlebot een pagina niet kan renderen, kan het de content niet goed evalueren, en rankings lijden eronder. Test je robots.txt door de URL Inspection tool in Search Console te gebruiken. Als Google de pagina niet correct kan renderen, heb je waarschijnlijk iets geblokkeerd dat het nodig heeft.

Gebruik de Disallow directive voorzichtig. Een Disallow voor /schoenen/ blokkeert /schoenen/, /schoenen/nike/, /schoenen/sale/ en elke URL die begint met /schoenen/. Als je alleen /schoenen/intern-rapport/ wilde blokkeren maar Disallow: /schoenen/ schreef, heb je net je hele schoenencategorie geblokkeerd. Test altijd je robots.txt wijzigingen met Google's robots.txt tester of onze robots.txt analyzer voordat je ze live zet.

Voeg een Sitemap directive toe onderaan je robots.txt die verwijst naar je XML sitemap (of sitemap index). Dit helpt crawlers je sitemap te vinden zelfs als ze niet in Google Search Console zijn geweest. Het formaat is eenvoudig: Sitemap: https://jouwwinkel.nl/sitemap.xml.

Structured data implementatie op schaal

Structured data (schema markup) helpt Google te begrijpen wat je pagina's bevatten en kan rich results genereren die click-through rates vanuit zoekresultaten verbeteren. Voor ecommerce zijn de relevante schematypen Product, BreadcrumbList, FAQPage, Organization en mogelijk LocalBusiness als je fysieke winkels hebt.

Structured data implementeren op schaal vereist een template-gebaseerde aanpak. Je kunt niet handmatig schema coderen voor 5.000 productpagina's. Bouw in plaats daarvan schematemplates in je paginatemplates en vul ze dynamisch vanuit je productdata. Je producttemplate moet naam, prijs, beschikbaarheid, SKU, merk, afbeeldingen en reviewdata rechtstreeks uit je productdatabase halen en uitvoeren als JSON-LD in de pagina-head.

JSON-LD is het aanbevolen formaat boven Microdata of RDFa. Het staat in een script tag in de head of body van de pagina en is eenvoudiger te implementeren, debuggen en onderhouden. Google beveelt JSON-LD expliciet aan voor de meeste schematypen. Plaats de JSON-LD script tag in de head sectie voor de snelste verwerking. Onze schema generator tool creert geldige JSON-LD voor Product, BreadcrumbList en andere ecommerce schematypen.

Test op templateniveau, niet alleen op paginaniveau. Als je productschema template een bug heeft, beinvloedt het elke productpagina. Voer de Rich Results Test uit op een product van elke templatevariatie. Monitor vervolgens de sectie Verbeteringen in Search Console voor sitewijde problemen. Veelvoorkomende fouten zijn ontbrekende verplichte velden (zoals afbeelding of aanbiedingen), ongeldige waarden (een prijs van '€0,00' op een product dat eigenlijk €49,99 kost), en markup die niet overeenkomt met de zichtbare pagina-inhoud. Laat je pagina's door onze schema validator lopen om problemen op te vangen voordat ze je rich results beinvloeden.

Ga verder dan de basis. Product schema met alleen naam en prijs is prima, maar het toevoegen van aggregateRating, review, merk, GTIN en gedetailleerde aanbiedingsdata (inclusief verzend- en retourbeleid) geeft je rijkere zoekresultaten. Breadcrumb schema op elke pagina vervangt de standaard URL-weergave door een leesbaar breadcrumb-pad. FAQ schema op categoriepagina's kan extra SERP-ruimte winnen. Elke laag structured data geeft Google meer om mee te werken en geeft jou meer mogelijkheden om op te vallen in zoekresultaten.

Core Web Vitals voor webwinkels

Core Web Vitals zijn Google's metrics voor pagina-ervaring: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Het zijn bevestigde rankingfactoren, en webwinkels staan voor unieke uitdagingen bij elk ervan.

LCP meet hoe snel het grootste zichtbare element laadt. Op productpagina's is dit meestal de hoofdproductafbeelding. Op categoriepagina's is het vaak de bannerafbeelding of de eerste productafbeelding in het raster. Doel: onder 2,5 seconden. Om LCP te verbeteren, optimaliseer je hero-afbeeldingen (WebP-formaat, juiste afmetingen, preload de afbeelding met een link rel=preload tag in de head), gebruik een CDN en minimaliseer render-blokkerende resources. Server responstijd beinvloedt ook LCP, dus zorg ervoor dat je hosting verkeerspieken aankan zonder te vertragen.

INP meet responsiviteit op gebruikersinteracties. Op ecommerce sites zijn de meest voorkomende INP-overtreders: filterinteracties die volledige pagina-herladingen triggeren, 'Toevoegen aan winkelwagen'-knoppen die de pagina bevriezen terwijl JavaScript verwerkt wordt, en zoek-autocomplete die de main thread blokkeert. Doel: onder 200 milliseconden. Optimaliseer door zware JavaScript naar web workers te verplaatsen, requestIdleCallback te gebruiken voor niet-kritieke taken en input handlers op zoek- en filtercomponenten te debouncen.

CLS meet visuele stabiliteit. Ecommerce sites zijn berucht om layout shift veroorzaakt door: afbeeldingen die laden zonder expliciete breedte- en hoogte-attributen (de content springt wanneer de afbeelding verschijnt), banners of promotiebalken die bovenaan de pagina worden geinjecteerd na het laden, en font swaps waarbij aangepaste lettertypen laden nadat de pagina rendert en alle tekst herschalen. Doel: onder 0,1. Repareer door expliciete afmetingen in te stellen op alle afbeeldingen en advertentieruimtes, ruimte te reserveren voor dynamische content die laadt na de initiele render, en font-display: optional of font-display: swap te gebruiken met size-adjusted fallback lettertypen.

Monitor Core Web Vitals op twee plaatsen: het Core Web Vitals rapport in Search Console (dat echte gebruikersdata gebruikt) en PageSpeed Insights voor individuele paginatests. Onze gratis Core Web Vitals checker geeft je een snelle momentopname van de prestatiescores van je winkel. Focus op de echte gebruikersdata omdat dat is wat Google gebruikt voor rankingbeslissingen. Labscores zijn nuttig voor debugging maar weerspiegelen niet de daadwerkelijke gebruikerservaring op varierende apparaten en netwerken.

Geef prioriteit aan je topaankomstpagina's. Je hoeft geen perfecte CWV-scores te hebben over elke URL. Focus op de pagina's die het meeste organisch verkeer genereren: je homepage, top categoriepagina's en top productpagina's. Het verbeteren van CWV op je top 50 pagina's qua verkeer heeft een groter rankingseffect dan marginale verbeteringen over 5.000 minder bezochte pagina's.