WooCommerce-onderhoud voor webshops die moeten blijven draaien

Een informatieve bedrijfswebsite die een uur offline is, kost u hooguit een paar gemiste contactaanvragen. Een webshop die een uur offline is, kost u omzet die niet terugkomt, en klanten die bij de concurrent bestellen. Dat verschil bepaalt alles aan de manier waarop een webshop onderhouden moet worden. Bij WooCommerce-onderhoud gaat het niet alleen om updates en back-ups, maar om het bewaken van een proces dat continu geld verdient: van productpagina tot betaling tot verzending.

Een WooCommerce-webshop is bovendien technisch een stuk complexer dan een gewone WordPress-website. Naast WordPress en het thema draaien er de WooCommerce-kern, een betaalplugin, een verzendplugin, vaak een koppeling met een boekhoudpakket of een voorraadsysteem, een plugin voor btw-berekening, een e-mailmarketingkoppeling en een reeks kleinere uitbreidingen voor kortingscodes, reviews of productfilters. Elk van die onderdelen krijgt updates in een eigen tempo, en elk onderdeel kan na een update net anders samenwerken met de rest.

Daar komt bij dat een webshop voortdurend nieuwe gegevens produceert. Bestellingen, klantaccounts, voorraadmutaties en betalingen stromen de hele dag binnen. Een back-up van gisteren is voor een webshop dus niet 'ongeveer actueel', maar mist een dag aan bestellingen. En anders dan bij een gewone website zijn de gegevens die u bewaart gevoelig: adressen, e-mailadressen, bestelhistorie en soms gedeeltelijke betaalgegevens.

Tot slot heeft een webshop te maken met regels die voor een gewone website niet gelden: btw-tarieven die per land verschillen, de OSS-regeling voor verkoop binnen de EU, herroepingsrecht, en eisen van betaalproviders. Verandert er iets in die regels of in de koppeling met uw betaalprovider, dan moet uw shop mee.

Ons WooCommerce-onderhoud is daarom ingericht rond drie vragen die wij dagelijks stellen: kan een klant op dit moment bestellen en betalen, zijn de gegevens van vandaag veilig, en is de shop klaar voor wat er morgen aan verkeer of wijzigingen aankomt. Alles wat wij doen, van staging-tests tot monitoring van de bestelflow, dient een van die drie vragen. In de secties hieronder leggen wij per onderdeel uit wat dat in de praktijk betekent.

De belangrijkste regel bij een webshop is simpel: nooit een update rechtstreeks op de live shop uitvoeren zonder eerst te testen. Een update van WooCommerce, van uw betaalplugin of van uw thema kan de checkout onbruikbaar maken zonder dat er een foutmelding verschijnt. De shop ziet er normaal uit, producten zijn zichtbaar, maar de betaalknop doet niets, of de verzendkosten worden verkeerd berekend. U merkt het pas als de bestellingen uitblijven.

Daarom werken wij met een staging-omgeving: een exacte kopie van uw shop op een afgeschermd adres, waar bezoekers en zoekmachines niet komen. Updates voeren wij eerst daar uit. Vervolgens doorlopen wij het hele bestelproces alsof wij een klant zijn:

1. Een product zoeken via de zoekfunctie en via een categoriepagina.
2. Een variant kiezen (maat, kleur) en toevoegen aan de winkelwagen.
3. Een kortingscode toepassen en controleren of het totaal klopt.
4. Naar de checkout gaan, adres invullen en de verzendopties bekijken.
5. Een testbetaling doen via de betaalprovider in testmodus.
6. Controleren of de bevestigingsmail bij de klant en bij u aankomt, met de juiste bedragen en btw.
7. Controleren of de bestelling correct in het beheer verschijnt en of eventuele koppelingen (boekhouding, verzending, voorraad) reageren.

Pas als dat allemaal klopt, voeren wij dezelfde updates uit op de live shop, op een rustig moment en met een verse back-up vooraf. Daarna herhalen wij een verkorte testbestelling op de live omgeving, want een staging-kopie is nooit honderd procent identiek aan de live server.

Een veelgemaakte fout is het inschakelen van automatische updates voor alle plugins. Voor een blog is dat te verdedigen; voor een webshop niet. Wij zien geregeld shops waar een automatische update van een betaal- of verzendplugin midden in de nacht de checkout heeft gebroken, en de eigenaar dat pas de volgende middag ontdekte. Beveiligingsupdates voor WordPress zelf laten wij wel automatisch lopen; alles wat het bestelproces raakt, gaat via staging.

Bij ons Groei-abonnement is de staging-omgeving standaard inbegrepen, evenals de maandelijkse update-ronde met testbestelling. Hebt u een eigen ontwikkelaar die af en toe iets bouwt, dan kan die dezelfde staging-omgeving gebruiken, zodat ook maatwerk eerst wordt getest voordat het live gaat.

In Nederland wordt het grootste deel van de online aankopen met iDEAL betaald. De meeste WooCommerce-shops bieden iDEAL aan via een betaalprovider zoals Mollie, die ook creditcard, PayPal, Bancontact voor Belgische klanten, Apple Pay en achteraf betalen via Klarna kan afhandelen. Die opzet werkt goed, maar er zit een aantal schakels tussen de klik op 'Bestellen' en het geld op uw rekening, en elke schakel kan haperen.

Wat er in de praktijk mis kan gaan:

• De betaalplugin loopt achter op de betaalprovider. Providers vernieuwen hun koppeling regelmatig; een oude plugin kan dan betalingen weigeren of de bevestiging niet meer ontvangen.
• De terugkoppeling (webhook) komt niet aan. De klant heeft betaald, maar uw shop hoort dat niet van de provider. De bestelling blijft op 'in afwachting' staan en wordt niet verzonden. Vaak veroorzaakt door een firewall of een cachinginstelling die de melding blokkeert.
• Verkeerde API-sleutels na een verhuizing of staging-kopie. De testsleutel staat nog actief op de live shop, waardoor echte betalingen niet worden verwerkt, of andersom.
• Klarna weigert bestellingen. Achteraf betalen vereist dat adresgegevens in een specifiek formaat worden meegestuurd; een aanpassing aan het checkoutformulier kan dat verstoren.
• Creditcardbetalingen falen op mobiel. Het 3D Secure-scherm van de bank opent niet goed binnen een aangepaste checkout.
• Verlopen of gewijzigde bedrijfsgegevens bij de provider. Een verlopen KvK-uittreksel of een gewijzigd rekeningnummer kan uitbetalingen tijdelijk blokkeren.

Bij het onderhoud controleren wij maandelijks of de betaalplugin actueel is, of de webhook-URL bereikbaar is en of de betaalstatussen van recente bestellingen kloppen met wat de provider registreert. Zien wij bestellingen die al langer dan een uur op 'in afwachting' staan terwijl de klant volgens de provider heeft betaald, dan is dat een signaal dat de terugkoppeling hapert, en gaan wij direct kijken.

Wat u zelf kunt controleren: log in bij uw betaalprovider en vergelijk de betalingen van gisteren met de bestellingen in uw shop. Kloppen de aantallen en bedragen, dan werkt de keten. Een verschil is niet altijd een storing, maar wel altijd een reden om verder te kijken. Een gebroken checkout hoort tot de meest voorkomende oproepen voor spoedreparaties; met goed onderhoud voorkomt u dat het zover komt.

Zodra een bestelling binnen is, moet hij de deur uit. De meeste Nederlandse webshops koppelen WooCommerce daarvoor aan een verzendplatform als Sendcloud of MyParcel, of rechtstreeks aan PostNL of DHL. De koppeling haalt bestellingen op, maakt verzendlabels aan en stuurt de track-and-trace-code terug naar de klant. Als dat werkt, scheelt het dagelijks veel handwerk. Als het niet werkt, staat uw magazijn stil.

De koppeling is afhankelijk van meerdere onderdelen die allemaal actueel en juist ingesteld moeten zijn: de plugin in WooCommerce, de API-sleutel van het verzendplatform, de verzendmethoden en tarieven die u in de shop hebt ingesteld, en de manier waarop adresgegevens worden opgeslagen. Vooral dat laatste geeft problemen. Een straatnaam en huisnummer in één veld werkt voor de klant prettig, maar PostNL wil ze gescheiden aangeleverd hebben. Een update van het thema of van de checkout kan die splitsing ongemerkt breken, waarna labels foute adressen krijgen of helemaal niet worden aangemaakt.

Andere situaties die wij regelmatig tegenkomen:

• Verzendkosten die niet meer worden berekend na een update, zodat elke klant gratis verzending krijgt.
• Afhaalpuntkiezers die op mobiel niet meer laden, waardoor klanten de checkout verlaten.
• Gewichten of afmetingen die bij producten ontbreken, waardoor de koppeling een verkeerd of te duur label kiest.
• Bestellingen naar België of Duitsland die in de shop wel mogelijk zijn, maar bij het verzendplatform geen passende dienst hebben.
• Track-and-trace-mails die niet worden verstuurd omdat de status van de bestelling niet goed wordt bijgewerkt.

In het onderhoud nemen wij de verzendkoppeling mee in de testbestelling na elke update: wordt er een label aangemaakt, klopt het adres op het label, en komt de track-and-trace-code terug in de bestelling. Daarnaast houden wij bij wanneer verzendplatforms hun API wijzigen, zodat de plugin op tijd wordt bijgewerkt.

Een praktische tip: leg bij uw verzendinstellingen vast welke tarieven en zones u hebt ingesteld, met een datum. Wij doen dat voor onze klanten in een korte configuratienotitie. Als er iets misgaat, is dan meteen te zien wat de juiste instelling was. En verandert u van vervoerder of van tarief, laat het ons dan even weten; wij passen de instellingen aan en testen ze, in plaats van dat u het zelf op een drukke maandag moet uitzoeken.

Over btw in een webshop bestaan veel onduidelijkheden, en de instellingen in WooCommerce maken het er niet eenvoudiger op. Wij zijn geen belastingadviseurs en geven geen fiscaal advies; uw boekhouder bepaalt welke regels op uw situatie van toepassing zijn. Wat wij wel doen, is ervoor zorgen dat de shop technisch doet wat uw boekhouder heeft bepaald, en dat dat na elke update nog steeds zo is.

Voor verkoop binnen Nederland is het overzichtelijk: het normale tarief van 21 procent, het verlaagde tarief van 9 procent voor bijvoorbeeld voedingsmiddelen en boeken, en in enkele gevallen 0 procent. Elk product hoort in de juiste btw-klasse te staan, en de prijzen die u toont horen inclusief btw te zijn, want in Nederland verkoopt u aan consumenten met prijzen inclusief btw.

Verkoopt u ook aan consumenten in andere EU-landen, dan komt de OSS-regeling in beeld, voluit het One Stop Shop-systeem. Kort samengevat: boven een drempel van 10.000 euro omzet per jaar aan consumenten in andere EU-landen moet u het btw-tarief van het land van de klant rekenen. Een Duitse klant betaalt dus Duitse btw, een Belgische klant Belgische btw. Via de OSS-aangifte geeft u al die buitenlandse btw in één keer in Nederland aan, zodat u zich niet in elk land apart hoeft te registreren.

Voor uw shop betekent dit dat WooCommerce per land het juiste tarief moet toepassen. Dat kan met de ingebouwde btw-tabellen of met een plugin die de tarieven automatisch bijhoudt. Wat er mis kan gaan:

• Tarieven van een bepaald land zijn gewijzigd, maar de tabel in uw shop is niet bijgewerkt.
• Na een update staat de instelling 'prijzen inclusief btw' onbedoeld uit, waardoor prijzen ineens netto worden getoond en bij de checkout stijgen.
• De btw wordt berekend op het factuuradres in plaats van het verzendadres, of andersom, terwijl uw boekhouder het anders had afgesproken.
• Zakelijke klanten met een geldig btw-nummer krijgen ten onrechte wel of juist geen btw-verlegging.
• Facturen die door een factuurplugin worden gemaakt, tonen andere bedragen dan de bestelling zelf.

Bij de maandelijkse controle vergelijken wij een steekproef van bestellingen met de ingestelde tarieven en met de factuur die de klant heeft ontvangen. Wijzigt uw boekhouder de afspraken, bijvoorbeeld omdat u de OSS-drempel nadert, dan passen wij de instellingen aan en testen wij met een bestelling naar het betreffende land. Zo blijft de administratie kloppen en hoeft u niet achteraf facturen te corrigeren.

Een webshop met tien producten beheert u met de hand. Bij honderden of duizenden producten, of bij een assortiment dat u bij leveranciers inkoopt, gaat dat niet meer. Dan werkt u met productimports uit een spreadsheet of een leveranciersfeed, en met een voorraadkoppeling naar een kassasysteem, een magazijnsysteem of een boekhoudpakket. Die automatisering bespaart veel tijd, maar vraagt om zorgvuldig onderhoud, omdat een fout zich direct vermenigvuldigt over het hele assortiment.

Voorbeelden van wat wij tegenkomen:

• Een leveranciersfeed verandert van kolomvolgorde, waardoor bij de volgende import prijzen en voorraadaantallen worden verwisseld. Producten van 89 euro staan opeens te koop voor 12 euro.
• Een import overschrijft handmatig aangepaste productteksten en afbeeldingen, omdat de importinstellingen niet goed waren afgeschermd.
• De voorraadkoppeling met het kassasysteem valt stil, zodat de shop producten blijft verkopen die in de winkel al zijn uitverkocht.
• Duizenden productvarianten met eigen afbeeldingen zorgen ervoor dat de mediamap en de database uit hun voegen groeien, met een trage shop tot gevolg.
• Een gestopte import laat producten met status 'concept' achter die in de zoekresultaten van de shop opduiken.

Onze rol in het onderhoud is drieledig. Ten eerste controleren wij of geplande imports en koppelingen daadwerkelijk draaien. Een koppeling die stilletjes is gestopt, valt anders pas op als een klant klaagt. Ten tweede bewaken wij de gezondheid van de database: verweesde varianten, dubbele producten en overbodige metagegevens ruimen wij periodiek op, zodat de shop snel blijft. Ten derde maken wij vóór elke grote import een back-up, zodat een verkeerd gelopen import binnen een kwartier is teruggedraaid.

Wat u zelf kunt doen: controleer na elke import steekproefsgewijs een paar producten, met name prijs, voorraad en btw-klasse. En houd het aantal producten in de shop overzichtelijk: producten die al een jaar niet zijn verkocht, kunnen vaak beter naar 'concept' of uit de shop. Elke productpagina die de zoekmachine moet doorzoeken en die uw database moet bijhouden, kost iets. Een kleiner, actueel assortiment is voor klant en server beter dan een uitgedijde catalogus.

Voor shops met een koppeling naar een boekhoudpakket, zoals e-Boekhouden, Exact of Moneybird, controleren wij daarnaast of bestellingen en betalingen correct overkomen, zodat uw boekhouder niet elke maand handmatig hoeft aan te sluiten.

Voor een webshop is een wekelijkse back-up niet genoeg. Stel dat uw shop op vrijdagmiddag onbruikbaar raakt door een mislukte update of een hack, en de laatste back-up is van maandag. Dan bent u vier dagen aan bestellingen, nieuwe klantaccounts en voorraadmutaties kwijt. Daarom maken wij voor webshops dagelijks een back-up, en bij drukke shops vaker. In ons Groei-abonnement zijn dagelijkse back-ups standaard.

Een back-up van een webshop moet aan dezelfde eisen voldoen als die van elke website (volledig, elders bewaard, met historie en getest), maar er komt iets bij: consistentie. Een back-up die midden in een bestelling wordt gemaakt, kan een bestelling bevatten waarvan de betaling nog niet is verwerkt. Wij plannen back-ups daarom op rustige momenten en gebruiken een methode die de database in één samenhangend geheel vastlegt.

Belangrijker nog dan de back-up zelf is de manier waarop wij herstellen. Een volledige terugzetting is namelijk niet altijd wenselijk. Voorbeeld: op woensdagochtend blijkt dat een update van dinsdagavond de productfilters heeft gebroken. Zet u de back-up van dinsdagmiddag terug, dan zijn ook alle bestellingen van dinsdagavond en woensdagochtend verdwenen. Dat wilt u niet.

In zulke gevallen kiezen wij voor een gedeeltelijk herstel:

• Alleen de bestanden (thema, plugins) terugzetten en de database met de nieuwe bestellingen intact laten.
• Alleen specifieke tabellen terugzetten, bijvoorbeeld de productgegevens na een mislukte import, terwijl bestellingen en klanten ongemoeid blijven.
• Bestellingen uit een back-up exporteren en in de huidige database invoegen als ze per ongeluk zijn verwijderd.

Dat vraagt om kennis van hoe WooCommerce gegevens opslaat, en om zorgvuldigheid. Wij doen zo'n gedeeltelijk herstel eerst op staging, controleren of bestellingen, klanten en voorraad kloppen, en zetten het dan pas live.

Alle back-ups worden versleuteld bewaard binnen de EU, los van uw hostingomgeving, en wij hebben een verwerkersovereenkomst met u, omdat er persoonsgegevens van uw klanten in staan. Wat u zelf kunt controleren: vraag eens hoe lang het zou duren om uw shop volledig te herstellen als de server vandaag uitvalt. Als het antwoord onduidelijk is of 'een paar dagen', dan is dat een risico dat u niet wilt lopen.

Een trage webshop verkoopt minder; dat is inmiddels ruimschoots aangetoond. Maar snelheid in een webshop is een ander vraagstuk dan snelheid op een gewone website. Bij een informatieve website kunt u vrijwel alles cachen: de pagina wordt één keer opgebouwd en daarna razendsnel uit het geheugen geserveerd. Bij een webshop kan dat maar gedeeltelijk. De winkelwagen, de checkout, het account van de klant en de voorraadstatus zijn per bezoeker anders en moeten dus telkens opnieuw worden berekend.

Dat betekent dat een webshop op twee fronten snel moet zijn. Ten eerste de pagina's die wel gecacht kunnen worden: de homepage, categoriepagina's en productpagina's voor bezoekers die nog niets in hun winkelwagen hebben. Daarvoor gelden de gebruikelijke technieken: paginacache, geoptimaliseerde afbeeldingen in WebP, lazy loading, een opgeschoonde set scripts. Ten tweede de dynamische onderdelen: de winkelwagen, de checkout en 'Mijn account'. Daar helpt cache niet, en telt de kwaliteit van de server, de PHP-versie, de database en de efficiëntie van de plugins.

Specifieke aandachtspunten bij WooCommerce:

• Categoriepagina's met veel filters. Elke filtercombinatie vraagt een zware databasequery. Een indexering van de juiste tabellen en een objectcache (Redis of Memcached) maken hier vaak het grootste verschil.
• Productafbeeldingen. Een assortiment met tientallen foto's per product is al snel een paar gigabyte. Wij zorgen dat de juiste formaten worden gegenereerd en dat de browser nooit een grotere afbeelding laadt dan hij toont.
• Winkelwagenfragmenten. WooCommerce ververst de winkelwagen op elke pagina met een extra verzoek naar de server. Op drukke shops kan dat de server belasten; het is mogelijk dat verzoek slimmer in te richten.
• Ingelogde klanten. Voor ingelogde bezoekers wordt de paginacache meestal overgeslagen. Wie veel terugkerende klanten heeft, merkt dat de shop voor hen trager is dan voor nieuwe bezoekers. Objectcache en een goede server verhelpen dat.
• Zoekfunctie. De standaardzoekfunctie van WordPress is voor grote assortimenten te traag en te onnauwkeurig. Een betere zoekindex verbetert zowel de snelheid als de conversie.

Snelheid is onderdeel van ons doorlopende onderhoud: wij meten maandelijks de laadtijd van de belangrijkste pagina's, inclusief de checkout, en grijpen in als die verslechtert. Is uw shop nu al structureel traag, dan is een eenmalige snelheidsoptimalisatie het goede startpunt, waarna het onderhoud het resultaat vasthoudt.

Een webshop bewaart meer persoonsgegevens dan een gewone website: namen, adressen, e-mailadressen, telefoonnummers, bestelhistorie en soms geboortedata of btw-nummers. Betaalgegevens zelf, zoals rekeningnummers en kaartgegevens, blijven bij een goede inrichting bij de betaalprovider en komen niet in uw database terecht. Maar ook zonder die gegevens is een gehackte webshop een datalek dat u mogelijk binnen 72 uur bij de Autoriteit Persoonsgegevens moet melden, en dat het vertrouwen van uw klanten aantast.

Voor webshops gelden daarom dezelfde beveiligingsmaatregelen als voor elke WordPress-website, plus een aantal specifieke:

• Klantaccounts beschermen. Klanten kiezen zelf hun wachtwoord en dat is vaak zwak. Wij stellen een minimumlengte in, beperken inlogpogingen op de accountpagina en zorgen dat het herstellen van een wachtwoord veilig verloopt.
• Beheerdersaccounts scheiden. Wie orders inpakt, heeft de rol 'winkelmanager' nodig, geen beheerdersrechten. Zo kan een gestolen inlog van een magazijnmedewerker geen plugins installeren.
• Kaartskimming voorkomen. Een bekende aanval plaatst een klein script op de checkoutpagina dat ingevoerde gegevens doorstuurt naar een aanvaller. Bestandsintegriteitscontroles en een Content Security Policy maken dat vrijwel onmogelijk.
• Exportbestanden opruimen. Exports van bestellingen of klanten die in de uploadmap blijven staan, zijn voor iedereen te downloaden die de bestandsnaam raadt. Wij controleren daarop en ruimen ze op.
• Bewaartermijnen. Bestelgegevens van jaren geleden hoeft u niet eeuwig te bewaren. WooCommerce kan oude persoonsgegevens automatisch anonimiseren; wij stellen dat in volgens de termijn die u met uw boekhouder en jurist afspreekt.
• API-sleutels beheren. Koppelingen met boekhouding, verzending en marketingtools gebruiken sleutels die volledige toegang tot bestellingen geven. Verlopen of ongebruikte sleutels trekken wij in.

Daarnaast loopt op elke shop die wij onderhouden een firewall, een dagelijkse malwarescan en monitoring op gewijzigde bestanden. Verdachte wijzigingen in de checkout krijgen daarbij voorrang; dat is het onderdeel waar een aanvaller het meeste te halen heeft.

Vragen over hackherstel, firewalls en meldplicht behandelen wij uitgebreid op onze pagina over websitebeveiliging. Voor uw webshop komt daar nog één advies bij: neem in uw privacyverklaring op welke partijen uw klantgegevens verwerken, waaronder uw betaalprovider, uw verzendplatform en uw onderhoudspartij. Wij leveren daarvoor de benodigde gegevens en sluiten standaard een verwerkersovereenkomst met u.

Voor veel webshops valt een groot deel van de jaaromzet in een paar weken: Black Friday, Sinterklaas en de dagen voor Kerst. Precies in die weken kunt u zich geen storing veroorloven, en precies in die weken is de belasting op uw shop het hoogst. Voorbereiding op seizoensdrukte is daarom een vast onderdeel van ons WooCommerce-onderhoud, en begint niet in november, maar in september of oktober.

Wat wij doen in de aanloop:

1. Alle updates vroegtijdig uitvoeren. In de drukke weken zelf voeren wij geen updates uit die het bestelproces raken, tenzij het om een kritieke beveiligingsupdate gaat. Alles wat kan, gebeurt weken eerder, via staging en met testbestelling.
2. Belastingtest. Wij simuleren een piek in bezoekers en bestellingen op de staging-omgeving en kijken waar het misgaat. Vaak blijkt de database of het geheugen van de server de eerste bottleneck.
3. Hosting afstemmen. Samen met uw hostingpartij bekijken wij of tijdelijk meer capaciteit nodig is. Veel hosters bieden een tijdelijke opschaling; dat is goedkoper dan een uur uitval op Black Friday.
4. Kortingscodes en acties testen. Een actie die pas om middernacht ingaat, een korting die alleen op bepaalde categorieën geldt, gratis verzending boven een bedrag: alles wordt vooraf getest, inclusief de combinaties die klanten zullen proberen.
5. Voorraadgrenzen controleren. Overschrijding van de voorraad door gelijktijdige bestellingen is een bekend probleem bij pieken. Wij controleren de instellingen voor voorraadreservering en de duur waarin een product in een winkelwagen 'vast' staat.
6. E-mailcapaciteit. Bij honderden bestellingen per uur moet ook de bevestigingsmail mee. Verzending via een transactionele maildienst in plaats van de server zelf voorkomt vertraging en spamproblemen.
7. Bereikbaarheid afspreken. Voor de drukke dagen spreken wij af hoe u ons bereikt en welke reactietijd geldt, zodat u niet hoeft te zoeken als het erop aankomt.

Tijdens de piek zelf staat de monitoring scherper afgesteld: kortere intervallen, extra controle op de checkout en op de betaalstatussen. Een storing van een kwartier op een gewone dinsdag is vervelend; op Black Friday-avond is het een probleem dat u wilt zien voordat uw klanten het zien.

Wat u zelf kunt doen: plan uw acties tijdig en geef ze aan ons door, zodat wij ze kunnen testen. Zet grote wijzigingen aan het thema of aan de checkout uit tot na de feestdagen. En bewaar de leerpunten: na afloop bespreken wij met Groei-klanten in het kwartaalgesprek wat er goed ging en wat volgend jaar beter kan.

Gewone websitemonitoring controleert of een website bereikbaar is. Voor een webshop is dat niet genoeg. Een shop kan prima bereikbaar zijn terwijl de checkout niet werkt, terwijl iDEAL-betalingen niet worden bevestigd, of terwijl de verzendkosten op nul staan. Daarom monitoren wij bij WooCommerce-onderhoud niet alleen de bereikbaarheid, maar de bestelflow zelf.

Wat er wordt bewaakt:

• Bereikbaarheid en laadtijd van homepage, een categoriepagina, een productpagina, de winkelwagen en de checkout, elke paar minuten, vanuit Nederland.
• Werking van de checkout. Een geautomatiseerde test die periodiek een product in de winkelwagen legt, naar de checkout gaat en controleert of de betaalmethoden en verzendopties verschijnen. Faalt die test, dan krijgt ons team direct een melding.
• Betaalstatussen. Een controle op bestellingen die te lang op 'in afwachting' blijven staan, wat wijst op een haperende terugkoppeling van de betaalprovider.
• Bestelvolume. Blijven bestellingen uit op een moment waarop u normaal gesproken bestellingen krijgt, bijvoorbeeld een zaterdagochtend zonder één bestelling, dan is dat verdacht, ook als alle techniek 'groen' lijkt.
• Foutmeldingen in het logboek. WooCommerce en de betaalplugin schrijven fouten naar een logboek dat bijna niemand leest. Wij lezen het wel en pikken er de fouten uit die op een probleem in de keten wijzen.
• SSL-certificaat en domein. Een verlopen certificaat zet uw hele shop in één klap op rood; wij zien het weken van tevoren aankomen.
• Geplande taken. WooCommerce voert veel werk op de achtergrond uit: mails versturen, voorraad bijwerken, koppelingen synchroniseren. Loopt die wachtrij vast, dan stapelen de problemen zich stil op.

Bij een melding beoordelen wij eerst of het om een echte storing gaat of om een tijdelijke hapering, en handelen wij vervolgens volgens de reactietijd van uw abonnement: vier werkuren bij Groei, acht bij Zakelijk. Vaak is het probleem opgelost voordat u het zelf hebt gezien. In het maandrapport ziet u wat er is gemeten, wat er is opgevallen en wat er is gedaan.

Wat u zelf kunt controleren: plaats zelf eens per week een testbestelling in uw eigen shop, bij voorkeur op mobiel, en betaal met een echte betaalmethode voor een klein bedrag. U ervaart dan precies wat uw klanten ervaren, van de eerste klik tot de bevestigingsmail. Het kost vijf minuten en het is de beste controle die er is, naast de geautomatiseerde monitoring.

Een webshop in tuinartikelen met circa veertig bestellingen per dag kwam bij ons nadat de eigenaar twee keer in een maand zelf had ontdekt dat de checkout niet werkte: één keer na een automatische update van de betaalplugin, één keer omdat het SSL-certificaat was verlopen. Beide keren was de shop meer dan een halve dag onbruikbaar voordat het opviel. Bij de intake bleken bovendien de back-ups alleen op de eigen server te staan, hadden vijf oud-medewerkers nog beheerdersrechten, en werden verzendkosten naar België verkeerd berekend.

In de eerste maand hebben wij automatische plugin-updates uitgezet en vervangen door een maandelijkse ronde via staging met testbestelling, dagelijkse versleutelde back-ups buiten de server ingericht, de gebruikers opgeschoond, de verzendzones gecorrigeerd en monitoring op de checkout en op de betaalstatussen geplaatst. In de maanden daarna zijn de productafbeeldingen geoptimaliseerd en is een objectcache ingericht, waardoor de categoriepagina's ongeveer twee keer zo snel laadden. De piek in december verliep zonder storing; twee kleine haperingen in de betaalterugkoppeling zijn door de monitoring gesignaleerd en binnen het uur verholpen, voordat er bestellingen bleven hangen.

Wilt u weten hoe uw eigen shop ervoor staat, loop dan onderstaande checklist door. Elke vraag die u niet met 'ja' kunt beantwoorden, is een aandachtspunt.

• Wordt elke update eerst op een staging-omgeving getest, inclusief een testbestelling?
• Is er een dagelijkse back-up die buiten uw eigen server wordt bewaard, en is een herstel ooit getest?
• Weet u binnen een kwartier als de checkout niet werkt, ook 's avonds en in het weekend?
• Kloppen de btw-tarieven voor alle landen waar u naar verzendt, en is dat het afgelopen halfjaar gecontroleerd?
• Zijn de koppelingen met betaalprovider en verzendplatform actueel en is de terugkoppeling gecontroleerd?
• Hebben alleen de mensen die het echt nodig hebben beheerdersrechten, en gebruiken zij tweestapsverificatie?
• Laadt uw productpagina op mobiel binnen drie seconden, ook voor ingelogde klanten?
• Is de shop de afgelopen piek zonder storing doorgekomen, of was dat geluk?
• Weet u wie u belt als het op een zaterdagochtend misgaat, en hoe snel er dan iemand kijkt?
• Is er een verwerkersovereenkomst met iedereen die toegang heeft tot uw klantgegevens?

WooCommerce-onderhoud is bij ons onderdeel van het Groei-abonnement van € 249 per maand, inclusief dagelijkse back-ups, staging, vijf uur aanpassingen en een reactietijd van vier werkuren. Er zijn geen opstartkosten en geen langlopende contracten; u kunt maandelijks opzeggen. Twijfelt u of uw shop klaar is voor de volgende stap, vraag dan een vrijblijvende controle van uw webshop aan. U ontvangt een verslag in gewoon Nederlands met wat er goed zit en wat beter kan, zonder verplichtingen.