“Kan WooCommerce tienduizend producten aan?” is een vraag die we regelmatig krijgen, meestal van een groothandel die een papieren catalogus online wil zetten. Het antwoord is ja, maar niet met de inrichting die prima werkt bij honderd artikelen. Een grote webshop in WooCommerce vraagt een paar keuzes die u het beste vooraf maakt, omdat ze achteraf duur zijn om te herstellen.
Hieronder staat wat er feitelijk verandert bij die omvang, waar de eerste klachten ontstaan en welke inrichting in de praktijk standhoudt. Geen theorie: dit zijn de punten die bij shops boven de paar duizend artikelen telkens terugkomen.
Waarom aantallen anders uitpakken dan u verwacht
Het aantal producten zelf is zelden het probleem. WordPress kan prima honderdduizend regels in een tabel hebben staan. Het probleem zit in wat er per product aan gegevens hangt.
Elk product heeft naast de hoofdregel tientallen extra velden: prijs, voorraad, gewicht, afmetingen, artikelnummer, zichtbaarheid, en alles wat plugins erbij zetten. Bij tienduizend producten met vijftig velden staat u al op een half miljoen regels in één tabel. Heeft u ook nog varianten, dan vermenigvuldigt dat.
Daar komt bij dat een categoriepagina met vierentwintig producten voor elk van die producten prijs, voorraad, afbeelding en soms beoordelingen moet ophalen. Dat is werk dat lineair meegroeit met wat u per product opslaat, niet met hoeveel producten u heeft. Vandaar de vuistregel: minder velden per product weegt zwaarder dan minder producten.
De vier plekken waar het eerst knelt
Het zoeken in het beheerscherm. De standaardzoekfunctie doorloopt titels en teksten met een patroonvergelijking die geen gebruik kan maken van de index. Bij tienduizend producten duurt zoeken op een artikelnummer al snel tien seconden of langer.
Filters op categoriepagina’s. Filteren op drie eigenschappen tegelijk levert een databasevraag op met meerdere koppelingen. Dat is de vaakst gemelde oorzaak van een categoriepagina die vijf seconden nodig heeft.
De sitemap en de indexering. Tienduizend producten betekent tienduizend adressen die Google wil bekijken. Zonder sturing besteedt de zoekmachine zijn aandacht aan uitverkochte artikelen en filtercombinaties in plaats van aan uw kernassortiment.
Imports en synchronisaties. Een dagelijkse prijsupdate vanuit de leverancier raakt duizenden regels. Draait die op een ongelukkig moment, dan concurreert hij met uw bezoekers om dezelfde database.
De inrichting waarmee een grote webshop in WooCommerce standhoudt
- Neem hosting met echte reserve. Niet gedeeld, wel snelle opslag, ruim geheugen en een database die op een fatsoenlijke machine staat. Reken op een pakket vanaf ongeveer vijftig euro per maand; onder dat niveau bent u vooral aan het pleisters plakken.
- Zet objectcaching aan. Bij een grote catalogus is dit geen extraatje maar een voorwaarde. Wat het doet, staat in de uitleg over objectcaching met Redis.
- Vervang de zoekfunctie. Een aparte zoekindex maakt zowel het zoeken in het beheerscherm als de zoekfunctie voor klanten bruikbaar. Dit is bij deze omvang de ingreep met het grootste merkbare effect.
- Beperk het aantal velden per product. Elke plugin die “even een veldje” toevoegt, doet dat maal tienduizend. Ruim velden op van plugins die u niet meer gebruikt.
- Houd uw categoriestructuur ondiep. Drie niveaus is genoeg. Diepere bomen leveren trage menu’s op en klanten die verdwalen.
- Draai imports ‘s nachts en in blokken. Duizend regels per keer met een pauze ertussen is trager op papier en veel vriendelijker voor uw bezoekers.
- Zet uitverkochte artikelen niet zomaar op verborgen. Bepaal beleid: blijft de pagina staan met een melding, of verwijst hij door? Beide zijn verdedigbaar, willekeur is dat niet.
Wat u beter niet doet
Er zijn een paar aanpakken die bij deze omvang standaard fout uitpakken.
Alles in één keer online zetten. Begin met uw bestverkopende paar honderd artikelen, kijk hoe de shop zich houdt en groei in stappen. Een import van tienduizend producten in een nog niet getunede omgeving levert een dag storing op en geen enkel inzicht.
Elke eigenschap filterbaar maken. Vijfentwintig filterbare kenmerken klinkt klantvriendelijk, maar het levert een traag filterpaneel op en oneindig veel filtercombinaties die Google gaat indexeren. Kies er vier tot zes die klanten werkelijk gebruiken.
Zware pagebuilders op productpagina’s. Een sjabloon dat per product dertig extra verzoeken doet, is bij honderd producten een ergernis en bij tienduizend een structureel probleem.
Alle producten in één sitemap. Splits per duizend adressen en zorg dat de wijzigingsdatum klopt, anders blijft de zoekmachine dezelfde pagina’s herbezoeken.
Beheer en dagelijkse praktijk
Bij deze omvang verandert ook uw werkwijze. Een paar zaken die in de praktijk het verschil maken:
- Werk met een testomgeving. Een update van een filterplugin op een catalogus van deze omvang test u niet live. Waarom dat bij webshops extra geldt, leest u in de case over updates via een testomgeving.
- Maak vaker back-ups dan dagelijks. Bij honderd bestellingen per dag is een nachtelijke back-up niet genoeg; dan verliest u een werkdag aan orders.
- Houd een overzicht bij van uw koppelingen. Kassasysteem, boekhouding, verzendpartij en leverancier: schrijf op welke koppeling welke velden overschrijft. Bij een conflict wilt u dat weten voordat u gaat zoeken.
- Bewaak niet alleen of de site draait, maar of er nog besteld wordt. Bij een grote catalogus valt een stille storing in één categorie niemand op tot het einde van de week.
Een voorbeeld uit de praktijk: een handelsbedrijf in bevestigingsmaterialen groeide van drieduizend naar veertienduizend artikelen. De klachten begonnen niet bij de productpagina’s maar bij het beheerscherm; medewerkers konden een artikelnummer niet meer opzoeken zonder een minuut te wachten. Na het invoeren van een aparte zoekindex en objectcaching zakte dat naar onder de seconde. De catalogus zelf is nooit kleiner geworden.
Wat u eerst zou doen
Overweegt u de stap naar een grote catalogus, doe dan drie dingen voordat u importeert. Meet hoe lang uw huidige categoriepagina met filters erop nodig heeft. Vraag uw hoster hoeveel geheugen de database mag gebruiken. En bepaal welke velden u werkelijk per product nodig heeft, want dat is de knop waar u het langst plezier van heeft.
Wij begeleiden dit soort groeitrajecten meestal in fasen, met een meting voor en na elke stap. Dat structurele bewaken hoort bij het onderhoud van een groeiende WooCommerce-omgeving, en bij WebMaintor is de eerste vraag altijd hoeveel gegevens er per product achter de schermen worden bewaard.
Concrete volgende stap: open een categoriepagina met een filter actief en meet de tijd tot het eerste antwoord van de server. Ligt die boven de anderhalve seconde, dan is uw filterlaag het eerste dat aandacht verdient, ongeacht hoeveel producten u heeft.
