Waarom categoriefilters (faceted navigation) je crawlbudget opsouperen
Elke filtercombinatie op een categoriepagina — maat, kleur, prijs, merk — kan zijn eigen URL genereren. Op een kleine catalogus maken een paar tientallen combinaties niet uit. Op een catalogus met duizenden producten en vijf tot zes gelijktijdig beschikbare filters explodeert het aantal mogelijke URL's, en de meeste hebben geen enkele eigen zoekwaarde — het zijn dezelfde producten, alleen herschikt. De Google-documentatie over faceted navigation beschrijft precies dit patroon als een van de meest voorkomende oorzaken van klachten over crawling: de zoekmachine verspilt tijd aan het opnieuw crawlen van bijna identieke variaties, in plaats van nieuwe of bijgewerkte pagina's te ontdekken.
Het praktische gevolg is geen „straf”, maar iets minder zichtbaars: de pagina's die er echt toe doen — nieuwe categorieën, nieuwe producten — worden trager ontdekt en opnieuw geïndexeerd, omdat het crawlbudget van de site elders wordt besteed.
- 01Sluit filtercombinaties uit van crawlbare interne links koppel de filternavigatie via JavaScript of geblokkeerde parameters, niet via normale, indexeerbare href's.
- 02Houd een schoon URL-patroon aan voor elk filter inconsistente parameters (andere volgorde, hoofd-/kleine letters) creëren extra duplicaten zonder enig voordeel.
- 03Blokkeer niet blindelings alles via robots.txt een te agressieve blokkering kan ook filtercombinaties met echt zoekvolume verbergen, zoals „schoenen maat 40”.
Correcte canonical voor productvarianten (maat, kleur, verpakking)
Een probleem dat losstaat van filters is het product met varianten — hetzelfde hemd in drie kleuren, hetzelfde wasmiddel in twee formaten. Hier is de typische fout omgekeerd: ofwel heeft elke variant zijn eigen URL zonder enige canonieke koppeling ertussen, ofwel worden alle varianten gedwongen naar één enkele „canonieke” URL, zelfs wanneer mensen exact zoeken op „zwarte tas”, niet alleen „tas”. Volgens de Google-documentatie over het consolideren van duplicate URL's zijn de sterkste signalen voor het kiezen van een canonieke pagina, in volgorde, de redirect, dan de rel=canonical-tag, dan de opname in de sitemap — en de signalen kunnen gecombineerd worden voor een duidelijker resultaat.
De praktische regel: als een variant een eigen zoekvraag heeft en voldoende afwijkende content (foto, beschrijving, prijs), is het de moeite waard om hem apart te indexeren, met een eigen canonical naar zichzelf. Als de varianten vanuit het perspectief van de koper inwisselbaar zijn, voorkomt een canonical naar de hoofdvariant dat het signaal verwatert tussen bijna identieke pagina's. WooCommerce behandelt varianten als subobjecten van een hoofdproduct; Shopify kan ze als aparte URL's blootstellen — controleer wat jouw platform standaard doet voordat je aanneemt dat het al correct is.
De beschrijving van categoriepagina's: welke content echt helpt
Een categoriepagina zonder enige unieke tekst — alleen een grid van producten — blijft, vanuit het perspectief van een zoekmachine, moeilijk te onderscheiden van tientallen andere vergelijkbare pagina's in de markt. Er is geen essay boven de producten nodig; er zijn een paar zinnen nodig die, in de echte woorden van de koper, uitleggen wat hij op die pagina vindt en hoe die verschilt van de aangrenzende categorie. De WooCommerce-documentatie over het organiseren van producten en het onderdeel over sitearchitectuur in de Shopify-gids voor SEO gaan in dezelfde richting: de categoriestructuur zou moeten weerspiegelen hoe de klant denkt, niet hoe het interne magazijn is georganiseerd.
Een simpele test: als je de tekst van de ene categoriepagina zonder enige aanpassing naar een andere kunt verplaatsen, zegt de tekst niets specifieks. Vermeld concreet wat de categorie onderscheidt — materiaal, gebruiksmoment, typisch prijsbereik — geen generieke bijvoeglijke naamwoorden zoals „premiumkwaliteit”, die noch de lezer, noch de zoekmachine helpen om de ene pagina van de andere te onderscheiden.
De structured data Product, Offer en AggregateRating, correct ingevuld
Structured data van het type product is de manier waarop je een zoekmachine expliciet vertelt wat de prijs van een product is, of het op voorraad is en welke rating het heeft, in plaats van deze informatie uit de tekst te laten afleiden. Volgens de Google-documentatie voor structured data van het type product worden rich results voor producten alleen ondersteund op pagina's die gericht zijn op één enkel product (of op de varianten van hetzelfde product) — niet op lijst- of generieke categoriepagina's.
De drie blokken die het meest tellen, zijn de naam en afbeelding van het product, het aanbod (Offer, met correct bijgewerkte prijs, munteenheid en beschikbaarheid) en, als er echte recensies zijn, de geaggregeerde beoordeling (AggregateRating). De meest voorkomende technische fout is niet het volledig ontbreken van de schema, maar de desynchronisatie ervan: de prijs die visueel op de pagina staat, wijkt af van die in de schema, of de beschikbaarheid blijft „in stock” staan nadat het product is uitverkocht. Een verzonnen of kunstmatig opgeblazen rating is een ander probleem, van vertrouwen, niet alleen technisch — vul AggregateRating niet in als je geen echte recensies hebt om het op te baseren.
Structured data creëert geen vertrouwen uit het niets — het brengt alleen duidelijker informatie over die sowieso correct en actueel op de pagina moet staan.
Core Web Vitals op de productpagina: wat wordt gemeten, wat wordt geoptimaliseerd
De productpagina (PDP) is meestal de zwaarst beladen pagina van een webshop — beeldgalerij, variantselector, recensies, aanbevolen producten. Volgens de Google-documentatie over Core Web Vitals zijn de drie gevolgde metrics de laadtijd van het grootste zichtbare element (LCP, onder 2,5 seconden), de reactietijd op interactie (INP, onder 200 milliseconden) en de visuele stabiliteit van de pagina tijdens het laden (CLS, onder 0,1).
Op een productpagina is de LCP bijna altijd de hoofdafbeelding — comprimeer hem, serveer hem in een modern formaat (WebP of AVIF) en laad hem niet lazy (lazy load), want het is het eerste wat de bezoeker moet zien. CLS ontstaat meestal door promotiebanners die laat laden en de content verschuiven, of door maatselectors die van formaat veranderen na het laden. INP lijdt het meest wanneer de knop „toevoegen aan winkelmandje” moet wachten op zware scripts van derden — chat, aanbevelingen, tracking — die de hoofdthread blokkeren.
- 01Secundaire afbeeldingen in de galerij in tegenstelling tot de hoofdafbeelding kunnen deze lazy geladen worden zonder de LCP te beïnvloeden.
- 02Beschrijvende alt-tekst, geen opeenstapeling van zoekwoorden „waterdichte jas heren, grijs, maat L” is nuttig; hetzelfde zoekwoord vijf keer herhalen in de alt-tekst helpt niet en kan als spam worden behandeld.
- 03Expliciete afmetingen voor elke afbeelding het ontbreken van de width/height-attributen is de typische oorzaak van CLS bij afbeeldingen die later laden.
Waarom de blog naar categorieën moet linken, niet alleen naar de homepage
Een blogartikel dat „de beste laptoptassen voor de woon-werkforens” vergelijkt en vanuit de tekst niet linkt naar de echte categorie laptoptassen, verspilt precies het soort interne link dat het meest telt voor een grote catalogus: een link die autoriteit en thematische context rechtstreeks doorgeeft aan een pagina die kan verkopen. De link naar de homepage doet dat niet — de homepage is meestal toch al de best gelinkte pagina van de site.
In de praktijk zou elk nieuw blogartikel twee of drie relevante categorieën of producten uit de catalogus moeten identificeren en ernaar linken met beschrijvende ankertekst, niet generiek („bekijk hier”). Op een grote catalogus is dit ook een ontdekkingsmechanisme: categorieën die diep in de structuur begraven zitten, worden vaker opnieuw gecrawld als ze verse links krijgen vanuit nieuwe content, niet alleen vanuit het statische navigatiemenu.
Uitverkocht of uit de verkoop gehaald product: 410, redirect of behouden pagina
Deze twee situaties worden verschillend behandeld, en de verwarring ertussen leidt tot de meeste verkeerde beslissingen. Een tijdelijk uitverkocht product, dat weer op voorraad komt, zou op zijn pagina moeten blijven staan, met de beschikbaarheid correct bijgewerkt in de productschema (out of stock of pre-order), niet van de site gehaald. Het verwijderen van de pagina voor een tijdelijk voorraadtekort gooit precies die URL weg die al geschiedenis en mogelijk behaalde positionering had.
Een product dat definitief uit de verkoop wordt gehaald, is een ander verhaal. Als er een duidelijke vervanger is — dezelfde categorie, bijgewerkt model — is een redirect naar dat product het sterkste consolidatiesignaal dat je kunt geven, volgens de signaalhiërarchie uit de Google-documentatie over canonieke URL's. Als er geen echte vervanger is, creëert het forceren van een redirect naar een ongerelateerde pagina (vaak de homepage, uit reflex) een slechte ervaring en een verwarrend signaal; een duidelijke pagina „product definitief niet meer beschikbaar”, met echte aanbevelingen van vergelijkbare producten, is nuttiger dan elke geforceerde redirect.
Wat er meestal misgaat bij een platformmigratie
Veel van de bovenstaande problemen worden plots zichtbaar op het moment van een migratie — van het ene platform naar het andere, of gewoon van het ene URL-patroon naar het andere. De categoriestructuur verandert, productvarianten krijgen een ander URL-patroon, de productschema kan volledig ontbreken op het nieuwe thema totdat ze opnieuw is geconfigureerd, en zonder een volledige mapping van redirects gaat alle opgebouwde linkgeschiedenis en positionering op de oude URL's in één keer verloren, niet geleidelijk.
Het onderwerp is groot genoeg om apart te behandelen — het redirectplan, de URL-mapping en de lessen uit een echte replatforming staan uitgewerkt in de aparte gids voor het migreren van een webshop zonder de opgebouwde SEO te verliezen. Als je wilt zien hoe de lijst wordt toegepast op jouw eigen shop, zie SEO voor webshops.
Bronnen en verder lezen.
- 01Google Search Central — Crawling December: Faceted navigation
- 02Google Search Central — Duplicate URL's consolideren (rel=canonical)
- 03Google Search Central — Intro to Product Structured Data
- 04Google Search Central — Understanding Core Web Vitals
- 05Shopify Help Center — Improving search engine optimization (SEO)
- 06WooCommerce Docs — Products
Veelgestelde vragen
Wat is faceted navigation en waarom beïnvloedt het de SEO van een webshop?
Het is het filtermechanisme op categoriepagina's (maat, kleur, prijs), dat een zeer groot aantal URL-combinaties kan genereren. Elke combinatie verbruikt een deel van het crawlbudget van de site, wat betekent dat belangrijke pagina's — nieuwe producten en categorieën — trager ontdekt en opnieuw geïndexeerd worden.
Moet ik rel=canonical op elke productvariant zetten?
Niet automatisch. Als een variant (kleur, maat) eigen zoekvraag heeft en voldoende afwijkende content, kan het correct zijn om hem apart te indexeren, met een canonical naar zichzelf. Als de varianten praktisch inwisselbaar zijn, voorkomt een canonical naar de hoofdvariant dat het signaal verwatert tussen bijna identieke pagina's.
Heb ik echte recensies nodig om AggregateRating in de productschema te gebruiken?
Ja. AggregateRating moet echte recensies weerspiegelen die daadwerkelijk op de pagina staan. Het invullen ervan met verzonnen of kunstmatig opgeblazen waarden is een vertrouwensprobleem, niet alleen een technische kwestie, en kan de geschiktheid voor rich results beïnvloeden.
Wat doe ik met een uitverkocht product zodat ik de al behaalde positionering niet verlies?
Als het voorraadtekort tijdelijk is, houd je de pagina en werk je de beschikbaarheid bij in de productschema, zonder ze te verwijderen. Als het product definitief uit de verkoop wordt gehaald en er een duidelijke vervanger is, bundelt een redirect naar dat product het signaal beter dan het verwijderen van de pagina.
Laten we kijken wat we bij jou kunnen automatiseren.
Een gratis sessie van 30 minuten: we vertellen je wat er te automatiseren valt, hoe lang het duurt en wat het kost, met een vaste prijs na de discovery.